The Truth About GraphQL

Thank you Highlight for sponsoring!!! CHECK THEM OUT www.highlight.io/r/theo-graphql
GraphQL is great. It's not great for everyone. I think we need to acknowledge that more.
Highlight GraphQL Docs: www.highlight.io/docs/general...
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
S/O Ph4seOne for the awesome edit 🙏

[@unknownChungus]

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

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

[@JayStothard11]

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

[@maverick_entertainment21]

Please don't go down this lane. Graphql backend soon becomes too complex for big projects and even simple things take a lot of time to develop as you will try to reuse the existing scehmas to fit new field or property needs. I am speaking from my experience with a huge banking project. Its okay to take your time and create a REST based backend. It might be more verbose but it will do the job and will never block you. Graphql is a living nightmare for big teams/distributed teams/central applications. Focus on rest apis, microservices architecture, separation of concerns, tight cohesion and loose coupling principles. Never Never Never go for graphql. Its a shithole.

[@mubashir3]

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?

[@SaschaB2B]

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

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

[@dealloc]

Define "finely tuned" rest requests. Because every time I have had to interface with something like that, it's often been a combination of multiple endpoints or some implementation a custom query language, whether it's through the query params or request body-and often without reflection nor specification. It often ends up being a custom GraphQL-like implementation. Another problem with REST APIs is that they often want to be agnostic to the client, so it does not consider the UI and ends up putting more work on frontend to transform payloads from and to UI, rather than just being able to ask the backend "please return this data in this format" or "handle these fields as this format". Something that directives are really useful for in GraphQL. Note that I am talking about this in large projects with multiple teams (incl. product managers, QA folks, etc.) where GraphQL truly shines.

[@thegrumpydeveloper]

Rest is just so much time bikeshed around the how (what’s the fields property?), pagination, data types communication, put or patch or post, just things that don’t matter. Which api schema do we use? Open api or ad hoc or no docs at all? Instead we can spend our time on purely optimizing and monitoring our graphql. Also nothing kills more than a waterfall of requests.

[@mihaiii6720]

Hakshuallly you can fine tune graphql at some point

[@ra2enjoyer708]

@@dealloc GraphQL not being able to utilize http cache (and therefore not compatible with reverse proxies) ensures graphql will never be as performant as REST serving the same business logic. Also transforming data to suit UI needs is the whole purpose of having frontend as a separate domain in the first place.

[@dealloc]

@@ra2enjoyer708 With queries through GET requests, it is possible to utilize HTTP cache. Additionally you can cache at different levels, including operation in case you have large queries/mutations that are issued often to circumvent the need for parsing those operations each time, by just passing a unique ID.

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

[@abdelrahmankhalil]

api/v1 api/v2?

[@mattisovereighteen]

@@abdelrahmankhalil That's kind of orthogonal to the point though, yes at some point breaking changes need to be made, and then API versioning can help mitigate that. But if the entire schema is inferred, it's really hard to decide by looking at the code if the change was breaking, necessitating a new API URL

[@makkusu3866]

@@mattisovereighteen You can easily compare OpenAPI schemas. Also you can use tools like swagger-to-typescript which generate TS interfaces and API clients and then simply compare the generated output for new API schema vs old from git. This is how we achieve the thing you described on REST

[@mattisovereighteen]

@@makkusu3866 You certainly can. Generally generated code is not checked in to a repo, so it doesn't form part of code review, though. My point was about where the focus of the team is, if you're focussing on the schema being a deliverable in of itself, then writing a schema first and generating code from it is probably more helpful than generating a schema from code

[@christiaanlandman3837]

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

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

[@spilatino2888]

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

[@itslemonandrew]

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

[@zikado4994]

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 ?

[@jacobleslie8056]

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.

[@split227]

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

[@itsanishjain]

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.

[@andrewobrigewitsh]

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

[@atifmahmood7258]

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.

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

[@dalanxd]

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

[@nabinsaud4688]

Graphql is love ❤ with typescript apollo graphql specially

[@kdiffin903]

Good stuff keep it up

[@mixxxer]

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.

[@maw951]

I’m a “CTO” of a company that makes millions of dollars. This is my very first job as a self taught and I’m dev ing all sorts of things in the t3 stack. Can you help me ?

[@k00k]

Just curious, what stack did you end up doing for your REST implementation and what does the process look like that has your team loving it?

