As a backend developer with a big focus on database, query design, and security, GraphQL has always worried me. And the more I learn about it, the more I'm glad I decided not to use it.

So we Structure our QL now ?

For the majority of developers seeing this video.... just use rest, thank me later.

I may be misremembering but when I was first introduced to graphQL by some ex-colleagues circa 7 years ago, word on the street was that graphQL was not a replacement for your rest API. I thought it was supposed to be used on top of one or alongside it. Ignorance is bliss I suppose

As a database person, the fact that something called a dataloader pattern exists to soften the N+1 problem boggles the mind. We can do most things with just 1 SQL query and output it all into JSON too directly from that same query.

Well.. Theo is changing technologies every 3 months so no wonder..

"now you're building crazy DIY rate limiters" - Dude's clearly never used any full-featured backend framework. Pretty much all of them have that for graphql

Our BE team: We can't in GraphQL, we will use REST. Period!

Out all of the shitposting I've done over the years, the one tweet that got me mobbed on was basically saying exactly this back in 2022.. maybe with a little more color.

Clickbait title, what a suprise.

Using graphql for the last years over all our products. We can spin up new products really fast. Every developers knows how to handle things. Sure, eliminating codegen would be cool but that's not enough for me to shift to trpc.

It's always fascinating at what little detail can bring significant problems later on. I guessed chat history along with chat, but when I think about it badges makes perfect sense.

This fits with the paper I wrote a long time ago about why CORBA (long time ago, ugly, think binary WSDL (also a long time ago and ugly)) and other forms of RPC are a bad idea. The problem with GraphQL is that it exposes too much of your internal state to external users. In my paper I describe RPC as being about what you want the other side to do rather than the messages you want to exchange. And that's true, but the real problem there is that when giving the other side detailed instructions on what you want to do, it necessitates knowing a lot of internal details about how the other side functions. I wrote this paper in the 1990s, but you could look at it as advocating for REST APIs. Though that's a little too narrow of a reading. I intended to lump in things like SMTP as being well designed protocols. I mean, SMTP has numerous security flaws involving verifying senders, but that's not the kind of issue I was talking about.

I'm using GraphQL in production since 5 years, it's always one of my favorite technology ❤❤

What I like about GraphQL: you can track which data is being consumed, which added to tracking request source lets you track how information flows across your app, spot possible optimizations and speed up deprecation. With proper instrumentation, you'll do magic. What I don't like about GraphQL: code generation, additional load and effort, tying up all the infra to an additional standard, security complexity skyrockets. Unoptimized lookups is not a GraphQL problem, it's a design problem.

19:08 Great job by your editor with the seamless transition...as I watched this on stream, it's so different I almost didn't notice

Does TRPC make sense if we can query and mutate the data directly with server components?

Would be interesting to hear your thoughts on what tRPC does better than just regular server actions.

I just built my first fastapi endpoint for a react project I'm working on. I took 2 days longer than the 1 day I estimated because I felt compelled to make the json file it served an asyncio call, the fetch was through an async web worker in react, and the fson it serves updates only once per day so it is reprocessed server side to be ready and waiting as soon as it's updated. Did I go overboard or are we suggesting my anal retentive approach ought to be standard? Again, my first time, learning solo, sincerely curious. It sounds like you're suggesting I did as much as we ought to expect of backend to provide to front end.

0:10 - let me fix this for you. If you have a DESIGN DOCUMENT that SPECIFIES the REST API signatures and the back / front teams are communicating, then you don't need a monorepo, you don't need the same language, you don't need anything. Just a proper Tech Lead who will OWN and ENFORCE this document and an Architect who oversees the whole thing. But I guess, having people actually talk and create design documents is too much these days, huh?

20:49 In the php world, its common to have your endpoint for users accept query params to supplement additional fields on the request, which are themselves their own endpoints with authorization already included, (bcs they are their own seperate endpoints), but you can thus essentially make multiple requests with a single request from the client and get the combined data of both. For example, a user, and its posts. They are separate endpoints. But the user endpoint accept a param to supplement the user, data to include the users posts. Just like that. Also, rate limiting as a package lmao

6 years too late... seems like someone stopped sending the cheques

What about if API needs to be externally exposed for a mobile app? Can tRPC expose the endpoints?

What are you thoughts on openapi specs for the contracts of rest api's?

I never liked graphql. And never will.

Honestly, what you describe with the Twitch badges is a dev problem, not really GraphQL

just like “every slow car handles well” “every tech works well with every trival application”

badges are sent with the message now 🤔

They must have scrum overlords and no waterfall

I don't know... for the most part, it doesn't sound like GraphQL is the problem. It sounds to me like some devs don't have enough paranoia when creating APIs 🥺

I've used trpc and graphql, I can't put my finger on why but I'm more comfortable using graphql and find it more enjoyable to use 🙈 Graphql provides a level of power I just love. Even for... Simple projects. 😬 That have more servers than users. 🤣 But I agree with most of your points!

