*Blog* mariocarrion.com/ *Software Architecture and System Design in Go* ua-cam.com/play/PL7yAAGMOat_GCd12Lrv_evJ3Zhv1dl8B-.html *All playlists* ua-cam.com/users/MarioCarrionplaylists *Keep it up!*
Completely agree with these pros & cons. People shouldn't underestimate just *how* much more expensive it can be to implement GraphQL, by the way, if you are doing anything at all complex and custom in your backend (i.e. not just reading from a database). It makes the problem of overfetching in REST very small by comparison. I would say, as a general rule, try to make REST work first.
Regarding the under-fetching con in REST, you can just apply filters on a list endpoint and get only the permissions, w/o other users' details. sure, it's still a loop in your logic, but another endpoint like /users/{userId}/permissions to hit in each loop iteration is not really necessary.
Yes you can do that, but like you said that extra logic now lives on the backend side; if the goal is to dynamically get some fields over others, then why even considering REST in the first place? Go the down the GraphQL route instead. There are tradeoffs either way with whatever decision we make anyways.
Worked at a company where we moved all our internal endpoints to gRPC, because the staff engineer that proposed it wants our backend communication protocol because it is language agnostic while our whole backend stack is written Java or in the process of migrating to Java. The engineer that proposed it got a promotion while the migration to gRPC provided no business and engineering value other than costing the company millions in lost engineering hours.
Being language agnostic is a nice feature, but the actual *practical* benefit when using gRPC (and really Protocol Buffers) is low latency and performance, so if there was no performance problem with your internal endpoints (assuming you mean east-west communication), then it makes no sense to change what you had at all.
@@MarioCarrion Rest is actually language agnostic as well, because the payload is in JSON we can serialize/deserialize in any language and there are many libraries in most languages that does that. And I don't see much performance gains in real world scenarios, because a big portion of latency in real world systems is caused by inter service communication and i/o operations on databases. The performance advantage of gRPC is mainly that it serialize/deserialize faster than JSON, but if there is a JSON library that serialize as fast as gRPC then gRPC's performance advantage diminishes.
For the most part, I agree with you. Ultimately, I will consider using gRPC **if** an internal service is requested millions of times per minute. Otherwise, JSON over HTTP is more than enough.
@@MarioCarrion At one of my previous companies we had millions of backend requests per minute and were quite performant and no latency issues. We implemented good strategies like caching, reduce the number redundent downstream network calls, had a performant backend framework that utilized asynchronous multithreading, and a performant json serialization library. There is more performance gain making those changes than the choice of network communication protocol.
graphql with golang is extremely hard and complicate and cannot understand the world of golang is weak on this part, then most of plugins use schema first not code first like "graphql-go", and for my personal experience until now upload file with graphql not working in golang
Yes, that is the way to use browser clients to talk to gRPC Backends; I should made it clearer because I didn't mean it wasn't possible but more like it requires an extra step. Best!
Hey Mario you explain so nicely. Alright, I have a question. I want to build an app that will be having user profiles, calling features, geo-fencing, geo-tagging, voice & photo sharing(ephemeral) and a bit of social features. Could you tell me what backend programmer should I hire? Because right now, I do have a Golang programmer who works with GRPC as well as a NodeJS developer and he works with Appsync(GraphQL). Also, I do have an iOS developer who can connect the final endpoints to the Xcode using Swift once the backend is ready. I really would like to take the serverless approach this is why AWS Lambda fits well to me but a GRPC needs an active server hence it can not be used with Lambda. Could you tell me which programmer would be best at my case for building the app logic, business logic and the complete backend. Please do reply. Thanks.
Hello Alysha, I think you are already answering your question. If your goal is to build what it looks like like a mobile app using Lambdas, then GraphQL sounds like the better choice because of the pros, regarding what programmer to hire, I don't know, I think that's something you should decide and depends on their experience and/or willingness to learn/use something that they may not know yet.
estoy confundido necesito consultar una db dgrpah con go, y tanta documentacion me dejo mas confundido donde puedo ir puntualmente para hacer esa gestion?
Only one thing to change about your else beautiful explanation: GraphQL is very inefficient performance wise. By many points of view. It also has very annoying N+1 problems that are not that easy to solve sometimes
![[UA] NAVI проти G2 Esports | Blast Premier Fall Final](http://i.ytimg.com/vi/QWlIm4FGESQ/mqdefault.jpg)
*Blog* mariocarrion.com/
*Software Architecture and System Design in Go* ua-cam.com/play/PL7yAAGMOat_GCd12Lrv_evJ3Zhv1dl8B-.html
*All playlists* ua-cam.com/users/MarioCarrionplaylists
*Keep it up!*
Completely agree with these pros & cons. People shouldn't underestimate just *how* much more expensive it can be to implement GraphQL, by the way, if you are doing anything at all complex and custom in your backend (i.e. not just reading from a database). It makes the problem of overfetching in REST very small by comparison. I would say, as a general rule, try to make REST work first.
Most underrated Go channel (see what I did there?) out there, amazing work Mario. Is there a way we can support your work?
Thanks Felipe, I think sharing it could be a nice way to support the channel, take care!
Thanks for creating this video, very clear explanation and easy to understand. Helps me as a product person to know better
I'm glad you found the video useful, take care.
This is great information, beyond the scope of Golang actually. Thanks!
Thanks for watching Cristian, I'm glad it was useful.
Me gusta como explicas, muy claro, seguiré viendo tus videos, gracias!!!
Regarding the under-fetching con in REST, you can just apply filters on a list endpoint and get only the permissions, w/o other users' details. sure, it's still a loop in your logic, but another endpoint like /users/{userId}/permissions to hit in each loop iteration is not really necessary.
Yes you can do that, but like you said that extra logic now lives on the backend side; if the goal is to dynamically get some fields over others, then why even considering REST in the first place? Go the down the GraphQL route instead. There are tradeoffs either way with whatever decision we make anyways.
Very clear and precise!
Awesome video as always!
Thanks Argana! Cheers
thank you for sharing this information
Thank you for watching, take care
Worked at a company where we moved all our internal endpoints to gRPC, because the staff engineer that proposed it wants our backend communication protocol because it is language agnostic while our whole backend stack is written Java or in the process of migrating to Java.
The engineer that proposed it got a promotion while the migration to gRPC provided no business and engineering value other than costing the company millions in lost engineering hours.
Being language agnostic is a nice feature, but the actual *practical* benefit when using gRPC (and really Protocol Buffers) is low latency and performance, so if there was no performance problem with your internal endpoints (assuming you mean east-west communication), then it makes no sense to change what you had at all.
@@MarioCarrion Rest is actually language agnostic as well, because the payload is in JSON we can serialize/deserialize in any language and there are many libraries in most languages that does that. And I don't see much performance gains in real world scenarios, because a big portion of latency in real world systems is caused by inter service communication and i/o operations on databases.
The performance advantage of gRPC is mainly that it serialize/deserialize faster than JSON, but if there is a JSON library that serialize as fast as gRPC then gRPC's performance advantage diminishes.
For the most part, I agree with you. Ultimately, I will consider using gRPC **if** an internal service is requested millions of times per minute. Otherwise, JSON over HTTP is more than enough.
@@MarioCarrion At one of my previous companies we had millions of backend requests per minute and were quite performant and no latency issues. We implemented good strategies like caching, reduce the number redundent downstream network calls, had a performant backend framework that utilized asynchronous multithreading, and a performant json serialization library. There is more performance gain making those changes than the choice of network communication protocol.
Thank you Mario. It's amazing video.
Thanks for watching, cheers!
graphql with golang is extremely hard and complicate and cannot understand the world of golang is weak on this part, then most of plugins use schema first not code first like "graphql-go", and for my personal experience until now upload file with graphql not working in golang
What about gRPC-Web for Frontend to Backend gRPC use tho?
Yes, that is the way to use browser clients to talk to gRPC Backends; I should made it clearer because I didn't mean it wasn't possible but more like it requires an extra step. Best!
Nice recap! Thank you
Thanks for stopping by Jerry. Take care!
Hey Mario you explain so nicely. Alright, I have a question. I want to build an app that will be having user profiles, calling features, geo-fencing, geo-tagging, voice & photo sharing(ephemeral) and a bit of social features. Could you tell me what backend programmer should I hire? Because right now, I do have a Golang programmer who works with GRPC as well as a NodeJS developer and he works with Appsync(GraphQL). Also, I do have an iOS developer who can connect the final endpoints to the Xcode using Swift once the backend is ready. I really would like to take the serverless approach this is why AWS Lambda fits well to me but a GRPC needs an active server hence it can not be used with Lambda. Could you tell me which programmer would be best at my case for building the app logic, business logic and the complete backend.
Please do reply.
Thanks.
Hello Alysha, I think you are already answering your question. If your goal is to build what it looks like like a mobile app using Lambdas, then GraphQL sounds like the better choice because of the pros, regarding what programmer to hire, I don't know, I think that's something you should decide and depends on their experience and/or willingness to learn/use something that they may not know yet.
estoy confundido necesito consultar una db dgrpah con go, y tanta documentacion me dejo mas confundido donde puedo ir puntualmente para hacer esa gestion?
Thanks for making this, good information and easy to digest
Thanks I'm glad you found it useful. Cheers
@@MarioCarrion whatever kid
Only one thing to change about your else beautiful explanation:
GraphQL is very inefficient performance wise. By many points of view. It also has very annoying N+1 problems that are not that easy to solve sometimes
dataloader is the solution most of the time
What do you mean by mutations here?
In GraphQL Mutations define the possible actions used to modify values: Create, Update and Delete actions basically.
Thanks
Thanks for watching! Take care
PATCH
I'm sorry, but your pronunciation is confusing.
Make sure you enable closed captioning, it typically works