[@JT-mr3db]

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

[@theangelofspace155]

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?

[@lapulapucityrider3227]

Create a private npm package and add that to your projecy

[@richardmcsharry]

use a monorepo like nx or lerna (I prefer nx)

[@yuvalsteuer1123]

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 😍

[@simonkirsch6847]

Thanks for sharing!

[@magne6049]

this!

[@dev_vice1466]

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

[@Jdban]

Yup. This is basically his whole thing. It would be nice if he acknowledged it as a HUGE limiting factor

[@speedsociety9177]

exactly, it's completely disregarding mobile which is like 90% of our customer base in some international markets.

[@Narslimmus]

@@speedsociety9177 so is GraphQL or REST better for a shared backend in your experience? kind of left that point ambiguous or I didn't understand fully.

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

[@ramzisabra9235]

Dataloaders?

[@jackevansevo]

@@ramzisabra9235 I find this a pain in the arse compared to writing regular rest endpoints with SQL table joins.

[@ramzisabra9235]

​@@jackevansevo If you have good use case for GraphQL, batching with dataloaders solves the n+1 problem. Avoiding GraphQL, if you have a good use case for it, because of dataloaders, for some strange reason, being harder to write than regular REST endpoints with SQL table joins, is a poor decision - akin to throwing out the baby with the bathwater. REST being a better fit for the use case you have in mind is a good reason not to go with GraphQL. Batching (dataloaders) doesn't even register on the radar as a reason to avoid GraphQL - since you'll be writing your SQL queries in a completely different manner when implementing GraphQL resolvers rather than REST endpoints, so having dataloaders or not doesn't really matter in that regard.

[@jackevansevo]

@@ramzisabra9235 I never said I wouldn't pick graphql for this particular reason, was merely expressing a common pain point. I agree with your breakdown/analysis

[@Sairysss1]

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.

[@marvinkr]

What about Drizzle + tRPC for different teams?

[@Keisuki]

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.

[@SubVengeance]

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

[@complexity5545]

Nice to know. But that sounds like a bad move.

[@marcusrehn6915]

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.

[@Ratstail91]

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.

[@tech3425]

Plugalicious

[@Ratstail91]

@@tech3425 dude I just got author creation and querying working in the author-book demo... and nobody is patting me on the head. SUCH AN INJUSTICE.

[@tech3425]

@@Ratstail91 Haha, sometimes we gotta pat one out brother. All in good time 😉

[@stepci]

You could also give garph a try!

[@chambaderaphael8946]

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

[@cherubin7th]

GraphQL is a good example of the Facebook cargo culting.

[@ianbamsey3849]

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.

[@noctali8049]

Tech debt

[@ianbamsey3849]

@@noctali8049 no corners were cut when created. Just a legacy cost.

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

[@dealloc]

There's overhead associated with doing it through GraphQL. It also leaks the underlying database and its data layout into the client, if used directly to query from a client-side application. Your client should not have to know what data is in what table, but have clear defined queries and mutations that matches the UI. This way changes to the database have very little to no breaking changes on the client in case you need to change the underlying database layout, migrating data, etc. Otherwise you could just as well just accept SQL directly from the client and not even have to deal with the overhead of parsing to and AST, resolving directives and transforming in to SQL queries.

[@gdnight]

​@@dealloc I think people are conflating multiple things. Before talking about doing obviously insane things like letting a client basically run db queries, there is an interesting debate to be had for graphQL instead of SQL, for use by the backend only.

[@ra2enjoyer708]

@@gdnight That debate ends the moment "who is going to be responsible for fuckups caused by migration from SQL to graphQL?" question is brought up. It's not going to be DBAs, since they already have a lot of responsibilities for data safety. Neither backend devs will be elated to rewrite an entire backend codebase for the new flavour of data query language for what benefit exactly?

[@_____case]

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.

[@HappyCheeryChap]

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?

[@ccgarciab]

Probably that different teams in the same company want to minimize coordination overhead, but they can get in a meeting if needed. Different companies are generally unaware of the internal processes of each other.

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

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

[@WolfrostWasTaken]

It's the exact same flow for us except we use REST standard and you can actually pass a query parameter to "select" only the fields you actually want to see returned. This way we don't have to make a ton of endpoints for virtually the same thing

[@MrZadeak]

