This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-19
Channels
- # aws-lambda (4)
- # beginners (62)
- # cider (20)
- # cljs-dev (9)
- # cljsrn (13)
- # clojars (3)
- # clojure (105)
- # clojure-brasil (1)
- # clojure-denver (1)
- # clojure-finland (4)
- # clojure-italy (23)
- # clojure-norway (1)
- # clojure-spec (6)
- # clojure-uk (56)
- # clojurescript (41)
- # cursive (10)
- # datomic (25)
- # emacs (23)
- # figwheel (2)
- # fulcro (133)
- # graphql (12)
- # hoplon (32)
- # instaparse (13)
- # keechma (1)
- # lein-figwheel (1)
- # luminus (1)
- # lumo (1)
- # nyc (2)
- # off-topic (34)
- # om (2)
- # onyx (10)
- # pedestal (8)
- # portkey (1)
- # re-frame (10)
- # reagent (26)
- # ring (8)
- # shadow-cljs (77)
- # spacemacs (4)
- # sql (8)
- # tools-deps (15)
- # vim (9)
Hey ... my boss has asked me to collect a little bit of praise for Lacinia to pass on to HIS boss. Please post or DM me, if you can.
> The GraphQL schema providing library I’m using in the server provides tools to map nodes in the graph to resolvers which are responsible for getting what’s needed when it’s needed without complication. I recently started migrating much of the gateway service’s internals over to resolvers, and making the REST endpoints execute GraphQL under the hood. It’s been such a great experience it’s how I want to build any REST APIs in the future.
Unless I'm doing file upload/download, I don't feel I have a reason to NOT use Lacinia. There's always going to be edge cases (e.g., limited clients, very steep performance goals, requirements for edge caching) but for general "get/mutate application data" interactions, Lacinia is the only way I want to roll.