61–70 of 182 posts
We decided against it. We’re in a java backend and GraphQL in Java with ORM is considerably problematic when trying to create efficient resolvers. We simply ran into one hurdle after another and we were finding ourselves in diminishing returns. The concept is great, and if you write custom SQL queries for each resolver (if necessary), properly caching things that can be cached, and use the first class citizen program…
Earlier quoted context omitted.
What is a red haired resource?
Think "red-headed stepchild". The weird ones.
There was this long pause and then we both just started laughing.
File under: shit that doesn't happen any more because nobody plays single-player games side-by-side, late at night any longer.
FYI we're using it in production over a django backend (which comes with some drawbacks, since subscriptions == pushed updates are not perfectly implemented) with our react/apollo apps (web and native) and in my opinion the overhead lies surprisingly more in the frontend side (writing data connectors is longer, but way more explicit, than using rest queries returning json)than on the backend (where you just declare resolvers, a thing you don't even need to do in nodejs) and handle permissions.
Earlier quoted context omitted.
> considerably reduced the number of connections, wasted data, and made our client code so much simpler through easily grokked queries. I mean, you could have also just done this with what you had.
With a standard REST interface, you have to name all such combinations in advance. Possibly build custom code for each. With GraphQL, you specify them all at once, and are guided towards implementing code that will handle that. (There's no magic in GraphQL, of course, but the conceptualization alone can be useful. And if you're already in some particular ecosystem, they may have some localized magic you can use.) You…
... OData ...
It's a thing.
I'd like to add that correctly designed resolvers allow you: - to control very easily who can fetch what where it's fetched (permissions) - to fetch nested data when you need it without writing serializers - to help your frontend team find what they are looking for without asking the backend team everytime - mutations are a huge plus when it comes to standardization of your API too FYI we're using it in production ov…
Could you all tell about your stack, too ? Do we have to use NodeJS in order to get GraphQL working properly ? I'm aware of the libraries available for other languages, but NodeJS seems to be the only platform with proper support. I wonder if there is any Go developers building servers with GraphQL.
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…
> considerably reduced the number of connections, wasted data, and made our client code so much simpler through easily grokked queries. I mean, you could have also just done this with what you had.
The problem with REST is largely the people who look at it blindly as "thing that makes the CRUD go" instead of as a methodology of how to effectively use HTTP verbs and designing URIs that make sense. So I guess my question is, why would I use GraphQL over, say, the Swagger tool suite? Swagger and the OpenAPI spec defines a way of doing REST that best fits both what Roy Fielding meant for REST but also fits IDE and…
There are HUGE benefits for our client developers with GraphQL. Like being able to select as much or as little as a particular view/component/whatever requires and no more. GraphQL from a front end or mobile POV makes your api more like a data store that it can interact with and query for it's needs, which makes app UI work much nicer. There are also a ton of maintenance benefits, like for example if you add a field…
Assuming you are using some from of Semantic Versioning, adding a field to a REST API should never break existing clients. Did you mean "removing" a field?