The Truth About GraphQL 

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

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.

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.

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...

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

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?

"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.

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

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.

I subbed for the stache, I have faith in your channel over that alone.

What are your thoughts on the Buf/Connect product suite? Looks like they are trying to make grpc-web great again.

We have had a good experience with Swagger and using semantic versioning. Need discipline about not deleting fields though without a major level version upgrade. Versioning over accept headers is also cleaner than in url versioning. We use query parameters to trim the objects for mobile, though our responses aren't as big as what your describing. We also get the benefits of using a CDN to cache things, which speeds things up and reduces our in cloud costs.

Amazing vid, Theo! Your content is invaluable! Totally agree with you in this one 🎉

So should I move to relay then when I'm currently using the apollo client? Or direct to react server components

Hi, this may sound dump but i can't really understand the difference of implementation between graphql layer frontend-database / frontend-server, could anyone explain please ?

Great info! The jump cuts make it a bit hard to watch, so I ended up listening to most of it

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.

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

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.

Yay for the Relay truth! love love. Stuck with python backends for good reasons. Relay + Graphql has been the best thing for us, but so many gotchas on both sides of that wall.

Good stuff keep it up

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.

Graphql is love ❤ with typescript apollo graphql specially

But isnt the limitation of trpc that you need to have a monolith? If yiu backend and fromtend are not in the same repo wont we limited to rest/graphql?

We had a joinMonster graphql endpoint that was fine until the queries got tricky. man the gnarly queries it generated were a huge issue.

As part of my work, I use Shopify's admin GraphQL API a *lot*. Problem is... I only ever really use it to update things, because what would I want to query from the admin API? I'm there to automatically update stuff on my store. If I'm only *ever* using mutations, what's even the point of GraphQL? As a result, my understanding is that most people continue using their REST API, which is slowly, slowly getting out of date as new features are implemented only in GQL and not in REST.

There is one great use case for GraphQL I am using currently, and it's read model for Event Sourced system. Your source of truth are events in your event store database, which are projected into relational database (postgres), and exposed via Postgraphile as GraphQL Schema (with Row Level Security policies). Postgraphile automatically generates GraphQL endpoints from your database schema which is efficient, includes pagination, follows best practices and conventions, and there is no need to write complex mappings manually which saves tons of time. There is no downsides of exposing something you are not supposed to, since it's just a Projection of your events that is designed for your read model, and it's also secured by the Row Level Security. Though I wouldn't use this approach for a regular systems without Projections.

Theo - love your content. As a seasoned engineer (over 15 years), am i a horrible human being for not fully appreciating GraphQL? I totally get it the contract between frontend and backend, but I've come from a school of thought that showed me that REST can do just about everything GraphQL does, and as long as it's well documented, teams can still work together. I caved in at my startup (as CTO) and allowed our team (small team of engineers; 25 of them) to start implementing a GraphQL gateway, and it actually made our development worse, more complex... By their own admission, they're happy to revert and get back to REST... Edit; we implemented it around 2 years ago... Now it sits in a legacy codebase - all new services are strictly REST and the team loves it and is more efficient.

I love GraphQL, but it's a nightmare if implemented incorrectly. Good to meet you at the conference by the way. tRPG looks great!.

Hey, you talked a lot about why you should "not" use Graphql btw your DB and server, would love to know why? and somewhere you mock Hasura as well. would be fun to know your view on this.

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.

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.

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.

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

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.

As a primarily frontend dev, I hate graphql so much. 😞

I think the real question we should be asking is why do we have separate backend and frontend teams, and why are they not communicating effectively?

In your table at 8:34 ... Why do "different teams" and "different companies" differ? What's the difference between them, that means they shouldn't use the same thing?

What about Drizzle + tRPC for different teams?

I have never used graqhQL in production so take it with a grain of salt, but my impression is that this technology shines when used to build API gateways/BFFs where the client needs to mostly read data from the backend and this data can be aggregated in few ways. Airbnb used it for creating a server-driven UI where the app layout changes a lot according to many complex rules. If you want to use GraphQL for implementing an API server that fetches data from DB it seems that it can get quite complex and inefficient. On the other hand, being schema based is not a GraphQL speciality...apart from choices that maybe can be seen as mor suitable for server-to-server communication (grpc,thrifth,avro) you can/should still be able to set up a REST API with openapi specs and generators as mean to enforce a contract. It's just that this doesn't come sort of for free as with GraphQL

