GraphQL, tRPC, REST and more - Pick Your Poison 

YES EVENT QUEUES ARE BETTER FOR MICROSERVICE COMMS I SHOULD HAVE MENTIONED THAT I AM SORRY

For anyone wondering what the actually name for "GraphQL Resolver Gateway" is, its called GraphQL Mesh, and that mixed with GraphQL Hive is magic

the between server communication is likely better dealt with as an event, posted to an event queue / log rather than a realtime connection that could / will fail.

I think it quickly becomes a mess when microservices talk to each other. You could do that with a message queue instead. Microservices can put messages into this queue and read/listen to messages, and suddenly your architecture's dataflow is way more understandable. If you think about it long and hard, the microservices talking to each other problem is similar to two-way data binding, and the solution I'm proposing is similar to what Redux does to solve the issue in a sense. Unidirectional Data Flows on the server^^

Thanks for making this video! I've been a graphql dev for 1 year and while I've gotten used to the mechanics of the system, I've never really understood the "why" behind it all. I work at an online retail company and this "middle tier" project was started more than two years ago and changed hands a couple times, so now people like me have no idea what the original point even was. This video helped me form a better idea of what it's for, and what my company is still missing in order to better leverage this technology. I might even be able to impress my manager by formulating a well-defined plan for improvements.

In case of distributing requests between microservices, GraphQL can address this on it's own via GraphQL Federation. The same applies for requests initiate from one service to another. Instead of calling the service directly it calls the federation. This removes the requirement for the service to know about each other. The only information that the service needs is where the federation gateway is. This allows you to easily merge and split services without need for application wide refactoring.

I think that gap that you show between "ServerClient" is a really good way to visualize that use case, and how useful GraphQL will be in comparison to the opposite use case when the server + client are "touching". I went down the path of using GraphQL a couple of years ago, and I can see it being great when dealing with multiple languages and/or dev teams, or with 3rd party APIs where I'm only the client. But for my big project where I'm the solo fullstack dev, and using TypeScript on both the nodejs backend + also the frontend... over the last couple of years I've slowly realized that I was just making heaps of extra work for myself dealing with 2 typing systems (TS + GraphQL) instead of just the 1 (TS). Plus all the extra complexity of having to write queries in another language, and all the extra tooling needed there. Overall it's slowed the whole project down a lot, without really any benefit for this project in particular. My use case in this instance was pretty much the opposite of when GraphQL shines. I'm just about to start removing GraphQL from this project. It's my own system (not for a client), and the frontend is still in its infancy... somewhat due to graphql slowing me down. I'll be taking a look at tRPC, and either using that, or building something customized for myself that has some similarities. Either way, my project isn't going to be any less typesafe than graphql in the end.

It feels good that the same arguments I had some years ago during an internal discussion, that GraphQL is probably best utilized as a gateway to your whole microservice clusterfuck rather than talking to the db's itself. The gateway also prevents the frontend developer to know about the slight differences in naming between the different microservices, as they only need to care about the contract GraphQL schema defines./

Good video, good points. Ever since I learned GraphQL, it made me appreciate the art of crafting API's, and made me like to *start* with GraphQL schema's when designing new object-oriented systems. However, *my* very favorite feature of GraphQL is its introspection capabilities. I do wish the spec would "require" it to always be public, so that clients could reasonably employ tools that could dynamically generate UI's, or even new machine-to-machine processes, based solely on schemas..