@@WolfrostWasTaken did the same when we knew before hand that there would be a lot of those kind of requests in the future. Need to do a little bit more work at the beginning but in the end it is better and easier to use.

[@benardallotey]

I’m not a fan of graphql, but the problem with this idea is that it’s generally slow. If I had to contact my backend team and have them add an endpoint to the backlog for every single view in our application that could become very tiring very quickly

[@samifouad]

that doesn't sound like REST, that seems like RPC and it's a maintenance/iteration nightmare compared to GraphQL and actual REST

[@none0n]

Exactly, it's just common sense.

[@tech3425]

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

[@dimkadenisov]

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

[@AnnaGottin]

8:56

[@maverick_entertainment21]

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.

[@VictorMachadoDeFranca]

there is always the option to use openapi generator

[@user-ut4hj7kc1t]

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

[@dameneko]

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

[@pokefreak2112]

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?

[@PolitiquePotontiele]

its fundamentally impossible Like imagine that you want to add another field in your ORM model and youre frontend At first you have to make a task ticket and wait some time(cuz no one would do it immediatly), then check it works fine and serialisators and tests doesnt break and only after this you can do your job as a frontend. By using hasura or directus even a manager can add a field to a model even without coding. I think its essential to be able to have flexible and discoverable queries(any graphql workspace allows you to discover which fields can be resolved).

[@coolassassin]

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

[@carmineingaldi47]

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

[@Rgotto2]

Swagger has entered the chat, and 2010 says hi

[@esquilo_atomico]

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

[@enricperpinya3375]

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!

[@PolitiquePotontiele]

Hiiii gRPC suits for MOA highload architectures and youll anyway have to implement some kind of API Gateway Its speed is incredible and fits nice for microservice's planned obsolescence. You just load your grpc schema into a new service and rewrite it It might be good if you have more than one backend service(like image server, delayed messages server,datalake(such as influx/clickhouse), data server etc)

[@magne6049]

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

[@mr.random8447]

TRPC not language agnostic

[@Sawashil]

What about OData?

[@quintencabo]

When you have a network type data it's great

[@arcanernz]

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.

[@WolfrostWasTaken]

The fact that AWS pushes you so hard to use Amplify is so scummy. The exact opposite of open source. Shit show for boomer companies to pay a lot for

[@stepci]

Have you tried using garph yet?

[@arcanernz]

@@stepci that looks pretty cool thanks.

[@arcanernz]

@@WolfrostWasTaken tell me about it. The problem with Amplify is that it does too much and when something goes wrong you have to reverse engineer it to fix things. Plus it replaces some of their own products like cdk/Sam/CloudFormation which if you’re already using a deployment automation frameworks why are you going to complicate your life with yet another framework that does the exact same thing but less configurable.

[@WolfrostWasTaken]

@@arcanernz YEAH.

[@serenitysoft]

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.

[@lapulapucityrider3227]

Hasura better for now I guess

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

[@skyhappy]

can you explain how they frequently abuse the GraphQL patterns and create schemas that are no better than REST?

[@ShaharHarshuv]

@@skyhappy For examble, putting a foreign id on the type instead of modeling the connection as an edge, creating new fields / types for entities that already exist instead of expanding existing ones etc. And that's not even considering naming convestions that are really hard for people to grasp (root query fields shoud be things, not action). It's a constant struggle and I don't like GraphQL as much because of that.

[@gentooman]

Your problem are your developers, not your technology.

[@nivaldolemos5280]

​@@gentooman but good tech should be stupid tolerant, as most people are brainlets.

[@ShaharHarshuv]

@@gentooman That's not a productive statement. A technology isn't worth a lot if it's really hard to understand how to use it. The fact that I (think) I understand it doesn't help me if most of my team doesn't. Also replacing the team will cost more than just staying in rest.

[@akahades11]

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

[@samuelschwager]

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

[@Leto2ndAtreides]

Sounds like GraphQL needs GPT-4...

[@256k_]

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

[@jayprakashpathak196]

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

[@smotch7533]

Could you please label your sponsored section.

[@lardosian]

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.

[@viperactual]

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

[@PieJee1]

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

[@xybersurfer]

this sounds more like a refactoring issue, or a lack of indirection

[@PieJee1]