Dgraph has chosen to implement a graph database with a GraphQL-like syntax as its native query language. Rather than using Cypher or Gremlin. A new standard graph database querying language called GQL is being standardized by ISO (who also define the SQL spec), but its probably many years from finalization.

I understood that you think trpc is better solution if your frontend and backend live together, but what’s the solution if not?

I used to work with Apollo and tRPC. for the past 3mo we’re using Garph. mind blown! It makes writing graphql ez and typesafe. amazing dev experience thus far. we love it 😍

There are alot different tools which can generate api layer for your app over yaml, which any language can generate to you. But it works way worse than graphQL contract, because you have huge gap in type definition and yaml cant cover all you need. I think we need to fix this REST issue, to make contracts easier to support and it will be way more intuitive than now

Dgraph is a substitution for SQL though, and uses GraphQL as interface 😊

Graphql broke our entire data access layer. Its hard to maintain and with enterprise projects it soon becomes a huge problem. Its hard to maintain, the underlying sql queries and parent child relationship soon give rise to a huge learning curve for new joiners. It also is prone to poor design and poorer evolution as enhancements pour in for each of the queries. There are huge enterprises that do well without using graphql. In my view, graphql is just like Devops - a huge propaganda of doing things a certain way and saying that it is the best way available.

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.

what about Garph? It looks really promising as a best of both worlds of GraphQL and tRPC.

In our project we had Frontend, Backend for Frondend, and real backend (the API). And first two parts were handled by FE team... And I actually do not find using GQL beneficial, since schema is handled by FE engineers. And what we basically do - we go to the API documentation provided from BE team and copy types to describe new thing in GQL. So basically with same result we could use the google spreadsheets or something :) How it helps? The only thing I can remember is that sometimes BE engineers could change their API without saying, and during bug investigation process you can find that there is a difference between schema and API documentation or actual response. So it works like an evidence for saying "It is not our fault!" :) Again google spreadsheets with limited access could do the same. :)

Theo I love your content, but why do you always have to appeal to authority 11:51 ?

there is always the option to use openapi generator

As a backend / data specialist, I appreciate this take.

My problem with GraphQL is it requires so much boiler plate to get the front-end and back-end to work correctly and some of the code-gen tooling is difficult to setup and use correctly. Theo didn't even mention the security vulnerability that exists with a normal GraphQL setup like being able to introspect or ddos using nested queries, etc. Even the AWS GraphQL service (AppSync) is no where near as robust as API Gateway since AppSync uses a non-standard GraphQL implementation making integration with React Apollo client difficult (they really want you to use Amplify which is not as robust) and is buggy when deploying new GraphQL schemas.

Could you please label your sponsored section.

What about OData?

TRPC not language agnostic

Swagger has entered the chat, and 2010 says hi

As 15 years exp backender with around 4 years GQL I must say. Learn damn HTTP guys=)

Problems with graphql is that your frontend and backend become tightly coupled because you can not easily rename a property in the backend without either replacing it entirely in the frontend as well or by thinking constantly with BC in mind

Hi Theo! You're always talking about tRPC, GraphQL and, at most, REST. Can you talk someday about gRPC and where it belongs? Can we use it to communicate backend and frontend? Thanks!

U all living the good life, I have to use an API that returns a Json with a field "data" with a XML string 💀

When you have a network type data it's great

Unrelated.. but anyone else think Theo is starting to look like a bad guy from a Die Hard movie? James bond? 😂

GraphQL is a good example of the Facebook cargo culting.

TRPC requires monolith that not everyone has. This creates adopting trpc on existing app difficult.

If you don’t use Relay framework, you don’t really utilize all the power of GraphQL with fragments and data collocation.

Sounds like GraphQL needs GPT-4...

This is a primary reason for WunderGraph. APIs are hard and GraphQL is just a single way to solve for certain things. Most people do GraphQL wrong - and for FE, they missed relay all together.

