The Truth About GraphQL
HTML-код
- Опубликовано: 30 сен 2024
- Thank you Highlight for sponsoring!!! CHECK THEM OUT www.highlight....
GraphQL is great. It's not great for everyone. I think we need to acknowledge that more.
Highlight GraphQL Docs: www.highlight....
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 🙏
![Tee Grizzley - Blow for Blow (feat. J. Cole) [Official Video]](http://i.ytimg.com/vi/wNLN5xsx5dc/mqdefault.jpg)
Hi theo, have you ever used swagger for documenting APIs?
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.
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.
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.
I use GraphQL at work, and I don't like it. It's slow.
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).
As a primarily frontend dev, I hate graphql so much. 😞
I would pay to not work with GraphQL, it's terrible. I hate averything about it.
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.
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
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.
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.
6:49 what about hasura? that sits literally right between the server and your db
Theo I love your content, but why do you always have to appeal to authority 11:51 ?
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?
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.
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.
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 ?
TRPC not language agnostic
"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.
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.
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
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.
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)
I love you Theo, but you're just wrong. And i love GraphQL
Upstairs looks like David Bowie, downstairs like Freddie Mercury. Dude, decide, what you want to be ...
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?
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?
How does GraphQL allow restricting data? Is there anything stopping someone requesting a Product together with all orders and customer data?
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
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.
I've seen more poorly design GraphQL APIs than I have well-designed APIs
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!
We had a joinMonster graphql endpoint that was fine until the queries got tricky. man the gnarly queries it generated were a huge issue.
Unrelated.. but anyone else think Theo is starting to look like a bad guy from a Die Hard movie? James bond? 😂
As 15 years exp backender with around 4 years GQL I must say. Learn damn HTTP guys=)
why http in backend case?
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.
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.
Trpc doesn't solve the over fetching problem that solve GraphQL, I'm not agree.
GraphQL is a good example of the Facebook cargo culting.
the answer to many doubts about graphql is in the graphql gateway API. Tryo it👍
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 🫡
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.
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
GraphQl sucks for the back end devs
2025, Ferrari + Adrian Newey + Lewis Hamilton = f1 dominance.
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.
Graphql is love ❤ with typescript apollo graphql specially
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
there is always the option to use openapi generator
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).
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. :)
your facecut are so similar with indians
Or we could just render the page on the the server and get on with our lives. 😂 I kid, I know some UX needs to be more complicated, but for goodness sake if you can get 95% of the way there with pure SSR and a little JavaScript why adopt all this?
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
Integrating a 3rd party GQL api is always easier for me compared to a REST api.
Also Relay is not always faster than writing queries manually. Most of the time maybe, but you can do the same job manually. Disliking this video.
Sport on!!!! I said this from day 1!!!!
GraphQL did indeed "solve" the communication problem between Back-end and Front-end. But it didnt really. The teams still don't communicate with each other. Which means at the end, you're still shipping a shit project. All your doing is moving the issues forward making them a post-release issue. The real solution lies on management getting people to talk and work together.
TRPC requires monolith that not everyone has. This creates adopting trpc on existing app difficult.
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.
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.
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
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.
Thank you, mini primeagean!
If you don’t use Relay framework, you don’t really utilize all the power of GraphQL with fragments and data collocation.
U all living the good life, I have to use an API that returns a Json with a field "data" with a XML string 💀
what about Garph? It looks really promising as a best of both worlds of GraphQL and tRPC.
never understand why some people think that gql may use like sql - this is crap
tfw i'm about to start a new position heavily involving graphql and see this video...
hasura
I love GraphQL, but it's a nightmare if implemented incorrectly. Good to meet you at the conference by the way. tRPG looks great!.
I think that a lot of people actually just like the schema. Open api is shit to work with
Great info! The jump cuts make it a bit hard to watch, so I ended up listening to most of it
Graphql helps when you can't reuse your database schema.
graphql wouldn't be as popular if people knew more about htmx
Lol hasura.
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 about Drizzle + tRPC for different teams?
I subbed for the stache, I have faith in your channel over that alone.
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.
i should've known this was about trpc 🤦♂
remember twitter...
Sounds like GraphQL needs GPT-4...
As a backend / data specialist, I appreciate this take.
So should I move to relay then when I'm currently using the apollo client? Or direct to react server components
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.
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?
Thanks
Swagger has entered the chat, and 2010 says hi
What are your thoughts on the Buf/Connect product suite? Looks like they are trying to make grpc-web great again.
how much would you charge to say this to my ceo?
I understood that you think trpc is better solution if your frontend and backend live together, but what’s the solution if not?
8:56
Could you please label your sponsored section.
When you have a network type data it's great
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 😊
There are people that use graphql like an orm?
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
A REST API with query parameters for fields, filters and relationships is a pretty solid alternative to GraphQL for many use cases.