[haney]

Mostly, NOTE: I'm using python/django/graphene server side and apollo client side.

I love how flexible it is for client developers and because the great client side libraries it helps to eliminate a ton of boiler plate code on the client side.

My biggest complaint has been "lost" exceptions and caching.

Because it's possible for an exception to be thrown server side on one field while the other ones succeed I've been plagued with hard to monitor/find errors. I ended up writing a shim to parse the response in an attempt to get more insight into #errors / fields (this has also been really helpful for monitoring slow queries in new relic since all requests go to the same endpoint which breaks a ton of APM monitoring).

My other issue has been around caching, in apollo there are ways to say "don't use the cache for this request", but it's not to give an object a cache ttl. My app allows users to search for events that are happening near them right now, and I've run into several issues where apollo decided that an event from yesterday should be added to a result. It happened frequently enough even with queries that included times as an argument that I ended up basically implementing a "middleware" between what apollo gives back and the component, which felt really ugly.

[arnorhs]

you should take a look at the caching policies (fetch policy) apollo client provides as well as the error policy. neither are easy to find

for the error policy, you basically control the behavior (for each client instance or each request) when a request is considered failed. none, ignore and all. [1]

fetch policy allows you immense control over caching. this all depends on what you're doing but in some instances it can even make sense to never cache any requests, depending on how you application is structured. the docs are hard to google for this, but here's a link for you [2]

[1] https://www.apollographql.com/docs/react/features/error-hand...

[2] https://www.apollographql.com/docs/react/api/react-apollo.ht...

[haney]

So I understand that I can use the cache, not use the cache, or use the cache and always go over network for the entire request but that's all client side. GraphQL in general lacks a good answer for object level caching (so in my case I just filter things out before they make it to the component). It also lacks a solution for the server to indicate to the client how long something should be cached (like you would with cache headers or Etags)

It's just really annoying that I have a ton of queries that return lists of objects, where each object has an easily known expiration time, and there's no way to say, "cache this result but remove the elements that have expired". I can't even say, "cache this list until X time", which would be very easy in a RESTful environment. I know there are extensions to support caching but none of them are universal yet. I'm hopeful that the community will land on an answer for object level cache expiration.

[syrusakbary]

That's great feedback. I'm working on vastly improving exception reporting for the next version of Graphene :)

[filleokus]

I just have to chime in and thank you for all the hard work with Graphene! You have almost become a meme at the office, we're looking at the latests RC's at the office and talking about what Syrus might be up to this time :-). As a side note, I'm happy to read about Quiver and I hope it becomes a sustainable business!

[vinayan3]

> My biggest complaint has been "lost" exceptions and caching.

This is quite annoying because the server never throws a 500 error so the normal logging doens't kick in.

[filleokus]

Regarding monitoring, I would recommend to check out Apollo Engine if you haven't already. Basically middleware on the server side that injects error and performance info into the extensions object of the response which is then sent to them and presented in a nice UI.

[haney]

I’ve played with it a little, and I may resort to creating a proxy node app that reads through to the python app exclusively so I can get better monitoring.

[PhineasRex]

You can implement cache ttls with an Apollo link. See https://github.com/kamilkisiela/apollo-link-maxage for an example.

[haney]

Nice, I tried to hand roll something like this using link-state and my own renders but it didn't work well for me. I'll definitely check this out.

[swalsh]

I've never looked at graphene before (I've stopped spending time learning about each fad) but this really looks like it solves a real problem I've experienced. Definitely going to try it out.

[paulhallett]

Protip: ignore the docs on the website, use the docs on the github package / in the examples instead. They're much better!