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
Пікірлер: 99
@maarten1012TTT4 жыл бұрын
I would really. love a tutorial video on automatically generating the queries with the react hooks. Awesome video!
@alkismavridis15 жыл бұрын
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.
@bawad5 жыл бұрын
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
@alkismavridis15 жыл бұрын
@@bawad I see. What do you think that would be different/less complex in the rest version?
@bawad5 жыл бұрын
making the routes efficient
@alkismavridis15 жыл бұрын
@@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?
@christiancole66922 жыл бұрын
@@alkismavridis1 nope lol
@imtheaman3 жыл бұрын
Best channel i've ever found on youtube until now.
@lancerhu81073 жыл бұрын
You don't need to change REST version if you are adding field either.
@JustPlayerDE2 жыл бұрын
but if you change what it returns
@Siddiskongen2 жыл бұрын
@@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.
@bobbyshaftoe3 жыл бұрын
Damn. Best GraphQL overview I have seen on KZfaq. Great job!
@jessewright8705 жыл бұрын
Exactly the question in my mind recently
@MayronDev3 жыл бұрын
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.
@AbdullahEAk5 жыл бұрын
Bro you are always on point, I love it. Keep up the good work
@aashayamballi5 жыл бұрын
Thanks Ben for sharing this valuable information 😊
@Kats0unam1 Жыл бұрын
I like the integration of GraphQL with Nest.
@faridguzman912 жыл бұрын
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.
@iykazorji81715 жыл бұрын
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...
@StephenRayner5 жыл бұрын
Cheers man, these videos are absolutely fantastic
@ChumX1003 жыл бұрын
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?
@IhiItsMEMaRiO5 жыл бұрын
i miss the projet videos ;(
@riongull5 жыл бұрын
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.
@vitaliikravets27773 жыл бұрын
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?
@user-qp7kb7yw8y5 жыл бұрын
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.
@bawad5 жыл бұрын
I want to try monetizing them so I'm not going to open source it at this time
@medilies Жыл бұрын
I like the thumbnail XD
@BrandonSWie4 жыл бұрын
Thanks for info as always.
@hipdev_5 жыл бұрын
Thanks as always Ben :)
@JoseHenrique-xg1lp2 жыл бұрын
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.
@ineris284 жыл бұрын
Great! Thanks for sharing!
@MechanicalMooCow2 жыл бұрын
2:15 - you either do or you don't, except when you're unsure; then you doon't.
@lmfao72245 жыл бұрын
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
@piby18024 жыл бұрын
I tried graphql but switched back to django because of several reasons like pagination, rate limiting, caching, authentication, authorization etc
@migueldomingos45704 жыл бұрын
Graphql and django are perfectly compatible One is a way to define an api and another is backend framework
@piby18024 жыл бұрын
@@migueldomingos4570 Sorry I meant to say django rest framework
@migueldomingos45704 жыл бұрын
@@piby1802 ah! ok! I wasnt aware graphql had such enourmous disanvanatges
@Mem0ryFade3 жыл бұрын
If you want that tooling but for REST you can get similar productivity levels in Rails.
@jakobankarhem62814 жыл бұрын
Hey, I think you would be interested in restful-react. It has some of the functionality that you mention liking about graphql with apollo
@bawad4 жыл бұрын
good to know, thanks
@geekboy3284 жыл бұрын
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...
@khatuntsovmikhail62235 жыл бұрын
How do you addressing breaking changes such as removing fields?
@bawad5 жыл бұрын
By not removing fields for a long time
@Eckster3 жыл бұрын
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.
@Kay8B3 жыл бұрын
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
@mariobisignani44772 жыл бұрын
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?
@randycanela18184 жыл бұрын
in your udemy course you should add Spanish subtitles to your course
@aaronbaron64682 жыл бұрын
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
@seamini91722 жыл бұрын
Did you end up landing a job and did learning graphql help?
@Thecoolbigbear3 жыл бұрын
Young Ben Awad before his unicorn company took off
@PrashanthKrishnamurthy5 жыл бұрын
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.)
@bawad5 жыл бұрын
I run middleware before resolvers for that, works pretty well
@bill.j.pearce3 жыл бұрын
graphql-ruby is fantastic just btw, the Ruby on Rails comment is very much outdated.
@shaunpx12 жыл бұрын
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 🤔
@makisetakashi5 жыл бұрын
redis is not hard to implement, that easy to implement redis in your graphql server
@natqe40495 жыл бұрын
For a big projects is a pain in the ass
@codebreatherHQ5 жыл бұрын
Check out swaggerdoc for rest api
@iancuvlad73683 жыл бұрын
Swagger is just scotch over window
@DanteS75 жыл бұрын
Also, what would you use (prisma, hasura, etc.) if you were starting a new project today?
@bawad5 жыл бұрын
I would use typeorm today
@approots5 жыл бұрын
If you are using Postgres, Hasura is fantastic.
@BenHayat3 жыл бұрын
@Ben Awad; Not only you have a great first name, I like your last name too... :-)
@shadow168104 жыл бұрын
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
@bawad4 жыл бұрын
nope, from what I've seen NestJS is not opinionated when it comes to the db
@danbo9673 жыл бұрын
@@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.
@valour.se475 жыл бұрын
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 ?
@jorgevilasboas5 жыл бұрын
Hi Ben! Any code generator or template for a project made with graphql, node, mongo and react native?
@bawad5 жыл бұрын
I don't I'm on graphql/node/postgresql/react-native
@jorgevilasboas5 жыл бұрын
@@bawad Could you share It, please?
@bawad5 жыл бұрын
take a look at any of my playlists kzfaq.info/sun/PLN3n1USn4xlma1bBu3Tloe4NyYn9Ko8Gs
@chimerablack49135 жыл бұрын
why is web so harrrd
@florianrubel63185 жыл бұрын
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.
@bawad5 жыл бұрын
You get rid of the deprecated fields later on, just not immediately
@matthewzecchini99515 жыл бұрын
Hey random question. How many frontend developers should there be per backend? What ratio is normal?
@bawad5 жыл бұрын
I'm not sure
@danieldosen52604 жыл бұрын
IMO - any new app - go with graphql... and app already using rest - don't 'rip and replace'
@DanteS75 жыл бұрын
Ben have you tried Vulcan.js?
@bawad5 жыл бұрын
nope
@FellTheSky2 жыл бұрын
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
@aleksd2865 жыл бұрын
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
@jakubsurdej43395 жыл бұрын
I developed application using graphql-ruby few months ago, so "There's no Ruby on Rails" is just a lie
@bawad5 жыл бұрын
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
@jakubsurdej43395 жыл бұрын
@@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
@honglytech5 жыл бұрын
It's like he is whispering to the mic...
@chimerablack49135 жыл бұрын
oh, no django? too bad, I love django
@burhanbudak60412 жыл бұрын
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.