This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # beginners (42)
- # calva (2)
- # cider (13)
- # clara (2)
- # cljdoc (1)
- # cljs-dev (8)
- # clojure (118)
- # clojure-australia (1)
- # clojure-europe (3)
- # clojure-finland (2)
- # clojure-italy (42)
- # clojure-japan (1)
- # clojure-nl (2)
- # clojure-spec (26)
- # clojure-uk (58)
- # clojurescript (83)
- # cursive (6)
- # data-science (2)
- # datomic (13)
- # devcards (2)
- # duct (9)
- # figwheel-main (4)
- # fulcro (11)
- # graphql (51)
- # jobs (1)
- # juxt (14)
- # kaocha (1)
- # off-topic (24)
- # re-frame (65)
- # reagent (4)
- # reitit (19)
- # remote-jobs (8)
- # shadow-cljs (50)
- # specter (3)
- # speculative (1)
- # vim (5)
- # yada (50)
with rest it's quite easy to set rules via cache-control headers and have a good level of granularity
The whole problem with graphql queries being flexible is that you can’t easily cache it like with normal REST endpoints.
Well you can if you have full control. But unless you have a CDN vendor that is/would be graphql aware that seems tricky to achieve with the same level of efficiency
One thing you can do is what Facebook do, which is precompile queries to hashes, and only accept the hashes in prod.
I think graphql has a very good fit for private data, or data that really changes according to the viewer. For things that are public/cacheable, you have to jump through hoops.
If you combine server-stored queries (coming in Lacinia) with query variables, you end up with a good cache key: the name of the query and the name and values of the query variables. Personally, I prefer to cache the raw data and just let the GraphQL execute.
Because GraphQL execution isn't pure, so there could be lots of state (time based values, auth rules driving visibility, or simply data changing in the backend) that make the cache data stale in non-obvious ways. If your data is fast, Lacinia is pretty fast too ... I run benchmarks and the execution overhead is typically under 5ms. You spend all your time waiting for data from backend or data store.
I am not worried about this. But if you want to be able to delegate caching/availability/locality to a cdn (which is super convenient and easy to achieve with rest) you dont have the same level of granularity now. You cannot have the same query (with or without params) return a response with A and B with different caching rules.
You can add a proxy that will query a cdn behind the scene but that's backward. You create a potential bottleneck you have to manage yourself, which kind of defeats the purpose of using a cdn
To get the same level of granularity a CDN would have to support/understand graphql and some custom extension to express cache settings from the query (like cache-control with rest) but per field
graphql is good for schema change management without having to version, and for avoiding overfetches
Sure, I am sold into this already. But I am trying to see if we can replace a public facing api with it also
If you’re talking about HTTP-level caching, I think you’ll find graphql really lacking, but you can in theory send some queries over GET, so that they can be cached my middle proxies.
if you want to vary caching of various parts of the query, you’ll have to do this server-side
yeah but even with middle proxies you don't get the "locality" from a CDN or the guaranteed availability
But still it’s happening server-side, right? That is, the client will get everything from your server, every time. It’s just that the server might save some work fetching those fields from somewhere else.
I mean there has to be a cdn vendor who supports this, via that graphql schema ext. or something else
Ah right. I don’t think you’ll have much luck there, too many moving parts for a vendor to support easily.
GraphQL schema extensions are very implementation-oriented, there’s only a couple official ones.
You can still send a graphql query over a GET parameter (a big opaque string), if you control the client and the query is static you will save some bytes, and you can use all the major CDN poviders.
it's more about the fact that cache settings will be set per (whole) response vs per fragments (field, object(s))
is it possible according to the GraphQL spec to have the same field-name/field-type definition in multiple interfaces that an object provides?
> The field must have a unique name within that Interface type; no two fields may share the same name.
let's say I have an interface
Person which represents common fields for a union of people object types, and specifies
phoneNumber, and an interface
hasPhoneInfo which is more something used for any object that provides phone fields and also specifies
phoneNumber, my take is that I should be able to do that
however when I try that with Lacinia, I get
ExceptionInfo Object field is not compatible with extended interface type.
I'm using an old version of lacinia, maybe I should really upgrade before continuing here