Six Years Later, I’m Over GraphQL

[@Malix_Labs]

So we Structure our QL now ?

[@Winnetou17]

This needs more upvotes

[@lbgstzockt8493]

tech is cyclic, web dev double so

[@SeriesFrontend]

Do not pronounce QL in spanish.

[@fahimp3]

😂🤣

[@RaZziaN1]

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

[@deadchannel8431]

U watch the video?

[@greidinger-reis]

Where did he change anything?

[@DanielBogusz]

@@greidinger-reiseg. trpc to server components

[@hanzo2001]

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

[@dyto2287]

The initial idea for it was to make make single API composition of our multiple REST APIs. It would perform repeated calls to REST to extend data closer to backend reducing latency and allow frontend devs to select only the things they need. But of course, people started using it everywhere and now it's shit.

[@TheHadrian54]

Well, a facebook blog about the creation of GraphQL: "When we built Facebook’s mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple enough to be easy to learn and use by our product developers."

[@AlexandruVoda]

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.

[@brahimbenfares1464]

Everyone is just afraid of rawdoggin some SQUEAL

[@SaschaBecker-k8p]

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.

[@comboschtap]

Are you using Apollo Server?

[@SaschaBecker-k8p]

@@comboschtap yes, via nestjs

[@Omnifarious0]

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.

[@minnow1337]

wundergraph has an open source backend for frontend framework which allows you to select queries from your graphql schema and generates a rpc server + client codegen limited to those queries. Seemed like a really elegant solution but it’s abandonware now in favor of their federated graphql router

[@redhotbits]

you can use graphql in development and convert it to restapi for production

[@agungdewandaru]

precisely. not to mention possibility of additional processing overhead that may incur. we could see it coming and thankfully skipped the hype altogether.

[@MrSofazocker]

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

[@sbogdaniuk]

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

[@Edwin-nl3qu]

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.

[@rthomasv3]

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.

[@armanomidi4859]

maybe you haven't learned enough to work with GraphQL and how to optimize your queries over db

[@tuananhdo1870]

because you are lazy

[@comboschtap]

Have you tried Apollo Server?

[@MadsterV]

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.

[@killswitch.]

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

[@Grumpicles]

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.

[@jackwright517]

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!

[@lcarsos]

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.

[@gamerzero6085]

"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

[@marcuss.abildskov7175]

Theo is a web developer. He knows nothing about software engineering.

[@O_Eduardo]

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

[@O_Eduardo]

@hellotherenameishere There're too many cons, simply don't worth it. Eventually, you'll see.

[@ian2neko]

​@@O_Eduardo I saw frontend devs decided to grab all properties and use only those he/she actually need then. ummm....

[@oneeyefpv]

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.

[@BCRooke1]

TIL about grpc-web. TBH I think most people don’t go this route because of the learning curve. But I’d agree grpc > trpc

[@rerere1569]

I used this on one of my previous jobs. The problem usually is that you still have quite big overhead, besides your frontend and backend you now need to maintain some sort of proxy to be able to request grpc from your browser. Ultimately it's an additional layer of abstraction and complexity, which might make debugging quite painful. Can totally see how it could be used by bigger teams tho, but we found it annoying back then

[@ケブ]

Many companies encode their requests to binary, grpc is nice.

[@hungrymusicwolf]

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.

[@jarrodhroberson]

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

[@user-abc855]

I think that REST with well documented Open API, or even better auto-generated Open API from backend code is the superior solution in combination with auto-generated API client from the Open API on the front-end, I guess literally every front-end technology/language has ability to generate such client. So basically we are receiving features declared by GraphQL and tRPC (I mean synchronization between FE and BE) without huge performance losses (In case GraphQL with Node.js) or without Typescript vendor lock with tRPC

[@sebastianmihaiprisacariu8975]

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

[@SonAyoD]

Everything is better with trpc

[@marcuss.abildskov7175]

trpc is a joke compared to deepkit rpc

[@QueeeeenZ]

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

[@hamburger--fries]

Same with Statamic but with Next (I honestly thought Nuxt was dead).

[@PhilipAlexanderHassialis]

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?

[@ea_naseer]

to be honest I don't like UML

[@MrLordLowbob]

@@ea_naseer design documents dont need to be UML though. even a swagger document can do a lot already

[@blenderpanzi]