This is a surprisingly good video given that I disagree with the two contentious points you make: 1. GraphQL shouldn’t be used directly in front of DBs. 2. GraphQL shouldn’t be used for inter-service queries. And here’s why: 1. The case for DB backed GraphQL APIs (e.g. Hasura) I think you're arguing against the idea of having micro-services use GraphQL to query their own data, and I 100% agree with that. However, the value of this tech when used correctly is as a rapid project accelerator that won't tie you into loads of tech debt down the line. Creating a schema directly in front of a DB is fine provided that the schema is a completely logical view of your domain, since in that case you’re free to change the implementation details later. Hasura makes this possible to do since you can create mapping rules that allow you to present your DB logically. Given how fast it is to create very performant services this way, it’s actually a really good option for start-ups and green-fields, and I’d particularly recommend it, since although it’ll allow you to get your tech. stack implemented quickly, the logical schema you (with care) end up, will mean you don’t get stuck with a monolith when it’s time to scale, and you have a really simple path to moving to something more scalable on the back-end as needed. You even say as much yourself, and I quote: > This is what I love about GraphQL. None of this back-end implementation detail exists to me anymore. 2. The case for using GraphQL for inter-service queries If the thing you really love about GraphQL is that none of the implementation detail need concern you as a front-end dev, then isn’t that an equally useful trait for other services on the back-end? Or, stated another way, if the benefit to this formal interface is the ability to change implementation detail provided queries flow through this interface, then isn’t it better that more of the traffic flows through it? You don't explicitly say why you disliked this pattern, but perhaps your objection is the performance hit from going through some additional resolvers. If so, then it’s worth noting that this doesn’t apply in the case that services are implemented as subgraphs, since in that case you can then either query them directly, or query them via a low latency router that adds no perceivable overhead. Thoughts?

A nice thing that you brought up here Theo is Data contract which is probably the most common problem that any software solution without proper planning face. Explicit schemas as contracts is a must. For the most complex systems, we even have dedicated versioned schema repositories nowadays thank god. GraphQL was one of the moves towards this in a more narrowed sense than when talking about architectures. Info near the definition, flexible and extensible metadata, all come very handy. Also a very bad practice I see a lot is to try to come up from the beginning with an ubiquitous data model that will not be needing updates any sooner (that is an illusion and probably it will become harder to cleanup those unwanted attrs and add useful ones ). My tip is, unless it is a very fundamental attribute of the particular entity wait until you implement the feature that will need the attribute. I get the creeps when i see those humongous entities that look like they came from an enterprise software of the 90s.

You should look into federated graphql. With that at the gateway each service maintains it's own schema. This provides a consistent interface for inter service requests.

I'd argue that the GraphQL client should always be considered as part of the frontend domain as most UIs are data-driven and frontenders knows best what data dependencies each component has. Over time frontenders needs to make changes to the frontend code, and then it'll lead to a much more streamlined and frictionless process if they adjust the graphql schema / resolver at the same time. If the frontenders needs to align and communicate with the backenders every time they need to make a change impacting the graphql sschema, it may risk leading to technical debt instead, as there's a big chance that a workaround will be taken instead if time is an issue. The graphql server as I see it is a BFF (Backend For Frontend), meaning its for moving complexity and business logic from the frontend/client/browser to instead handle and prepare it in the graphql server. Therefore there are very strong arguments for writing the graphql server in node.js (javascript, typescript, rescript, purescript or some other compile-to-js language). Other than that I agree about server to server comm should be gRPC, and that is is only intended as a thin interface/proxy without direct db connectivity... but the split between FE and BE is where I disagree. This is based on my experience from working this way.

I was told GraphQL is used over REST primary because you can tell it to "filter" the response and thus you get exactly what you want. The problem is, you can emulate this with REST too if you really wanted. Either in the query params or inside the body you can tell the server what you want then your REST api will filter it based of your request.

Awesome that you spent the time explaining this. I've seen crazy usages of GraphQL, even all the information on the client managing a client side database 🥺

hey @Theo, heard about federated graphql? Have a look, it does let you have individual services also speak graphql, then use apollo router as your gateway (no code, just deploy), then your individual services can talk to other services through the router as well.

we use Hasura in production its is actually quite amazing... our backend is written in golang using the gqlgen library and we auto generate around 5M lines of compliant golang code because of the graphql schema Hasura provides... Theo you fail to understand that companies operate in different levels. If my company is worth 1B+ do you really think we would use Hasura? Of course not, its better to build your own infrastructure because you have the cash/manpower to do so. Hasura is fundamentally game-changing for startups unders ~25M and can easily handles thousands of concurrent subscriptions through Hasura Cloud. There is a reason Hasura is worth so much these days, and you fail to understand Hasura for what it truly is. You can easily eject out of Hasura because it does NOT interfere with your postgres database whatsoever

Awesome explanation. I finally get it. Thanks theo!

