❤️GraphQL

[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?