81–90 of 182 posts
Absolutely. Before GraphQL we were making a monumental effort to build a REST API. After deliberating on exactly what REST was and how we’d represent a few red haired resources, we were spending a lot of client time fetching deep trees through resource links. When we moved to GraphQL it solved a lot of the administrative and philosophical headaches and considerably reduced the number of connections, wasted data, and…
What is a red haired resource?
You're going to get responses from people who have invested a considerable amount of time in something they already had plans for (a "sunk cost") so I'm not sure you will get the sort of information you are after here.
We were mid-way through our project before realizing GraphQL might be a better fit for our use case so we paused for a week to play around with it and see if we could stand up something inside of our project that made sense.
GraphQL felt very "plug and play" to us. Aside from having to re-work some validation to fit into GraphQL's idea of mutations, we were mostly able to drop our existing models and logic directly in and see it working right away.
Having built very well defined REST APIs (and SOAP before that) for years, the flexibility that GraphQL offers made me feel a bit "uneasy" at first but I have come around to appreciating how much freedom it gives the front-end to only request the data they need.
I'm usually the type to shy away from flashy new doodads and stick with what I know is safe+reliable, especially in an enterprise environment, but as the project continues I'm feeling more and more confident in our choice. I suppose only time will tell though.
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…
GET `/gql?query=${query}&variables=${JSON.encode(variables)}`It went well, it greatly simplified both our backend and frontend code. The backend code got simpler and more stable because it no longer had to deal with "data packaging". The frontend code became more transparent, because you can now easily read what data gets exchanged, and more decoupled, because different components can independently require the data they care about. One of the biggest benefits has been the degree of independence to evolve both the client and server.
We haven't had the performance issues some people have mentioned (N+1 query etc.), because of the server-side design of our homemade GraphQL engine - in which data resolvers are batching and asynchronous by default, unlike most backend libs which approach this problem more naively. Will open-source that soon.
The biggest limitations I see to GraphQL are:
- it doesn't really have a story for caching. I have some ideas for addressing that, but it hasn't been a problem for us really.
- it repeated the SQL mistake of exposing a query language based on text, not data structures. Now we have to write queries as templates instead of assembling them programmatically. This hurts both application developers and library authors.
- it doesn't really have a story for structured writes.
On the upside, we can construct complex queries than eliminate many consecutive RPCs that you'd end up with in a traditional REST API. At scale this should work wonderfully, greatly reducing the client/server latency for our realtime app.
On the downside, the tooling is still far behind. This is somewhat due to GraphQL being a younger technology so you have to give it some time. OTOH, I feel like you can get things off the ground with REST more quickly. Problems with GraphQL tend to be harder to reconcile due to the debug tooling handicap.
Some of our engineers take a little time ramping up to GraphQL due to its complex nature. This is probably a good thing in the long run though, since it stresses the importance of keeping RPCs to a minimum and eliminates having to sync or batch consecutive RPCs.
Overall I still think it's a win. The tooling should improve over time, and hopefully it will be a first-class citizen in IDEs and libraries soon. Until then, you've got to be prepared to muscle though it.
You're going to get responses from people who have invested a considerable amount of time in something they already had plans for (a "sunk cost") so I'm not sure you will get the sort of information you are after here.
my experience is just ok. as someone here puts it, great for frontend devs but bad for backend devs. if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql. and on the frontend, get prepared to write out every songle fields you need from the backend. i can imagine it may be brutal for those who have a lot of changes in their schemas. my conclusion is that, since im a fullsta…
I would consider this a weakness of ORMs, not of GraphQL.
We have, so far, only made a GraphQL endpoint for internal use. It has been awesome for quickly finding things in a medium-complexity database schema (30 or so tables, bunch of different relationships). It has become my preferred way to quickly find things in the database. That being said, there are cases where a join between ad hoc subqueries is the best way, and GraphQL doesn't really offer a way to do that (though…
I think you're supposed to create a "virtual" field on the left-hand object that represents a collection of the right-hand type of objects. The field can be parameterized if your join needs extra information. If you want pagination, the virtual field returns an intermediary object describing the cursor (sort order, offset).
As a consumer of APIs I vastly prefer REST APIs. In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and m…
Earlier quoted context omitted.
> and on the frontend, get prepared to write out every songle fields you need from the backend. i can imagine it may be brutal for those who have a lot of changes in their schemas. Wouldn’t you need to do this in some form anyway (since those fields would be displayed or used in some way)?
well, it won't be just a simple GET /user/1 anymore. it will be like: user { id name role status age sex address group { id name } etc etc }