This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-23
Channels
- # announcements (1)
- # architecture (20)
- # babashka (30)
- # beginners (79)
- # calva (27)
- # cider (8)
- # clj-kondo (1)
- # clojure (125)
- # clojure-australia (1)
- # clojure-berlin (4)
- # clojure-europe (62)
- # clojure-france (1)
- # clojure-italy (6)
- # clojure-nl (4)
- # clojure-uk (12)
- # clojuredesign-podcast (5)
- # clojurescript (28)
- # core-async (31)
- # cursive (14)
- # datomic (47)
- # defnpodcast (1)
- # emacs (7)
- # figwheel-main (2)
- # fulcro (10)
- # graalvm (1)
- # graphql (11)
- # jobs-discuss (8)
- # leiningen (2)
- # off-topic (23)
- # rdf (9)
- # re-frame (3)
- # reagent (1)
- # reitit (5)
- # reveal (12)
- # shadow-cljs (12)
- # spacemacs (1)
- # tools-deps (87)
- # vim (22)
- # xtdb (21)
Well, tests did change output, but that output was wrong. The implementation is a little complicated by pushing as much as possible into the schema compile stage.
Oh yeah, I mean it’s good it’s more spec compliant, but it fundamentally changes the behavior of how our GraphQL responses will look when non-nilable fields are nil. I think this means we need to make sure our schema is more ironclad and fault tolerant when we upgrade to the newest version that includes this change. Right now our consumers are used to getting back mostly partial data when a service goes down that causes a non-nilable field to come back as nil. Now they will need to expect less partial data returned when this happens.
A stance I (sometimes) read from blogs about GraphQL is that you should embrace nullability. So in this case that would mean that if a field could be unavailable due to a partial outage, it could be nullable in your schema. Not that our schema is perfect in this regard :’)
That’s a great point, thanks for insight
Question for anyone in here: If you provide GraphQL APIs to your customers, what kind of feedback do you get? Do people consider it hard to use?
In our case, having 'internal' customers it's often putting them off, as they think it's complicated. But some of them have started using GraphQL, so I think it's just a matter of getting used to.
We used to get a bit of pushback because it was unfamiliar; then we parked ’em in front of GraphiQL and that solved most of the problems. Now way more of Walmart is on the GraphQL bandwagon, including federation.
Interesting, thanks @U26FJ5FDM and @U04VDKC4G!
No problem, I tend to see a difference between backend use and frontend use. Where frontend easier/faster to adopt GraphQL than backend. Probably helped because there are a lot of ‘serverless’ GraphQL solutions, but not that many GraphQL backend clients. But it seems more and more ‘acceptable’ for server to server as well.
Ah, interesting. I've noticed some resistance too (main use case is server to server), just not sure if it is a vocal minority, or what.
Also server to server the bandwidth is much less of an issue, while it’s one of the strong points of GraphQL that you only get what you aks for. But server to server often want ‘everything’ and that can be quite complex with GraphQL. But the introspection and graceful deprecation/evolution are big wins for server to server you get in return, in my opinion.