Yeah, an up to date OpenAPI spec as the interface to program to sounds good enough for me, but then I've only ever worked in projects with two or three devs max.

[@j.r.r.tolkien8724]

As a solo developer I approve this. LOL.

[@PhilipAlexanderHassialis]

@@blenderpanzi yeah, YMMV. The projects I work on (well, more or less Arch-ing on these days) have at least 7-8 devs, so I end up mostly designing, owning and augmenting the design documents along with the product owner(s). Trust me, as long as everyone comes along for the ride and understand that software engineering is NOT a democracy, it all flows swiftly and smoothly.

[@andyjones11]

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.

[@maykefernandesdossantos7374]

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.

[@John2202W]

Great idea! Let’s call those predefined queries “procedures” and expose a TypeScript friendly way to invoke them remotely. We can call it a TypeScript remote procedure call or just TRPC for short!

[@ChrisSkene]

I think you're looking for persisted queries? Here is what that looks like in code: const response = await fetch(graphQlUrl, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ documentId: 'md5-query-hash-of-query', variables: { variableOne: '', variableTwo: '', }, }), });

[@maykefernandesdossantos7374]

@@ChrisSkene Interesting I didnt know about them

[@maykefernandesdossantos7374]

@@John2202W I am aware that the concept of such predefined query would basically mimic a REST request, and that's is my point hahahah can't graphql just leverage some of the things trpc does? idk the architecture would need to change in order to address the problems we saw here... I just don't know how or if would be possible.

[@maykefernandesdossantos7374]

​ @ChrisSkene That actually interesting, I didn't know about them, the concept would be similar but implemented 'natively' on the graphql architecture itself somehow, it seems that for now such implementation lives on the client side layer, Apollo has its own implementation of persistent queries, and I was wondering if that could actually become part of the grapqhl specs, a way to request predefined data ( much like rest API ) passing the name of a query, therefore making the "all you can query" style of grapqhl limited somehow because I do agree that setting authorization per field is way too cumbersome most of the time. but thanks for the tip on persisted queries I was looking for something like this!

[@joegaffney8006]

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

[@black-snow]

Errrr... Yes?

[@Saeid-Za]

Been using it for years now, I love it. Fully type safe rest APIs for any client in any language without the mumbo jumbo.

[@cyneostudio]

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

[@Holobrine]

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

[@steve-adams]

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.

[@hefoxed]

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.

[@MelroyvandenBerg]

I never liked graphql. And never will.

[@keffbarn]

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

[@yapdog]

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 🥺

[@MrSofazocker]

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

[@MadsterV]

big words look good on presentations, but are terrible in daily use.

[@ShadoFXPerino]

I thought that's intentional. Say "auth" and you have to implement both because you don't know which they want.

[@nikbl4k]

They must have scrum overlords and no waterfall

[@sabiw]

Clickbait title, what a suprise.

[@Jzhongzhi]

I mean it is Theo...

[@gusvanwes6192]

I've been seeing this a lot lately at KZbin. Not sure why it's happening

[@SPAHI43]

First time?

[@AndrieMC]

​@@Jzhongzhi Theos titles and thumbnails are so bad even chatgpt hates him, he sucks

[@Zeragamba]

​@@gusvanwes6192 Clickbait generates more clicks. The algorithm likes more clicks. Shows more videos with clickbait.

[@05xpeter]

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

[@yapdog]

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

[@Matt23488]

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.

[@chrisr236]

When I first heard of GraphQL many years ago, most of these fears seemed instantly obvious to me. I never used it in my projects. All this n+1 stuff, how did people not understand this immediately? Is it because of front end devs who never had to think about this?

[@jonathan-._.-]

badges are sent with the message now 🤔

[@comboschtap]

Uhm... regarding security risks mentioned... I am not convinced I should forget about GraphQL and under-estimate it, especially in a large company with distributed back-end teams and different data endpoints to maintain. Are we forgetting why the schemas are for? Are we forgetting about Apollo Server which I don't see being mentioned at all? Theo did not mention Apollo Server. He discussed GraphQL as a general technology, highlighting challenges with security, authorization, performance, and scalability, but he didn’t refer to Apollo Server’s tools or features that address many of these concerns. Apollo Server provides many of the built-in functionalities that mitigate the risks he mentioned, such as field-level authorization, query complexity limiting, and caching strategies. The omission of Apollo Server misses a significant part of how modern GraphQL setups, especially in larger or distributed environments, manage these exact issues.

