The Truth About GraphQL

GraphQL is great. It's not great for everyone. I think we need to acknowledge that more.

S/O Ph4seOne for the awesome edit 🙏

[engineeranonymous]

Primarily as a backend developer I get why GraphQL is loved by frontend developers. Bu when you have to get some data from database it seems it will never be as fast as finely tuned rest requests. And yes you can set what fields you get in REST request from day one.

[LoveLearnShareGrow]

I work on a graphql middle tier, and I really appreciate your viewpoint here, especially how you break down where it does and doesn't make sense to use different technologies. I always loved the saying "The right tool for the right job" and it's reassuring to know that my company is using graphql in a way that is somewhere in the vicinity of correct.

[dev_vice]

From what I'm understanding, most of these points depend on you writing both your frontend and backend in typescript

[mattisovereighteen]

Another benefit to GraphQL that, I think, is worth mentioning is ensuring backwards compatibility. We're building a React Native app, so the backend needs to be able to support requests made by a client that was written a long time ago. Having a schema written in GraphQL syntax, rather than being inferred by tRPC makes it super obvious which changes are breaking and which ones aren't

[unknownChungus]

Hi theo, have you ever used swagger for documenting APIs?

[JayStothard]

This rings so true to a conversation i'm currently having at work. I work for a company that has split front and backend straight down the middle and as a rule, no one works across both environments. When I joined the front end team were writing a proxy API that cached and filtered out the data they needed from the backend (this data was used elsewhere, it wasn't built with UI in mind). We moved this proxy API over to TRPC which was great from a front end experience, but it didn't solve a lot of the issues we were having with slow load times still (some of the data was too large to be cached and we couldn't cache sensitive data). We're now in the process of reccomending GraphQL for the. exact reasons outlined in this video, we need a structure for the company to communicate. I am slightly worried by it as a solution though as multiple teams own this code so there is a potential for this to be split into multiple GraphQL clients...

[MrZadeak]

I developed a bunch of backends in Java and kotlin. Usually the flow was the following. New business requirement: We need to render user page with user Id, name and photo.
In db we have those fields + a bunch of others(address, middle name and ect.)
We write endpoint, that fetch only specified data from db. Annotate it with swagger, so front-end devs will know the 'contract' of this endpoint. They use swagger to generate code to work with this data and use react to do fron-end. It is that simple. No unnecessary data is send.

[ianbamsey]

Not sure i fully agree with graphql being an organisational thing only. It's tech when you have a big back end legacy in java. Cannot justify a typescript rewrite of back end with big complex db.

[puopg]

Definitely not for everyone, we've been using Relay for the past 5 years and for anyone coming into GQL and relay new, don't be surprised if it takes a while to ramp up. But for a lot of use cases, once you learn what not to do and best practices, you can build stuff super fast and in parallel.

[LukePighetti]

I personally think if we had canonical batching in REST, we wouldn't have much appetite for GraphQL.

For me the best use case for GraphQL is "Backend For Frontend" or acting as an API gateway. People got way too deep on trying to do field level optimization and nested queries and the result is predictably complicated.

[jackevansevo]

Dealing with N+1 queries with graphql on certain occasions on the backbend can be an absolute nightmare depending on what tool/framework you're using.

[Ratstail]

I have trouble developing ONLY backend or ONLY frontend - I'm a fullstack dev. Still... I like the idea of graphQL, so much that I developed a simplified clone called sineQL, just to understand some of how it works under the hood.

[marcusrehn]

It's a perfect take, all I would add is that it was projects that could have countless independent frontends. If you have a 1:1 relationship, then it really doesnt make much sense inviting graphql into your tech stack. It's such a pain to implement on the server if you want it done correctly, and if you dont, then you shouldnt even start. Thats my opinion.
If a strict Rest approach is not working for you, make new endpoints that are not strictly Restfull, SOLVE YOUR BUSINESS NEEDS.

[Jdban]

"You can get all these benefits given you're willing to work in a fully typescript environment"

Yeah, that's not the reality most of the time. Lemme just tell the backend team I barely know to switch all their code from python/go/etc to Typescript which is missing all the libraries they need.

[gdnight]

After trying out graphQL in multiple projects in the past, I do also find it to be a pain at this point.
However, I don't understand the reasoning behind "graphQL does not belong in the database", you have said this countless times, yet I cannot remember any actual argumentation to support this view.

[jahelation]

The solution is to get rid of GraphQL and not split devs into front and backend. Create middle-end teams. Complexity is the root of ALL evil.

[itslemonandrew]

6:49 what about hasura? that sits literally right between the server and your db

[mubashir]

Honest question. With graphql and hot chocolate c# library I get free projections, streaming and pagination capabilities, among other thing. Do yo get them with trpc? Or you have to build them yourself?

[ShaharHarshuv]

When I first heard about GraphQL when we started implementing it in our codebase, I was really excited because I thought the idea of modeling your business logic in a graph that can be queried is awesome and super flexible. However - after more than a year of consistently trying to "explain" GraphQL to the team, most teams just don't get it. They frequently abuse the GraphQL patterns and create schemas that are no better than REST, and there is STILL not enough communication in the teams. I end up learning about bad design in GraphQL from reviewing the FRONT-END pull request that implements work around to work with that. 🤦
The reality of having one team that is exclusively typescript and just write "function" to do stuff seem really good, but unfortunately that is not my reality.

[chambaderaphael]

the answer to many doubts about graphql is in the graphql gateway API. Tryo it👍