@@xybersurfer nope it's not. Because the moment you change it in the backend you have to deal with all current users still being active in your frontend using the old property names (whether you deploy the new frontend or not). There are plenty of solutions for it, but most of them are either UX unfriendly or developer unfriendly for maintaining multiple versions of your API. Most developers don't even think about it and I've seen dozen of SPA's crashing when a new version is being deployed.

[@xybersurfer]

@@PieJee1 who said anything about users? if the front and back-end are in the same code base, then i would imagine that renaming something in the back-end with the IDE, could automatically rename it in the front-end. with both in the same code base you can also have static type checking, which i imagine avoids these crashes. theoretically it all depends on the available tools, and this is not specific to GraphQL, but i admit that i haven't found good enough tools for this. actually the coupling is usually not tight enough

[@PieJee1]

@@xybersurfer I've seen many projects that were not properly set up and that users were complaining the application no longer works after a deploy. In all those cases we had to say they had to do a hard page reload because the frontend was cached in their browser. In some cases a junior developer rolled back the last deployment thinking it's broken making it even worse. Yes you can change it in the IDE in a project with frontend and backend both written in typescript, but you can not force all users to do a hard page reload when you do apply changes. And even if you do handle it correctly, browsers are notorious for not handling it well (looking at browser session restore and import history from other browsers)

[@xybersurfer]

@@PieJee1 users not reloading the page, sounds like a solvable problem, which you also seem to be hinting at. yes browsers can be quirky, but i'm not convinced it's that bad, for this very specific feature, that you can't easily find something that works on all major browsers. there are so many possible ways to go about this. it only needs to be solved once

[@alekseiborsenkodev]

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

[@GoodLuck-dk3rg]

why http in backend case?

[@ShaharHarshuv]

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.

[@XxwookiedancerxX]

theo looking nice today 😍

[@RedCloudServices]

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

[@godisB2eenus]

I'd argue most APIs out there in the wild are not REST, as they don't follow the principles of Representational State Transfer. I guess that calling them Plain Old Http endpoints is not as catchy 🤓

[@RedCloudServices]

@@godisB2eenus exactly 😊

[@adela.k5463]

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

[@binaryfire]

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

[@vadimevseev669]

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

[@JeremyStover]

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

[@domfarr2968]

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.

[@godisB2eenus]

HATEOAS, which virtually nobody correctly implements in their "REST" APIs, is a poor approximation of a graph. Might as well represent your domain model as a graph, and come up with a standardised way to query it...wait a second

[@guillemgarcia3630]

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

[@ThomasWSmith-wm5xn]

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?

[@speedsociety9177]

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

[@nanonkay5669]

There are people that use graphql like an orm?

[@amirhmahmoodi4607]

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

[@dacam29]

Rest with Rest, so you can take a Rest and Rest in Peace without worries

[@lime8738]

Please make a Hasura video

[@glupilazni1399]

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.

[@josersleal]

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

[@DrewIsFail]

Graphql helps when you can't reuse your database schema.

[@gro967]

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

[@ra2enjoyer708]

Why didn't you name a real javascript network then?

[@d1ge]

hasura

[@dev_vice1466]

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

[@kamalkamals]

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

[@shanginn]

remember twitter...

[@ShaharHarshuv]

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.

[@oliverjumpertzme]

Disagree with the relay part here. No issues with a really-big-scale-federated GraphQL API serving millions of users in the streaming space. Apollo Client is just fine if your backend and API are designed well.

[@alexvass]

Thanks

[@soumojitchakraborty5021]

Hey! put a video the current economic problem in tech job market🙂

[@t3dotgg]

I have like 3

[@GuilhermeMG]

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

[@t3dotgg]

It is! That's the point of the video

[@fahimhussain1918]

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

[@godisB2eenus]

That argument ignores the fact that APIs exist for a reason. And modern REST is an evolution of Service Oriented Architecture in that sense. Server Side Rendering has existed for decades, and its main drawback is mixing data with presentation, and if you have to serve multiple clients (Web, various mobile platforms, 3rd parties, etc.) then you're stuck with implementing an api anyway. This need led to the proliferation of BFFs, and Frankenstein monster REST APIs that tried to cater for every need of this or that client. GraphQL solved that problem by exposing the domain model as a graph (and pretty much every business problem can be modeled as a graph) that can be queried by each client according to their needs, with type safety.

[@nightshade427]

Another strength of graphql is exposing apis to third parties for integration into your app.