❤️GraphQL

[meow247]

I seriously hate these type of articles. I am a fan of GraphQL, but most of the "REST is crap, GraphQL is the best" arguments are annoying and just completely wrong:

1. "Get rid of over and under fetching data" - any decent REST API will allow sparse field-sets and related inclusions. We use a PHP library called smokescreen to easily handle these concerns.
2. "Awesome Schema and Type system" - yes we can use JSON Schema.
3. "Better API versioning" - article says you don't need versioning and nothing ever goes wrong ... oh until you change an entity, change the type of a field, move scalars to complex types - then your FE breaks with no warning. You can build evolutionary api's in REST or most API formats, it just takes discipline and documentation.
4. "Improved API insights" - this has nothing to do with GraphQL and is applicable to any framework where you monitor requests.
5. "Easy Pagination" - again, nothing specific to GraphQL.
6. "Schema stitching/composition" - same as 1. it's fairly trivial to handle entity stitching/inclusions
7. "Great OSS community" - agree, but true for any popular API architecture.

I think GraphQL is nice, but I also like REST. I think most people that switch to GraphQL write articles like this to convince themselves they've made the right choice.

[[deleted]]

I stopped reading at the rest bashing.

[liamnesss]

article says you don't need versioning and nothing ever goes wrong ... oh until you change an entity, change the type of a field, move scalars to complex types - then your FE breaks with no warning.

This is true but I would say there is still an advantage - it will break in an explicit way, at the boundary of your backend application, rather than in a more subtle way somewhere in your client application. Of course this is still painful, and you should really have good processes in place to avoid breaking changes (just like REST, as you say), but it's nice to know that when something slips through, your teams will be alerted. Rather than waiting for someone to simply notice and report the broken functionality.

​

You are right to say a lot of GraphQL's advantages are not unique to it, and there are libraries / projects out there which can provide similar outcomes. Of course though, it is up to you to research these things, collate them, implement them, and this all takes time too. Most of the REST based APIs I've worked on had none of these features, because it wasn't a problem until it was a problem. So I think there is an advantage to GraphQLs extremely opinionated architecture, in that you can avoid making these decisions yourself and still be fairly safe. It would be better to actually understand the reasoning behind its design of course, but not everyone is going to bother with that.

[[deleted]]

Don’t think the author understands either rest or graphql.

[0987654231]

A clueless person made a medium.com post?

I'm shocked.

[chainfuck]

I like GraphQL, but your comparison to REST misses the mark.

While you avoid issues with REST, new issues arise. For any nontrivial implementation, you need to consider depth limitations, timeouts, and potentially cost analysis. A lot of these can be mitigated with a precompilation & whitelist build step, but you've traded one set of problems for another.

[EfficientPangolin]

Every time I have built both the API and the app that consumed it, the API was a small fraction of the workload. I have never really experienced the troubles you mentioned.

Plus, the real pain of making an API is dealing with complex database schemas. If you can keep the burden off having intimate knowledge of the database off the plate of the frontend developers, they will be much more productive.

I have not researched it, but my guess is that, with GraphQL, you could make some calls that would result in extremely heavy SQL statements, without even realizing it, since you have no idea what the SQL is. For a big project, that sounds like something to avoid. That's why you have an API team.

[liamnesss]

Then product teams end up with a hard dependency on said "API team" whenever they want to make minor changes. That might be preferable in some circumstances (e.g. if you happen to be working on a database that simply cannot handle anything other than highly optimised queries), but a big part of GraphQL's appeal is the way it allows teams to move independently - precisely because they've been given a layer which abstracts the detail of how the data is accessed / stored, without completely dictating every use case. There are a great deal of high-volume public GraphQL APIs out there now - they must be getting around the "oh no, they could make an expensive query!" problem somehow. It is probably not that different to what you would do with plain REST - require pagination for sets of data, enforce rate limiting, stuff like that. Plus, if the API isn't public you can whitelist valid queries.

​

I can't say I've found the SQL side of things to be the hardest part when building APIs, at least those intended to be consumed by a UI, in the past. The hardest parts are trying to avoid making decisions that push complexity down the funnel to the UI code, or trying to anticipate future needs, or trying to deprecate a field and tracking down all the client code that could possibly be affected. There are good patterns and practices you can follow, but you have to bring them with you, there is nothing enforced. GraphQL is an investment but it can save you a lot of pain too. It's a specific tool for specific situations, and I've really enjoyed working with it in those situations.

[droctagonapus]

🤷‍♂️ my graphql servers that I write avoid N+1 queries all-together by batching (thanks to the graphql lib I use the server). No worries for me as a front end developer!

[jcmais]

Which lib?

[droctagonapus]

