I go over the pros and cons of GraphQL vs REST that I experienced from creating 2 side projects with GraphQL. #graphql ---- Follow me online: voidpet.com/be... #benawad
Great video! Thanks! Stangely, I personally felt that moving to graphQL speed up my backend efficiency (I have a spring boot server and used graphql-java-tools library which is GREAT). My way of dealing with DB communication in graphQL is to follow exactly the same logic as I would in the rest version. Lets assume that we have a teacher entity that has relationship to many student entities. My REST api would work like that: 1. I have a quick rest controller that fetches the teachers without their students (no sql JOINS). 2. I have a less quick rest controller that fetches the teachers, but also performs the sql JOINS to include their students. 3. In the end of the day, my frontend would decide which URL to call, according to whether it needs the student lists or not. So my graphQL version would follow the same logic. Simply I would have 2 resolvers instead of 2 rest controllers. My DB queries would be exactly the same, and my frontend would decide which of those 2 it needs, exactly like the rest version.
@@bawad can you explain what you mean by that? Maybe provide an example that would be simpler in a rest implementation than in a graphQL implementation, and show the difference?
@@JustPlayerDE No. As long as you add fields you are not breaking the contract. Are you changing (e.g renaming / chaning types) or removing fields in either rest or graphql you are breaking the contract. In both instances you can deprecate the fields instead of removing them and let the consumers update the requests.
Exact same conclusion I came to. It's a pain on the backend using dataloaders with a database not tried and tested with graphql and finding your own solutions. But using graphql on the frontend is amazing.
About no need for GraphQL versions. Extending schema example that you provided would work with REST most of the times too, because it is backward compatible. How do you deal with backward incompatible changes, like removing or renaming a field/entity?
GraphQL seems to be most effective for organizations of multiple dev teams that are mostly independent (Facebook). When you are the sole consumer of your own API, you pretty much know what data you want and how you want it, so you can set up endpoints tailored to your necessities. Also, isn't simple validation a form of type system?
I think this is absolutely spot on again! I recently built a test project with Graphcool and Apollo on the frontend and it was an amazing experience. But although setting up an actual graphql server is quite a chore I think the payoff on the long run is worth it...
I'm going to give this a try. I've been working with ERPs for a very long time and thanks to questionable design, I've caught SQL tables with over 70 columns and tens of thousands of rows.... It's a pain to deal with under / over fetching for table display and report exporting.
Agreed. My vote is a Nexus 2 backend serving a Gatsby front end that uses `gatsby-browser` to show dynamic (frequently changing) data in a rehydrated React front end.
I don’t really like mutations but queries are good. GraphQL works best in a full stack JS environment. If you’re working outside of that it can be a pain with such a rigid type structure (say a Rails GraphQL API and a native iOS App) they don’t play nearly as nicely and a MERN stack app
We would have clients send a version number with each request, and we would deprecate fields, but continue supporting them. After a couple months, when we figured almost all clients had updated to using the non-deprecated fields, we would bump the lowest API version we supported, and clients that sent the older version would be redirected to update. That being said, this doesn't work great if other people are developing clients for your API.
IMO you don’t need a thick client or API. You can do all of it using good old fashioned server rendered templates. It will be far more performant than any SPA + API combo (especially when it comes to bundle size and TTI). If you’re a frontend dev who doesn’t know backend templating and you NEED react, use Nextjs static export and then do a fully serverless backend. All the other approaches give you the worst of both old style web pages and SPA’s...
I remember almost 10 months ago I chose gql for my personal full stack project for my resume to host on heroku to land a dev job, I read these advantages and thought maybe it'll be better since heroku free tier is slow as shit anyway so I made the gql choice
Controlling fields based on roles is a big problem in GraphQL - so much so that I reverted to Rest / ORM based ad-hoc query languages to avoid dealing with the potential security issues. Am I missing any tooling that could have made my life easier (other than doing DB-based auth in Hasura / PostGraphile etc.)
I've been looking all over the web and have failed to see how Graphql is secure compared to an API services that accesses the db and acts a secure bridge between data and the client 🤔
For the over/under fetching I remember designing a method where you input the fields you needed and only those would be selected from the database as opposed to select * : which gave me a similar effect but nice to know QL has it out the box
Can't we , instead of writing resolver for each field why not write resolver for each resource, also can't we rate limit the endpoint , ultimately whoever is going to call any query it is going to be a http call so we can block it right away there on the server side ?. what do you think ?
Would you say NestJS helps in the "no Ruby on Rails/Django yet" point? From my experience using Nest it really looked like and awesome Framework to build graphQL APIs
@@bawad Hi, what about nexus ? I saw the prisma team abandoned the GraphQL-yoga project to collaborate with nexus. I think GraphQL-yoga was pretty neat. Maybe nexus can become even better.
I don't think, that just adding new fields is a good idea. It will mess the project. Keep code clean and get rid of the deprecated stuff. A client side handling could be better.
I'm investigating a bit but honestly it looks like a waste of time. I rather learn AWS and if some day I get a assign some task of graphql I'll learn it there. It looks so much work for very little reward, unless you're facebook I guess
Queries sure look nice. Because at the moment my FE be like yield call(messages.find, { query: { $limit: limit, chat_id: id, $sort: { created_at: -1 } } }); While the NodeJS BE has like 50 line long sequelize query for the call above... Wtf? :D
@@bawad graphql-ruby appends RoR functionality, so you can just use RoR for graphql. Also, there are few startups using this gem, so there should not be a bigger problems with creating 'real' apps
GraphQL sucks. There is to many tools and the tutorial don't follow the thin red line. It forced typescript even if its not enabled. It makes me like PHP which means something.
I would really. love a tutorial video on automatically generating the queries with the react hooks. Awesome video!
Great video! Thanks!
Stangely, I personally felt that moving to graphQL speed up my backend efficiency (I have a spring boot server and used graphql-java-tools library which is GREAT).
My way of dealing with DB communication in graphQL is to follow exactly the same logic as I would in the rest version.
Lets assume that we have a teacher entity that has relationship to many student entities.
My REST api would work like that:
1. I have a quick rest controller that fetches the teachers without their students (no sql JOINS).
2. I have a less quick rest controller that fetches the teachers, but also performs the sql JOINS to include their students.
3. In the end of the day, my frontend would decide which URL to call, according to whether it needs the student lists or not.
So my graphQL version would follow the same logic. Simply I would have 2 resolvers instead of 2 rest controllers. My DB queries would be exactly the same, and my frontend would decide which of those 2 it needs, exactly like the rest version.
I agree and that's nice, but to do that properly (or efficiently) in graphql where you only join on some queries is more complex
@@bawad I see. What do you think that would be different/less complex in the rest version?
making the routes efficient
@@bawad can you explain what you mean by that? Maybe provide an example that would be simpler in a rest implementation than in a graphQL implementation, and show the difference?
@@alkismavridis1 nope lol
You don't need to change REST version if you are adding field either.
but if you change what it returns
@@JustPlayerDE No. As long as you add fields you are not breaking the contract. Are you changing (e.g renaming / chaning types) or removing fields in either rest or graphql you are breaking the contract. In both instances you can deprecate the fields instead of removing them and let the consumers update the requests.
Best channel i've ever found on youtube until now.
Exact same conclusion I came to. It's a pain on the backend using dataloaders with a database not tried and tested with graphql and finding your own solutions. But using graphql on the frontend is amazing.
Exactly the question in my mind recently
Damn. Best GraphQL overview I have seen on UA-cam. Great job!
Thanks Ben for sharing this valuable information 😊
I like the integration of GraphQL with Nest.
Bro you are always on point, I love it. Keep up the good work
Thanks man, was offered a gql, redux-saga ,apollo, react fullstack dev contract, but now i see what i have to deal with if i take the job.
About no need for GraphQL versions. Extending schema example that you provided would work with REST most of the times too, because it is backward compatible. How do you deal with backward incompatible changes, like removing or renaming a field/entity?
GraphQL seems to be most effective for organizations of multiple dev teams that are mostly independent (Facebook). When you are the sole consumer of your own API, you pretty much know what data you want and how you want it, so you can set up endpoints tailored to your necessities. Also, isn't simple validation a form of type system?
I think this is absolutely spot on again! I recently built a test project with Graphcool and Apollo on the frontend and it was an amazing experience. But although setting up an actual graphql server is quite a chore I think the payoff on the long run is worth it...
Ben, may you please open source your 2 side projects. It would be very awesome to see the actual code of such awesome stuff. Cheers.
I want to try monetizing them so I'm not going to open source it at this time
Cheers man, these videos are absolutely fantastic
I'm going to give this a try. I've been working with ERPs for a very long time and thanks to questionable design, I've caught SQL tables with over 70 columns and tens of thousands of rows.... It's a pain to deal with under / over fetching for table display and report exporting.
i miss the projet videos ;(
Agreed. My vote is a Nexus 2 backend serving a Gatsby front end that uses `gatsby-browser` to show dynamic (frequently changing) data in a rehydrated React front end.
I tried graphql but switched back to django because of several reasons like pagination, rate limiting, caching, authentication, authorization etc
Graphql and django are perfectly compatible
One is a way to define an api and another is backend framework
@@migueldomingos4570 Sorry I meant to say django rest framework
@@piby1802 ah! ok! I wasnt aware graphql had such enourmous disanvanatges
I don’t really like mutations but queries are good. GraphQL works best in a full stack JS environment. If you’re working outside of that it can be a pain with such a rigid type structure (say a Rails GraphQL API and a native iOS App) they don’t play nearly as nicely and a MERN stack app
2:15 - you either do or you don't, except when you're unsure; then you doon't.
Thanks for info as always.
I like the thumbnail XD
Thanks as always Ben :)
How do you addressing breaking changes such as removing fields?
By not removing fields for a long time
We would have clients send a version number with each request, and we would deprecate fields, but continue supporting them.
After a couple months, when we figured almost all clients had updated to using the non-deprecated fields, we would bump the lowest API version we supported, and clients that sent the older version would be redirected to update.
That being said, this doesn't work great if other people are developing clients for your API.
IMO you don’t need a thick client or API. You can do all of it using good old fashioned server rendered templates. It will be far more performant than any SPA + API combo (especially when it comes to bundle size and TTI). If you’re a frontend dev who doesn’t know backend templating and you NEED react, use Nextjs static export and then do a fully serverless backend. All the other approaches give you the worst of both old style web pages and SPA’s...
Great! Thanks for sharing!
Hey, I think you would be interested in restful-react. It has some of the functionality that you mention liking about graphql with apollo
good to know, thanks
I remember almost 10 months ago I chose gql for my personal full stack project for my resume to host on heroku to land a dev job, I read these advantages and thought maybe it'll be better since heroku free tier is slow as shit anyway so I made the gql choice
Did you end up landing a job and did learning graphql help?
Controlling fields based on roles is a big problem in GraphQL - so much so that I reverted to Rest / ORM based ad-hoc query languages to avoid dealing with the potential security issues. Am I missing any tooling that could have made my life easier (other than doing DB-based auth in Hasura / PostGraphile etc.)
I run middleware before resolvers for that, works pretty well
If you want that tooling but for REST you can get similar productivity levels in Rails.
I've been looking all over the web and have failed to see how Graphql is secure compared to an API services that accesses the db and acts a secure bridge between data and the client 🤔
For the over/under fetching I remember designing a method where you input the fields you needed and only those would be selected from the database as opposed to select * : which gave me a similar effect but nice to know QL has it out the box
Not a very good idea to build such system by yourself, you risk to introduce many security problems. For instance now did you handle sql injection?
in your udemy course you should add Spanish subtitles to your course
Can't we , instead of writing resolver for each field why not write resolver for each resource, also can't we rate limit the endpoint , ultimately whoever is going to call any query it is going to be a http call so we can block it right away there on the server side ?. what do you think ?
graphql-ruby is fantastic just btw, the Ruby on Rails comment is very much outdated.
Also, what would you use (prisma, hasura, etc.) if you were starting a new project today?
I would use typeorm today
If you are using Postgres, Hasura is fantastic.
Would you say NestJS helps in the "no Ruby on Rails/Django yet" point? From my experience using Nest it really looked like and awesome Framework to build graphQL APIs
nope, from what I've seen NestJS is not opinionated when it comes to the db
@@bawad Hi, what about nexus ? I saw the prisma team abandoned the GraphQL-yoga project to collaborate with nexus. I think GraphQL-yoga was pretty neat. Maybe nexus can become even better.
redis is not hard to implement, that easy to implement redis in your graphql server
@Ben Awad;
Not only you have a great first name, I like your last name too... :-)
Young Ben Awad before his unicorn company took off
For a big projects is a pain in the ass
I don't think, that just adding new fields is a good idea. It will mess the project. Keep code clean and get rid of the deprecated stuff. A client side handling could be better.
You get rid of the deprecated fields later on, just not immediately
Hi Ben! Any code generator or template for a project made with graphql, node, mongo and react native?
I don't
I'm on graphql/node/postgresql/react-native
@@bawad Could you share It, please?
take a look at any of my playlists ua-cam.com/play/PLN3n1USn4xlma1bBu3Tloe4NyYn9Ko8Gs.html
Hey random question. How many frontend developers should there be per backend? What ratio is normal?
I'm not sure
why is web so harrrd
IMO - any new app - go with graphql... and app already using rest - don't 'rip and replace'
Check out swaggerdoc for rest api
Swagger is just scotch over window
I'm investigating a bit but honestly it looks like a waste of time. I rather learn AWS and if some day I get a assign some task of graphql I'll learn it there.
It looks so much work for very little reward, unless you're facebook I guess
Ben have you tried Vulcan.js?
nope
Queries sure look nice.
Because at the moment my FE be like yield call(messages.find, { query: { $limit: limit, chat_id: id, $sort: { created_at: -1 } } });
While the NodeJS BE has like 50 line long sequelize query for the call above... Wtf? :D
I developed application using graphql-ruby few months ago, so "There's no Ruby on Rails" is just a lie
I guess I meant there's not a framework that's as complete as Ruby on Rails that treats GraphQL as a first class citizen
@@bawad graphql-ruby appends RoR functionality, so you can just use RoR for graphql. Also, there are few startups using this gem, so there should not be a bigger problems with creating 'real' apps
GraphQL sucks. There is to many tools and the tutorial don't follow the thin red line. It forced typescript even if its not enabled. It makes me like PHP which means something.
It's like he is whispering to the mic...
oh, no django? too bad, I love django
Graphql is so wrong
Why is that?
ooh look at me I'm so edgy