51–60 of 81 posts
The combo has taken all the pain of backend development out of the picture. Awesome to see GraphQL take off.
I've been using GraphQL with Apollo and Absinthe/Phoenix for a civic data gerrymandering project. Fantastic combo and everything plays well together. Certainly looking forward to using this stack on something big and bad in the near future.
Interesting. I'm considering building a graphql service using Absinthe. Could you give more information on your experience? Any difficulties?
There's a few areas the guides are a little sparse, but the API docs are pretty solid. That will improve over a little more time. There are some areas like returning errors to the client that are sort of roll-your-own in the graphql community at large, but those kinds of things for me have come down to just finding a practice that works for me and going with it. I haven't had a chance yet to upgrade to the latest version, which supports middleware and subscriptions, along with stuff I _think_ was already supported like transport-level batching.
My advice if you're thinking about using it is to build out a basic set of features with it and expand your usage—you'll find out pretty quick if you like that modality, and apollo makes a great combo with it if you do.
I'm about to start re-writing an api as GraphQL, I'm looking at the comments of support for Apollo, and looking at their webpage, but I'm failing to see what the real benefit is. What is the problem with GraphQL that they are addressing?
Apollo Client doesn't solve problems with GraphQL, it provides a client for GraphQL.
I'm about to start re-writing an api as GraphQL, I'm looking at the comments of support for Apollo, and looking at their webpage, but I'm failing to see what the real benefit is. What is the problem with GraphQL that they are addressing?
Relay I think is a more opinionated and heavier weight option, with the benefit provided being that it intelligently aggregates queries based off fragments and allegedly handles caching (minus invalidation, so you could argue that it doesn't really handle it ;) )
Fwiw in the project I'm working on now we judged that the extra complexity of a data fetching layer like Relay or Apollo wasn't worth it for us. We may have come to a different conclusion with a different project. Ymmv
I just got to plug graph.cool too for people interested in GraphQL and Apollo. I've been using it for quite a while, and the platform has been working great. I've been chatting quite a lot with their support (hey Nilan if you see this ;)) and they've been very helpful both in matters concerning the platform, but also for my app and GraphQL in general. I really recommend trying it out!
Edit: I guess you do something like this: https://github.com/RisingStack/graphql-server/blob/master/sr...
Earlier quoted context omitted.
HTTP/2 doesn't fix the problem of loading data dependencies over a connection with a noticeable round trip latency. Even with server push, you need some way of defining what is to be pushed. As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking…
Falcor sort of solves this by allowing you to communicate "references" in the graph. For example, it might inform you that users.52.friends.1 is actually users.45, so the client will cache it at that location instead. This is less complicated than GraphQL's solution of using the Relay Node interface.
Earlier quoted context omitted.
I'm kind of hoping that nesting resources becomes a non-issue in the future once HTTP/2 is widespread. Ideally you don't ever nest resources. With HTTP/2 the overhead of additional requests can be significantly lower, and you get the benefit of using client cache. This becomes pretty powerful once cache digests land, so a HTTP/2 REST service can just proactively push only the resources to the client that it has an (u…
But you're still going to make lots of requests which result in inefficient data access on the server unless you batch them up. So you just end up moving batching from the client where it is easy, to the server where it is hard.