[@minma02262]

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

[@duelarm]

Super agree

[@jay-cm]

Why so many of Theo's haters watch his videos? I don't get it.

[@naught0]

@@jay-cm Man is literally just reading an interesting blog post and they come out the woodwork lmao

[@minma02262]

@@jay-cm KZbin autoplay some video in the background while I do stuff

[@miettoisdev]

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.

[@Siderite]

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.

[@ReyhanJoseph]

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

[@pythagoran]

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

[@capability-snob]

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

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

[@cbaesemanai]

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.

[@VincentFulco]

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

[@DanielNistrean]

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.

[@bhumit070]

what problems are you facing?

[@John2202W]

Have you looked into options like trpc-openapi (or the newer fork, trpc-swagger)? They make it very easy to expose your tRPC procedures as REST endpoints following the openapi spec

[@bhumit070]

@@John2202W I haven’t use TRPC so asking

[@j.hoffmann]

Exposing APIs with tRPC is really easy with Next.js’s app router. Just create a route.tsx and fetch the data as you would in a page then return it. I can see how this could be annoying with a ton of endpoints though but the above comment has solutions for that.

[@neociber24]

Isn't trpc mean to be internal? Pretty sure you can expose them with the createCaller or whatever is called, or separate the query/mutation logic and use a service approach to use them in the API.

[@joninsley8]

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

[@br3nto]

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.

[@MadsterV]

because then you'd be running untrusted SQL in your database.

[@br3nto]

@@MadsterV no no. Just the syntax. Then map that to one or more persisted data sources. So much like what GraphQl does, except using the standard SQL syntax.

[@EricLouisYoung]

The abstraction of the types is the whole point.

[@br3nto]

@@EricLouisYoung thats what schemas are for. To define the structure of the data that can be queried.

[@paxdriver]

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.

[@axa993]

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

[@LucasLuengo]

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

[@victor95pc]

What is the big difficult related to authorization? I mean on REST we need to do the same thing, it's not like GraphQL introduce it as issue.

[@LucasLuengo]

@@victor95pc All the problems described for GraphQL are not inherent to GraphQL. You can also have N+1 problems in your REST API if you suck at making queries. I even think GraphQL makes it easier to dismantle these problems in smaller portions and reduce complexity like that. Even the badge issue that Theo describes could have happend in rest or gRPC or whatever.

[@victor95pc]

@@LucasLuengo Most of the issues in that post seems like a skill issue, even the one about re-running authorization checks, if you use Pundit the authorization result is cached by session, so even you run "authorize record, :update?" 10 times it will run only once... Also not that hard to save the result in the global object

[@mrdmajor]

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

[@Gordonfreems]

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

[@SazzadAhmedTuhin]

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

[@SpektRProduction]

Changing tires in mid-air

[@johnstarich]

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.

[@conceptcoder]

R u using Batik, unique clothes from Indonesia? 😊

[@1337GameDev]

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

[@omri9325]

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

[@xybersurfer]

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

[@rachitmishra1]

why not protobuf if it’s just about the schema?

[@matthewbeardsley7004]

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

[@Thaun_]

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

[@black-snow]

It was a draft and it expired. No QUERY for you, sir.

[@ShaharHarshuv]

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"

[@jpegjpg]

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.

[@jpegjpg]

​@@zhanezar Not being a dick by why can't 2 things be good? I like NY style pizza, Chicago deep dish and classic napoleon they are all good and all satisfy me in different ways. Choose the tool that makes sense. My stack at work uses both. All are alphanumeric data is accessed from graphql where as all our file based operations use rest? Why you might ask? Because graphQL is a better fit for the complex queries our customer wants on our data sets in our databases. Why still use REST? Because serving generic files in REST is easy and stupid complicated in graphql.

[@shamashel]

@@jpegjpg Because GraphQL fucking sucks when the consumer doesn't have a direct line of communication with you, and most companies don't have the luxury of having an on-call developer answer customer service requests. Also because GraphQL is a fucking nightmare to secure and ALL consumers outside of your organization are potential threat actors. If you're building an API for customers to use, GraphQL is one of the worst solutions possible. Did you not watch the video? That was literally one of the conclusions.

[@Noah-cv4zo]

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.