I went through Apollo’s free courses, which are super high quality, and learned GraphQL was not for the project I was working on. I’m really glad I went through the courses still, because now I’ll know when to use it.

What's a problem to use gql as api gateway instead of REST(HTTP/JSON) API? For example to use `GraphQL Mesh` instead of Kong/Tyk/Ocelot/KrakenD etc.?

I really like Prisma lately. They seem to fix and work on the various issues.

Thanks for the great explanations.

This video really helped me understand the theoretical perspective of GraphQL. I was indeed viewing the whole concept like Hasura has designed..

With regards to microservices, GraphQL Federation can be used to provide a unified API while keeping services isolated; services define their schemas and ownerships. As for using GraphQL to communicate _between_ services, you'd be better off with using something like gRPC, Protobuf or other event queue systems alike. GraphQL only make sense when you want to expose APIs to one or more clients.

Another thing that I find GraphQL helpful is with defined schema, graphql client (apollo) can automatically merge same objects from different response which help consistency in the UI without manually doing in that in reducer or in react-query callback. How do you normally deal with this when you are using trpc/rest

Thank you Theo, reading comments I realize i'm not alone, I've worked with it before but never really understood it. I finally get why and where GraphQL is valuable.

At work our app uses GraphQL stitching to combine Hasura with some custom NestJS APIs. We're in the process of porting to a single tRPC server and it is SHOCKING how much code we're removing. To be fair, a lot of that code is generated. However, the more significant change is to our dev process where everything is 10x easier.

Theo can you explain why having graphql directly on a database is bad? Isn’t it just like a serverless implementation of graphql? I mean ultimately with hasura o assume there’s still a server in between the database and the client, or do I assume wrong?

I was thinking about the graphql between microservices - is it good idea to use GraphQL API for between microservices just to have a single API implementation over all infrastructure ? Then you can expose all these graph ql apis using the apollo federation/proxy service. The key thing to mention is, that microservices themselves will not communicate directly between each other but instead using kafka topics. What do you think about that Theo ?

Thank for creating content ❤

You didn’t give any real reasons why graphql server is bad. I recently started a project with aws and when looking for resources to connect my dynamodb tables to my front-end, aws-amplify came up among the first solutions with graphql the default. I think I agree it’s probably not the best route, but I like to know why.

I don’t often comment on videos but those I do are ones that help guide me in the right direction, light bulb moments if you will. It’s been a while since I’ve played around with programming and naturally things have changed a bit. I’ve been researching tools & tooling to possibly build small apps to manage my seemingly unmanageable life. TLDR: this was insightful

So wait, i am conflicted now, am i an idiot for using graphql for storing data i need from a graphql api into my database, and then also for fetching the data i need for my frontend ? I am very confused by this video

Very good explanation on how to use GraphQL. I have a question, what if we use GraphQL between each service and the Gateway? So, each Microservice exposes its own schema and the Gateway is in charge of resolving it according to the client's requests, in other words what I mean is, it is a bad idea to have graphql between the client and the server, but also to have it between each microservice and the gateway. Thanks

Dude this video is gold! And you are a star!

Not always true about databases, there’s graph database called dgraph, and it looks really nice there

Hasura is literally a server deployed as a microservice. It IS the server between the database and the client so it falls right in line with your "acceptable use cases for GraphQL" diagram. Memes and hot takes that paint the whole world black and white are great for driving Twitter and RU-vid engagement (here I am, engaging with your content) but at the very least you could try to do an honest review that adheres to your own "rules". If your take is that systems that have any kind of GraphQL -> SQL translation layer in their stack is evil at least be honest with yourself and viewers and say that instead of this nonsense about requiring a server in the middle.

Theo, that was exactly the question I asked myself yesterday.

I am planning to study graphql and this exactly what I am looking. But I have a question does the server built by REST API then graphql consumes it? please help me with this

GraphQL for server to server is perfectly valid use case. I have used it in production with 7 microservice and it was a pleasure to use. Each service just needs to expose an internal graphql schema at say /internal/graphql that can be consumed by other microservices.

why micros ervices swagger cannot be contract between backend and forentend? If I don't has too many micro services..

