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.
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.
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.
@@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.
@@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.
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.
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 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
@@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
@@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
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.
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...
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.
@@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.
@@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
Definitely not for everyone, we've been using Relay for the past 5 years and for anyone coming into GQL and relay new, don't be surprised if it takes a while to ramp up. But for a lot of use cases, once you learn what not to do and best practices, you can build stuff super fast and in parallel.
I 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.
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
@@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.
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
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.
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?
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 ?
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?
Very often you'll get the exact same if not better performance by simply adding generic "include" and "exclude" parameters to your REST endpoints, with far less complexity. Trimming 15KB of data from the server response might seem like a big deal, and it certainly can be for the client, but for the server it might make no performance difference whatsoever whether that data is fetched or not, especially with caching. It might even be forced to fetch most of the data anyway because downstream services (potentially external) don't support GraphQL.
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.
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.
@@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.
@@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?
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
The way my mind was blown when I realized GraphQL is just a fancy layer between the API and Frontend that basically takes the same amount of custom code for each endpoint. My n00b butt always thought it sat on top of the database and that the resolvers would be automatic (like it would know how to translate a GQL query to an SQL query, instead of you having to do that manually).
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.
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.
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 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.
@@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
@@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)
@@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
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.
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.
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.
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?
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.
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 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.
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.
"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.
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. :)
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.
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 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 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.
Theo - love your content. As a seasoned engineer (over 15 years), am i a horrible human being for not fully appreciating GraphQL? I totally get it the contract between frontend and backend, but I've come from a school of thought that showed me that REST can do just about everything GraphQL does, and as long as it's well documented, teams can still work together. I caved in at my startup (as CTO) and allowed our team (small team of engineers; 25 of them) to start implementing a GraphQL gateway, and it actually made our development worse, more complex... By their own admission, they're happy to revert and get back to REST... Edit; we implemented it around 2 years ago... Now it sits in a legacy codebase - all new services are strictly REST and the team loves it and is more efficient.
I’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 ?
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.
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 😍
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).
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
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!
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)
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
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 🤓
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.
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
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.
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.
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.
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.
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
What? I think that's a very big assumption to think most people are willing to adopt a fully typescript lifestyle, cause am not, I don't even really want to use Typescript for frontend stuff, but I have to
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?
Error log in graphQL is a non issue. If your backend guy don't know how to implement good error log in graphQL just replace him. What make graphQL great is the flexibility around a standard. Caching is not a big issue if you know how to implement it. On big projects graphQL advantage are incredibles, the overall economic gain can impact up to 10% in the whole Project. But if you are a lonely devloper involved in one man project is better you use your energy in something else and you use REST or in some case gRPC
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).
Apollo GraphQL is the best approach to work with GraphQL, especially if you use the 'code first approach', besides you get Apollo Federation 2, so you get all the perks to work with microservices architecture in graphs. Maybe you're kind of noob in the backend, seriously. PD: gRPC/tRPC don't solve over fetching.
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.
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.
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.
Hakshuallly you can fine tune graphql at some point
@@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.
@@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.
Hi theo, have you ever used swagger for documenting APIs?
6:49 what about hasura? that sits literally right between the server and your db
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.
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
api/v1
api/v2?
@@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
@@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
@@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
From what I'm understanding, most of these points depend on you writing both your frontend and backend in typescript
Yup. This is basically his whole thing. It would be nice if he acknowledged it as a HUGE limiting factor
exactly, it's completely disregarding mobile which is like 90% of our customer base in some international markets.
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.
Tech debt
@@noctali8049 no corners were cut when created. Just a legacy cost.
The solution is to get rid of GraphQL and not split devs into front and backend. Create middle-end teams. Complexity is the root of ALL evil.
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...
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.
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.
Dataloaders?
@@ramzisabra9235 I find this a pain in the arse compared to writing regular rest endpoints with SQL table joins.
@@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.
@@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
Definitely not for everyone, we've been using Relay for the past 5 years and for anyone coming into GQL and relay new, don't be surprised if it takes a while to ramp up. But for a lot of use cases, once you learn what not to do and best practices, you can build stuff super fast and in parallel.
I 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.
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
@@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.
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
that doesn't sound like REST, that seems like RPC and it's a maintenance/iteration nightmare compared to GraphQL and actual REST
Exactly, it's just common sense.
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.
How does GraphQL allow restricting data? Is there anything stopping someone requesting a Product together with all orders and customer data?
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?
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 ?
Theo I love your content, but why do you always have to appeal to authority 11:51 ?
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?
Create a private npm package and add that to your projecy
use a monorepo like nx or lerna (I prefer nx)
Very often you'll get the exact same if not better performance by simply adding generic "include" and "exclude" parameters to your REST endpoints, with far less complexity. Trimming 15KB of data from the server response might seem like a big deal, and it certainly can be for the client, but for the server it might make no performance difference whatsoever whether that data is fetched or not, especially with caching. It might even be forced to fetch most of the data anyway because downstream services (potentially external) don't support GraphQL.
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.
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.
@@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.
@@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?
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
The way my mind was blown when I realized GraphQL is just a fancy layer between the API and Frontend that basically takes the same amount of custom code for each endpoint. My n00b butt always thought it sat on top of the database and that the resolvers would be automatic (like it would know how to translate a GQL query to an SQL query, instead of you having to do that manually).
the answer to many doubts about graphql is in the graphql gateway API. Tryo it👍
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.
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.
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
this sounds more like a refactoring issue, or a lack of indirection
@@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.
@@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
@@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)
@@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
We had a joinMonster graphql endpoint that was fine until the queries got tricky. man the gnarly queries it generated were a huge issue.
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.
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.
Plugalicious
@@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.
@@Ratstail91 Haha, sometimes we gotta pat one out brother. All in good time 😉
You could also give garph a try!
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.
Upstairs looks like David Bowie, downstairs like Freddie Mercury. Dude, decide, what you want to be ...
working at a company that does only a few web services we're stuck with java on the backend and likely will be for a long time...
Need your backend and Fronten d to use the same Schema? Just use protobufs
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?
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.
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.
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
Have you tried using garph yet?
@@stepci that looks pretty cool thanks.
@@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.
@@arcanernz YEAH.
What about Drizzle + tRPC for different teams?
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.
"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.
Thanks
I understood that you think trpc is better solution if your frontend and backend live together, but what’s the solution if not?
TRPC not language agnostic
Great info! The jump cuts make it a bit hard to watch, so I ended up listening to most of it
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. :)
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.
So should I move to relay then when I'm currently using the apollo client? Or direct to react server components
As a primarily frontend dev, I hate graphql so much. 😞
I subbed for the stache, I have faith in your channel over that alone.
What are your thoughts on the Buf/Connect product suite? Looks like they are trying to make grpc-web great again.
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.
can you explain how they frequently abuse the GraphQL patterns and create schemas that are no better than REST?
@@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.
Your problem are your developers, not your technology.
@@gentooman but good tech should be stupid tolerant, as most people are brainlets.
@@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.
TRPC requires monolith that not everyone has. This creates adopting trpc on existing app difficult.
Theo - love your content.
As a seasoned engineer (over 15 years), am i a horrible human being for not fully appreciating GraphQL? I totally get it the contract between frontend and backend, but I've come from a school of thought that showed me that REST can do just about everything GraphQL does, and as long as it's well documented, teams can still work together. I caved in at my startup (as CTO) and allowed our team (small team of engineers; 25 of them) to start implementing a GraphQL gateway, and it actually made our development worse, more complex... By their own admission, they're happy to revert and get back to REST... Edit; we implemented it around 2 years ago... Now it sits in a legacy codebase - all new services are strictly REST and the team loves it and is more efficient.
I’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 ?
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?
Dgraph is a substitution for SQL though, and uses GraphQL as interface 😊
Nice to know. But that sounds like a bad move.
What about OData?
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.
As 15 years exp backender with around 4 years GQL I must say. Learn damn HTTP guys=)
why http in backend case?
there is always the option to use openapi generator
Graphql is love ❤ with typescript apollo graphql specially
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 😍
Thanks for sharing!
this!
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).
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
As a backend / data specialist, I appreciate this take.
A REST API with query parameters for fields, filters and relationships is a pretty solid alternative to GraphQL for many use cases.
U all living the good life, I have to use an API that returns a Json with a field "data" with a XML string 💀
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!
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)
what about Garph? It looks really promising as a best of both worlds of GraphQL and tRPC.
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
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 🤓
@@godisB2eenus exactly 😊
maybe the issue is having a backend team and a frontend team in the 1st place :P
Smartest comment I have read on the discussion
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.
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
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.
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.
Hasura better for now I guess
Could you please label your sponsored section.
GraphQL is a good example of the Facebook cargo culting.
I use GraphQL at work, and I don't like it. It's slow.
If you don’t use Relay framework, you don’t really utilize all the power of GraphQL with fragments and data collocation.
There are people that use graphql like an orm?
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.
2025, Ferrari + Adrian Newey + Lewis Hamilton = f1 dominance.
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.
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
What? I think that's a very big assumption to think most people are willing to adopt a fully typescript lifestyle, cause am not, I don't even really want to use Typescript for frontend stuff, but I have to
tRPC is bad for teams with complex systems that don’t fit inside a single Monorepo. GraphQL is a great alternative in this scenario
It is! That's the point of the video
When you have a network type data it's great
Swagger has entered the chat, and 2010 says hi
I would pay to not work with GraphQL, it's terrible. I hate averything about it.
never understand why some people think that gql may use like sql - this is crap
I love GraphQL, but it's a nightmare if implemented incorrectly. Good to meet you at the conference by the way. tRPG looks great!.
Unrelated.. but anyone else think Theo is starting to look like a bad guy from a Die Hard movie? James bond? 😂
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?
Trpc doesn't solve the over fetching problem that solve GraphQL, I'm not agree.
tfw i'm about to start a new position heavily involving graphql and see this video...
Error log in graphQL is a non issue. If your backend guy don't know how to implement good error log in graphQL just replace him.
What make graphQL great is the flexibility around a standard.
Caching is not a big issue if you know how to implement it.
On big projects graphQL advantage are incredibles, the overall economic gain can impact up to 10% in the whole Project.
But if you are a lonely devloper involved in one man project is better you use your energy in something else and you use REST or in some case gRPC
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?
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).
There is a lot of talk of a "React", but can you also use these patterns in a real JavaScript framework?
Why didn't you name a real javascript network then?
graphql wouldn't be as popular if people knew more about htmx
Sounds like GraphQL needs GPT-4...
Apollo GraphQL is the best approach to work with GraphQL, especially if you use the 'code first approach', besides you get Apollo Federation 2, so you get all the perks to work with microservices architecture in graphs. Maybe you're kind of noob in the backend, seriously. PD: gRPC/tRPC don't solve over fetching.
Over 2/3rds of the CPU time on the Twitch site is dealing with terrible Apollo cache behaviors. Agree to disagree 🫡
Thank you, mini primeagean!
remember twitter...
i should've known this was about trpc 🤦♂
Rtk query is better than trpc
I think that a lot of people actually just like the schema. Open api is shit to work with