[@u007james]

same goes with supabase and firebase security rules

[@mubashir3]

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.

[@jackwright517]

What's wrong with Apollo client?

[@dkchen]

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.

[@kamalkamals]

with graphql u can use one of them, code first or schema first, code first more better

[@dkchen]

@@kamalkamals Still performance sucks on day one. I have to do caching and query optimizations to make sure its okay.

[@kamalkamals]

@@dkchen the performance of javascript + nodejs already suck with or without graphql

[@armanomidi4859]

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

[@RusuTraianCristian]

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.

[@fmri4301]

Did you bleach your teeth? They look good.

[@PapaVikingCodes]

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.

[@Ratstail91]

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.

[@IamFrancoisDillinger]

if you have $10 to waste, there are some decent courses on Udemy. I'm sure some youtube has a good course but I haven't found any myself.

[@kamalkamals]

what about a laaaaarge file of schema graphql !!!

[@jarrodhroberson]

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.

[@ephemer]

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

[@jmkacz]

At the start you appear to be praising graphql, but what you're actually thankful for is strong contracts between FE and BE.

[@eran2670]

aren't we all

[@ea_naseer]

is graphql a dsl?

[@minnow1337]

its in the name

[@thenecroyeti1]

Protobuf?!

[@youpele5226]

Whoa

[@SergeSavostin]

...until you start using it.

[@zlwuzlwu]

And ... tRPC

[@ZoranRavicTech]

Your issue with badges is completely unrelated to graphql. If the api is super slow then using a rest endpoint would not have sped it up. And the rest of the points boil down to inexperience. Just because you couldn't figure it out doesn't mean others couldn't.

[@mohitkumar-jv2bx]

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

[@valerysmirnov9535]

No one does that, so technically it's incorrect, but practically is

[@mohitkumar-jv2bx]

@@valerysmirnov9535 I wouldn't say none. Elasticseach's apis for getting documents are all GET apis(atleast they used to be last time i checked) Elasticseach has got a big userbase too. But i do get your point. My overarching point basically here is that Theo keeps getting things wrong. Sometimes because he wants paid promotions. Sometimes he just don't know stuff but acts like he does

[@jimiscott]

Some servers will actually reject your request if you do.

[@kd8437]

​@@jimiscott but it doesn't mean that this is a correct behavior. You can define a body for GET requests, this is not forbidden by HTTP specification.

[@kd8437]

@@valerysmirnov9535 Defining a body for GET request is not forbidden by HTTP protocol, so you can define it. That's the point. ElasticSearch uses it, OpenSearch uses it. This is correct technically and practically, Google and Amazon cloud services use it. There were event requests from community to add support for GET requests with body in Apolo Client for some optimization purposes. So, you are just wrong...

[@genericpotato7118]

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

[@xybersurfer]

yeah. it sounded like company politics was the main issue there

[@danhorus]

I understood it was not a persisted field, meaning they had to run lots of calculations to compute each badge on every request. In short: bad database and API designs

[@TurtleKwitty]

it was hogging the resources of the payments db, so payments werent able to go through quickly anymore

[@xybersurfer]

@@danhorus it sounded like a technically fixable problem

[@ermilburn02]

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

[@TurtleKwitty]

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.

[@PanosPitsi]

What? Expose the database? What are you on.

[@TurtleKwitty]

@@PanosPitsi PostgreSQL has fine grain permission xD I'm on firebase and supebase and all these backend as a service things exist universe, what universe are you in?

[@_BonsaiBen]

Yikes

[@iwsutw]

GraphQL is network masturbation - REST works with any backend technology lol 😂 or the web would be broken!!!

[@JeyPeyy]

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

[@br3nto]

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.

[@MadsterV]

disagree. We collectively abandoned Visual Basic. Code is simpler when people know what they are doing, or are led by someone who does.

[@br3nto]

@@MadsterV the reason is simple. When you develop a solution full stack, you can manage the code complexity from both ends, whereas, when you split the front end work from the backend work, each team must coordinate changes with the other, and often that’s time consuming, so instead, they implement all this complexity so they can defer communicating and coordinating with the other team. It leads to the creation of unnecessary code that could have otherwise been avoided. The better way to divide work is feature slicing. A person or team develops a feature across the entire stack. The complexity in that case is when features are interoperable…. Which is then more a design choice.