I have been using Wordpress as a headless CMS, and using WPGraphQL gives you real power, and its so superior to the WP Rest API, in a lot of ways. It allows you to just don’t really care about API routes defined by Wordpress, and just fetch your things (with a proper caching solution, which can be a problem using GQL…).

What are your thoughts on Postgraphile?

Hi Theo, I've only worked on the front end so far and now I just begun learning React for almost 1 week now learning useState and useEffect at the moment. What are the next things would you recommend I should focus on after React? I think Redux would be the next step? Maybe GraphQL after Redux? There is lots to learn and work on. At the moment I am focused on trying to create a scheduler App for myself. Kind of like a journal mixed with dates and goals you could set for yourself, not a to-do App. But my end goal is to land a job as a full stack developer with JavaScript as the client side and Java as the backend. I would appreciate your honest and brutal opinion, thank you Theo.

Senor, yo no speako English good. Do I understand correct: I use graphQL for server, and SQL for frontend si? Thanks!

Great info. New subscriber.

What is GQL solving better than JSON schema as a contract between teams (BE/FE) and generating TS types from those for clients to use?

I agree 100%. Have you used federation? (E.g. Apollo's solution for joining multiple graphql endpoints into one) would be curious to see your take on that pattern :-)

One of the few channels where I don't mind the clickbait titles, the content is always good.

Hasura is great for base CRUDs, an events driver to fire off serverless fns, while adding your own apis (more serverless fns) for business logic in highly efficient and no boilerplate ways. Did I mention serverless? And Hasura is the (graphql) gateway. Theo is right: He doesn't know what he is talking about. He like most are too stuck on microservices. Go serverless and event driven, then Hasura makes sense. PS. You also must hate Firebase. Me too, Firebase is a trap. Hasura is conceptually like Firebase as a BEaaS, but better in every way: complexity and performance scaling, transparent and open source, graphql ecosystem

"we define a schema and don't have to talk to each other anymore" - remembers me the time we used SOAP

Could someone please try to explain GraphQL to me? From what I've seen, it basically just looks like an ORM but for client-side fetching.

What do you think about graphql(appsync) used in AWS stack to implement crud access to dynamodb nosql table?

Thx.... your videos are helpful as always, keep up the good work Did you know the Mock Service Worker (npm: msw) , what dou you think about msw.

Could you please explain why querying DB from GQL server is bad idea, and what's wrong with Hasura?

What a nice content, gz

I was wondering why is what hasura or platformatic do so wrong, yes ofc depends on the scope of the project, some are out of scope of what those frameworks can do, but for simple stuff why not?

Great video. I just signed on to use a data company who uses GraphQL to access their data. I have many years of SQL and so far I am not a fan of GraphQL. No default aggregate / Count?? Because it is like you said for the UI and not the database. I need to ask this company on why they are using GraphQL as their interface to their database.

I'm using graphql for a new SAAS project and we designed it as a supergraph/gateway for all rest microservices so client all access the same graphql api and the rest API remain private into the cluster. sure you won't add logic on the database nor creating any kind of monolithic api for transforming to sql

Isn’t Hasura just auto-generating CRUD GraphQL (and recently REST) API, instead of querying DB’s using GraphQL? Also, can you share your thoughts on public GraphQL APIs?

How is it even possible to use GraphQL between the server and the DB? What database is supporting GraphQL queries??

Did I miss something or was standard REST not even mentioned? Isn't that also a way to separate Front and Back people?

I love this man. I just wanna get scolded for bad practices. Can you make a video on Prisma and ORMs in general next?

I still don't understand how gql is better than trpc for communication (assuming you use TS for your server ofc)... You could define typescript types for your BE-FE contract just as easily as you define a gql schema....only you don't need to use a different syntax for it....

What does it mean 'as long as its I/O performant' ?

We use javascript for things it's not meant for. Here's the thing, if the tool works well for your use case and there's no much bad trade-off, then you should ideal it.

Scoping this question to the 'fullstack dev working on a big solo project' Does having application data that can be modeled like an actual graph data structure come into play when thinking about using graphql? Or I am conflating the concepts like someone would with assuming Java and JavaScript being named similar means they are closely related?

Amazing!!

Thanks!

does traditional REST APIs make sense in your experience?

what about schema generation in something like MongoDB Atlas distributed app data DB. It would reach that boundary to talk to a db, but than other dbs can process data from it. and in this process you have a schema that represents data in a persistation layer, in the GraphQL API layer, and the UI Layer with react hooks for sofisticated data interaction and CRUD. anyway, just a train of thought, still a lot to be understood about these technologies.

Best explanation about GraphQL

Does Apollo Federation change anything about GraphQL

8:27 so graphql client is not good for real time and rapidly changing data?

This confirms my thought. I currently can't see any value in Graphql if all it does is describe a schema.

I wondered about the title of this video, so I went to google trends and guess what? For the last 5 years, searchs related to GraphQL are going well, especially on 2022. People is indeed very interested on GraphQL. So there you have it.

Okay, you are hands down the best tech RU-vidr.

As soon as you said "do not use graphql for you database", the first thing I did was check to see if thats exactly what I did😅

So you have multiple microservices that call the same database? Congrats! you have a distributed monolith) One of the biggest advantages of microservices is the ability to scale them independently. You just multiply it by 0 when you join everything in DB. With a schema like this you will end up using 600$ RDS DB instance on AWS (without traffic). I know this because I did this)