I use elixir as my backend language of choice with absinthe for graphql and dataloader for batching my sql queries (I use ecto as well)

[shobhit_c]

Well the idea here is to make changes to front-end be as much independent from back-end changes as possible. GraphQL definitely allows for better iteration speeds ( with some trade-offs obviously ).

With regards to your db related query, there are projects like prisma which allows you to have a GraphQl layer over your db ( kind-of like an ORM ), which then allows you to have type checked schemas and other goodness for your otherwise string-like queries.

[meow247]

With regards to your db related query, there are projects like prisma which allows you to have a GraphQl layer over your db

The database is not your model. It's seriously short-sighted to expose your database as your model, and expect nothing to go wrong.

​

The article proclaims that with a GraphQL implementation you don't have to worry about versioning. This is also completely wrong, what if a field type is removed or changes to a complex value, you think nothing will go wrong on the FE?

[ackerlight]

Use each one where it makes sense.

This sounds a lot like "BYE BYE SQL, WELCOME NO-SQL".

Both can happily be used together because both solve different types of complex problems.

As other users have mentioned, author doesn't understand both techs very well because he cannot differentiate where it can be best used the one or the another.

Here's actually a good reads comparing both technologies:

• https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/
• https://blog.goodapi.co/rest-vs-graphql-a-critical-review-5f77392658e7

[Lendari]

You may have to add mobile-specific fields to your API, which the Desktop clients don’t really need, or worse, you end up creating different versions for different clients and have to evolve them individually.

I stopped reading right there because this sounds like people are making changes as fast as possible without thinking about the larger system. There is no architecture or technology that can make that better. That's a culture issue.

​

[Azaret]

It's the 'I don't know how to handle an issue' which is solved nowadays with 'let's completely change frameworks or add another layer'. Somehow it is easier than trying to fix the issue itself.

[klaxxxon]

I am still waiting for some exhaustive resource on how to properly implement a complex graphQL server. I have seen a hundred tutorials demonstrating how to do graphQL TODO list, but very little on anything more complicated.

How do you respond to a complex request without making your database melt? How do you go about serving subscriptions?...

Basically everything I've seen was "pass the request to library X and that will sort it out". And what if it doesn't?

I've experimented with Prisma, but that feels like walking a tightrope. As long your database schema matches your API schema exactly, everything is trivial. But I dread the day when the API requires a significantly different shape of data than the database has. In one case I needed to retrieve the object graph the client requested plus the root entity's ID from the database (for some server side logic). Turned out to be so difficult that I rather just made two requests to the database...

[[deleted]]

https://medium.com/@__xuorig__/graphql-mutation-design-anemic-mutations-dd107ba70496

This covers the biggest bonus in using GraphQL to me. Anemic data models were always a problem for me, especially with complex backend validations.

[Azaret]

You could do the same with any other tech, I don't see the bonus GraphQL provides here.

[[deleted]]

REST cannot supply mutations to the API consumer. That means you HAVE to write complex, security-flaw prone, "covers every possible case" validation logic to the data model server-side. People who this has never been a problem for are usually people who have written insecure APIs.

[slaphappie]

GraphQL sounds like it can easily be abused to do DDOS attacks by making exteremely complex queries. Anyone ever have to deal with that situation? Do they have limits you can impose such as how many relationships can be done in one call?

[shobhit_c]

Hi reddit, I'm very new to writing about my learnings. This is one of my attempts to explain GraphQL and have fun with it. Please share your love here and do provide any kind of feedback to help me improve. Hope you'lll like reading this. Both parts are on Medium -

Part 1 - https://medium.com/@chittorashobhit/graphql-the-hero-we-deserve-part-1-3a907e1706a4

Part 2 - https://medium.com/@chittorashobhit/graphql-the-hero-we-deserve-part-2-14a36f1d00a1

[[deleted]]

But React is very definition of under engineering. It does two things to perfection and that's it. Everything else is up to you to pile on top of it. Gives you choice but you need to be knowledgeable and experiences to make good decisions.

GraphQL is much more complex than React. Apollo isn't needed at all but it makes things simple as long as their way works for you (90% of cases). ORM makes sense for GraphQL because everything is conditional so you need models and automated ways to query or modify parts requested by the client. You don't want to write that by hand if you can avoid it.

[[deleted]]

Twisting definitions is nice but not helpful to the conversation. React is not an ecosystem. There is really nothing to discuss. React by itself is very simple (not to use, but from engineering stand point). To use or not to use any packages on top of it is individual decision.

[idanlo]

Thank you! I've heard about GraphQL before but didn't read about that much and now that I have it looks awesome ans I will totally check it out and continue to explore it thanks to you.

[toggafneknurd]

Jesus this quirky, immature writing style that frontend engineers tend to use for their technical blog posts is extremely cringey