we use Nuxt for frontend and Symfony for backend and separate teams so GraphQL is really nice

Huh, i had heard of graphql but wasn't aware what it did. I can see why it's be useful, but the security issues and limitations just doesn't seem worth it, and I'd likely stick to rest. But I've also been coding since before rest itself was popular so I may be a bit stuck in the past. I've primarily worked in teams where everyone is full stack and so front end waiting for endpoints hasn't been an issue.

R u using Batik, unique clothes from Indonesia? 😊

Tbh front ends shouldn’t be making complex data queries, just request the component you need and get it whether it’s htmx or React server components

is graphql a dsl?

How about gRPC-web (on the client), and gRPC (on the server). The ProtoBuf compiler (protoc) has plugins for generating gRPC-web client (in JavaScript), as well as plugins for generating server side code in many languages.

Although GraphQL is an awesome solution where it fits, I don't often find places where it fits and if I do, I don't find cases where its advantages warrant the complexity of implementing it. This could be due to the bias caused by my level of experience and the type of work I tend to do; maybe this isn't as true in other contexts.

Going from REST to graphQL made me insist that my next job absolutely needed to be in a fullstack environment with something like TRPC.

Wonder what you will be “over” a few months from now, the influencer reality is so off from what devs have to work with and maintain

10:40 -- why do they not just call the function to get badges when you change it......

GraphQl does subscriptions with joins, can't do that with anything else I think.

absolutely nobody: THEO: *AND I TOOK THAT PERSONALLY*

13:37 no it's okay Theo. You're completely correct. Requiring every developer talk to every team for every graphql query they're going to make to get the green light that you won't take down the whole service absolutely does not scale. Shame on that team.

Give me graphql without the nesting and I'll be happy. Client-side we get all the benefits of type-safety, code-gen and introspection. Server-side we dont have to worry about N+1's and complex schema resolution on fields existing far down on the tree of GQL nodes.

Six years later I still never gave a single flying f about Graphql

aren't we all

Watching people have security problems in graphql makes me appreciate capnproto rpc even more

from a software engineering perspective i get why you justifiably throw overboard a whole technology and have keep changing technologies, because of these problems. but from a language or technology design perspective i think it's really dissatisfying, because there are some deeper issues here that cut across the tech being used, whether it's tRPC, GraphQL, REST. especially caching issues and the N+1 problem

I never even jumped on the GraphQL train. It just never made sense for me. I have always worked on relatively small teams of full-stack devs, so I have always had control over both sides of the API. And with unit testing ensuring that the two don't get out of sync, it was never worth the time to even learn GraphQL in the first place.

I wanted to love it (on AWS) but I came to hate it and moved on.

Wouldnt it be amazing if inside the graphql ecosystem we could create pre defined queries that could be executed by name and possibly optional arguments as well, therefore the request could be something line: { query: "query name", args: [] } This is a layer I couldn't find anywhere in the specs of the architecture, also the possibility to isolate "contexts" would be amazing, making free to custom query just part of the data not the entire schema.

My one gripe is the argument right at the end about "front-end bugging back-end" in non-GraphQL APIs. I live in the SME world where we're either full-stack doing both, or, we collaborate and "bugging" people is an advantage becuse it leads to a thoughtful architecture where back-end understands how their services are actually being used. As developers we dont just "write code and call stuff". Everything is done with intent and should ve done thoughtfully.

There is currently an soon-to-be RFC that is basically POST with caching, named QUERY.

I think GraphQL shines the most when you expose it to the public. Of course, you have to be careful with security, throttling, and N+1 problems, but you are giving the best experience to the people consuming the API. They can get the schema, and query whatever they need

ClickbaitTube is so sad when "content creators" have to behave like National Enquirer and Star Magazine from the 1980's for engagement and views. 😥

Never used GraphQL, I am a REST API guy, but it sounds to me like all GraphQL issues could be solved by a policy to switch to REST when a query use is mature enough and never give GraphQL the resources to bring down the servers. Meaning that if you need something that works NOW and you don't want to wait for backend guys (as a backend guy I feel a bit offended 😛) just use GraphQL, but after a while that thing should be switched to REST when the endpoint is available. That being said, I've never worked in an environment where data queries were so complex and fast changing that I needed an extra DSL just to define what I want.

GraphQL is really good when you don't know how your endpoint will be consumed by a client, and when it's not possible to model a rest api in a good way to serve the data. Notion API is a perfect example when GraphQL would be better then REST for example...

How is the badges issue unique to GraphQL? It's just crappy backend work

0:10 GraphQL is not a good solution. In theory we should be able to write actual SQL and send to an endpoint. I don’t get why we need a limited version of that.

I don't hate it either but as a Devops / SRE there is nothing that has caused me more grief with performance issues than GraphQL.

same goes with supabase and firebase security rules

Whoa