I just wish they have the "select *" operator. Having to write out / link the primitives each time is silly.

"when graphql happened for the first time ever there was a real line drawn between the backend and the frontend, that i didn't have to worry about the other side". That's not because of graphql, but the lack of basic knowledge about design patterns, SOLID principles, etc.

What Im really interested in ist the difference between graphql and odata. OData manages to solve the classical REST Problem of Over- and Underfetching by implementing standardised funktions. So why not use OData instead of graphql when both share the Same funktionality, while OData simplifies a Lot of bloatware

GraphQL sounds neat.... But yeah... I'm doing full stack as a solo dev on my project. I think I've kinda already done some of the stuff it does... Not sure if it would add much for the time it would take to learn GraphQL...

I hope it is

Even I have the question in my mind

Why can't you use a rest API to do this though? Can't you replace the graphQL server in this architecture with a rest API to do the same thing?

Would this mean that you would not recommend something like Hasura? We benefit greatly from shipping our new features faster, with some limitations of Hasura of course.

I don't understand the reference to Hasura, when it is interpreting postgres schema, plus reading some other metadata to generate an API (runs on a server). This API is communicated with via graphql to the client. I hardly expose any of the underlying database via Hasura, and mostly use more advanced postgres views and Hasura actions to define my full set of backend services, which then is all stitched together so my client can use it. Note, I am using Hasura for prototypes and getting into front end (which it has allowed me to do, while at the same time up skilling in postgres and getting my data model right. Am I misunderstanding how Hasura works? For me all it does is take the heavy backend effort away from maintaining a graphql able server. Definitely not going to attempt running it in my usual backend language, Python. However I know I could serve a model in Python and use Hasura actions or Remote schemas to integrate it (that part is not done using graphql)

What about typegraphql-prisma? Can someone share opinion?

Instructions unclear. Now using GraphQL for everything except client server state transfer

What is about Hasura?

much respect

Excellent. Another similar solution is provided by OData.

So the main thing that GraphQL solves, being the hard separation between FE and BE, is based on a middle contract layer. Doesn't Swagger/Openapi do this as well?

Apollo GraphQL Federation solves the problem he describes at 5:20

Why Gatsby use graphql see the template use with wordpress, and wordpress use php under the hood.

It would be interesting if you could properly address your beef with hasura. Perhaps a dedicated post explaining exactly why you don't like it? Or even discussion panel? I'll be there to meet your objections in a constructive way

RDBMS is a server, and User Service is a DB client application, so why, you say, shouldn't GQL be put between a client and a server?

First time i hear that people misuse GraphQL as a sort of new SQL. Eww. But i can see where the initial confusion could have come from. If you treat a backend service as just a Persistence thing that just happens to have a web interface you might get a wrong idea to use it there.

I fail to see why it is "bad" at server to server communication.