theo looking nice today 😍

There are people that use graphql like an orm?

Please make a Hasura video

tfw i'm about to start a new position heavily involving graphql and see this video...

Had that situation creating and maintaining a graphql schema using AWS Amplify in my my first gig being inexperienced, sometimes it was a nightmare if I made a mistake updating the schema.

hasura

We dont use js in our backend, now what, trpc?? you literally are pissing me off with this trpc thing

Standards? REST is not a formal standard or specification I wish it was but it is simply the most widely adopted best practice out there. To supplement this massive flaw we got Swagger then OpenAPI. And just like a silo SQL database you need a human developer to know all possible queries up front to setup smaller join tables for custom endpoints. If you want to avoid over fetching you end up with a bunch of endpoints. And React is massively popular but man oh man is TS or JS verbose. Any type of TS resolver needs to also be setup correctly and also at the mercy of a developer. GraphQL is a super nice solution for a query gateway

Interestingly regarding promotion of GraphQL you are all pointing at backend returning you massive amount of data what basically depends on backend development and not on type of communication. If you use GraphQL wrongly backend still could return you massive amount of data.

you have to admit it sounds pretty funny saying "as long as you stick to the schema and spec we agreed on" literally was always the case you just added a useless abstraction because... web?

maybe the issue is having a backend team and a frontend team in the 1st place :P

A REST API with query parameters for fields, filters and relationships is a pretty solid alternative to GraphQL for many use cases.

I think you are missing the point. The only exclusive benefit of GraphQL today is not type generation (you can do that with Swagger), but it's the fedrated architectre. The fact you can have independant microservices (subgraphs) that can contribute to the same types in a way that is transparent to the client and does not force the client to make multiple requests.

i should've known this was about trpc 🤦‍♂

Sport on!!!! I said this from day 1!!!!

Isn't the argument of TRPC and the Typescript stack completely ignoring GraphQL for mobile? In a large org with client apps for all platforms and many teams and backend services, federated GraphQL and a single Schema can be a huge productivity booster to the whole org, reduce costs by reducing overfetching of data, make complex architectures simpler (as the GraphQL router can handle simpler aggregation workloads) and overall just provide a better dev experience. There are also solutions to the caching problem nowadays (persisted queries, HTTP Caching).

Thanks

The api is badly implemented if the blog is too big. Given a nicely implemented restful api, data is released in small chunks, with links to fetch deep detail. Trying to avoid the smell with a technology like GQL is madness. GraphQL is a classic shine new thing that looks strong on a resume. I believe if you have multiple data sources of various types that need some type of aggregation GQL is a possibility but the investment is high. And what ever happened to cross functional teams where everyone has the same goal. 🤷🏻‍♂️ But I’m sure I’ve missed something.

graphql wouldn't be as popular if people knew more about htmx

I love you Theo, but you're just wrong. And i love GraphQL

your argument about pre fetching the data you need through server components is valid, but it fails to consider use cases such as pagination and lazy loading. fetching from the client is NOT dead, it must be done for smooth user experiences

remember twitter...

Seems like the "only benefit of graphql" you're describing can be solved for REST APIs using swagger. You also get the same type of contract binding, and type generation.

Laughs in grpc-web

When its a Theo video i press like before watching cause i know it will be a banger

tRPC is bad for teams with complex systems that don’t fit inside a single Monorepo. GraphQL is a great alternative in this scenario

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.

There is a lot of talk of a "React", but can you also use these patterns in a real JavaScript framework?

Two questions So should Facebook abandon GQL entirely? Is this video an ad?

never understand why some people think that gql may use like sql - this is crap

Trpc doesn't solve the over fetching problem that solve GraphQL, I'm not agree.

to use and implement schema graphql you have two ways, schema first or code first, the most easy way is code first, u can add dtos, models and resolvers then automatically. schema generated, so i not recommend using schema first cuz it will very hard if u working with medium or big project, i have experiences with resutfull and graphql, i found restfull is very hard to impl in client app, a lot of endpoints retreive all fields of object ...etc, trpc is good for small app and not for big app, so yeh graphql is very awesome