I thought everyone knew about this already (except for the GraphQL fanboys)

Protobuf?!

what about a laaaaarge file of schema graphql !!!

Also, who tf came up with saying "Authentication and Authorization". So saying "auth" doesn't mean anything any more. Nice. What? It's always been Access Control. Authentication - Determining if the query is from whoe they say they are Permissions - Is he allowed to do that? Permissions, giving you the even more fine-grained terms of “Privileges” and making "Roles" a pretty obvious abstraction on top of that. But no, its auth and auth.... and everyones confused. lol

1:59 you know when you separate the front end development from back end development, the code seems to get a lot more complex. The code always seems to be simpler on apps where teams are full stack.

My biggest gripe of GraphQL is performance. You have to engineer a lot of stuff together to get the same level of performance of REST on the first day.

BE vs FE (different teams, technologies, repos, priorities, timing) is the hard truth on most coompanies. GraphQL allows FE devs to cut dependency times on their workflows and be more reliable on estimations. Most of the security / performance issues mentioned were also present in REST APIs a while ago. If anything, FE devs should be actively present in API design decisions, instead of ditching a very useful pattern because someone is not doing they job right.

To me, the type inferencing of GraphQL is like a happy accident. The reason you should use GraphQL is if you have many different API users and you want to allow the user to decide the shape of the data they pull.

It's annoying that you still try to sell GraphQL solely as an API schema solution, because it's not even the easiest way to do it. It's very easy to set up a similar kind of type-safety around a REST API, but using swagger/openapi schemas with code generation in any languages / technology so you don't have to have your backend and front-end shared. You can also host the schema ON the API endpoint so you don't have totechnically "share code"

Not sure it was intentional, but I don't think I understood WHY the badges-field was that big of an issue/why it was that heavy

tRPC is awful for exposing API's. Most projects I worked on in my career needed to expose API's so we ended up using tRPC for internal API and REST for exposing endpoints externally. I'm now the techlead on a project that has grown quite a bit and I'm deeply regretting buying into your hype with tRPC, I didn't do enough research. I plan to remove it from our system eventually.

...until you start using it.

And ... tRPC

Here's something funny - I wanted to learn graphQL, so I followed a bit of random advice online and tried to make a clone - sineQL works, but is unweildy to use. I still don't understand graphQL.

Just dont listen to theo. You will solve most your problem 😂😂😂😂😂

It was a terrible idea from day zero. For all the reasons I was telling my coworkers that thought it was this silver bullet to get front end devs to leave them alone. Dozens of projects ripped it all out in less than a year for all the reasons I told them would happen.

I always said k8s is overrated. It’s a great and powerful tool (we use it as well) but not everyone should employ it because not every system needs it.

The absolute funniest thing for me is that in a world where postgresql exists graphql is useless; if youre really at a point where you need graphql for some odd reason you might as well expose your db since it has all the security for doing that if you set it up (hello supabase) but for some reason reimplementing a slower (thanks to n+1 instead of letting the db handle internal re-queries) and less secure version is seen as a win but just doing the simple thing of using your db query language as the query language is seen as bad.

I don't think I've ever been this early to a Theo video...

Hasura and Neo4j have made awesome integrations with graphql that i think it's high time to start using graphql

Many of the problems discussed here are limitations of the tools used with GraphQL. Granted, making those tools is non-trivial, so one must weigh the tradeoffs. Sure, GraphQL isn’t as easy as setting up REST server backends. However, the point of GraphQL is to craft the best possible user experience, not necessarily the best backend developer experience. Many organizations don’t need this at the API layer, but some do.

If your app is the only consumer of your API you really don't need graphQL. If you are building an API for customers to user it's a fantastic solution.

Yikes

I get the feeling that Theo has never actually implemented/architected a good GraphQL pipeline. Only then would he understand the real value of it. For small and simple projects, he is correct. GraphQL is an overkill for those scenarios. However, for data intensive apps, GraphQL cannot be beat. For example our webapp has data tables that need to show large amounts of data. Thousands of rows. They need to be paginated, filtered, and sorted among other things. And we have several dozen tables that need to do this. This is the sort of thing where GraphQL really really shines. GraphQL libraries in the frontend and also at the backend do most of the work. They provide type safety, performance and so much more. Also, if you are not using Relay in the frontend, you are doing GraphQL wrong.

Theo please, you gotta get rid of these stupid thumbnails. And that mustache, it just doesn't fit you as well as it does on Prime

"You can't have a body in GET". Lol. Theo exposing himself in each video. 😂

SKILLS ISSUE please learn how to use GraphQL before reacting to it!

first

Entertaining content, but mostly bullshit.

This guy just won't stop talking.

Honestly stop speaking about programming / tech / dev. U re more a youtuber than a real programmer.

Graph for us is night and day. We pull data from three clouds and have multiple backend languages to support. Resolvers make it nice. Kubes and the works… it’s all bully in its own way. Good take.