Don't Use REST APIs in your Backend, Use gRPC
HTML-код
- Опубликовано: 13 июн 2023
- gRPC let's you specify the request/response/functions and generates the code to do RPC to the API server. It's cheaper and smaller requests. Handles security out of the box. Let's you avoid crazy API migrations.
Наука
Computer science is crazy, I've never been able to study something without someone telling me "why are you using this? you should use this other one." Anyway thanks for the video, I had never heard of gRPC.
there's good chance this comment delivered by GRPC
Hope you liked it!
I think at the end of the day it's all about tradeoffs. If you're just building something over the weekend that you'll never touch again. gRPC is probably overkill. It takes a slightly longer time to set up than a REST API - especially if you haven't used it before.
But for any serious production workload if you gRPC doesn't at least come into the conversation at some point you'll probably end up paying a steep price down the road.
At the end of the day, these guys have their own agenda so your best bet would be to try out those popular things and see if you like it.. anddd i dont like grpc
The most horrific code i've ever seen. Thank god I dont have to work on that project
This is misleading.
The API Rest example assumes that for each API request you have to write all the code to initialize, send and interpret the response. Which no one in their right mind would do.
All the repetitive code is encapsulated in a class method and that's it. If there is a bug, there is only one place where it can happen and only one place to fix it.
Exactly as it is done in the gRPC examples.
It's exaggerated to bring the point home. If my example would contain 5 layers of nested classes it'd be even less understandable than it is now.
Frankly, unless you are generating your REST API from some OpenAPI spec (which is a ~reasonable way of using REST) you are still implicitly doing all the same logic at some layer in your code.
At some point you are:
1. Specifying either a class or dictionary that contains the request body.
2. Specifying either a class or dictionary that you expect will match what the server responds with.
3. Specifying your URL path and any parameters.
1 and 2 implicitly are serialized or deserialized (you only hide the actual call to the JSON parsing -> all the same things might still go wrong). And you might still accidentally change the name of a variable on your server causing that to propagate through your code to change what is returned in the response body.
The main benefit with gRPC (at small scale), which maybe didn't come through in the video, is the contract it provides that you know the server will abide by. Sure, you could probably build something similar yourself. But it'd eventually just be a bad reimplementation of gRPC, and why would you waste your time on that when you can just use it off the shelf and focus on actual business problems?
When scale start mattering, then gRPC (or something similar) becomes a no brainer. Otherwise you're just be wasting money on inefficient serialization formats.
Contracts aren't what make gRPC a great solution for certain problems - all interfaces require a contract of some sort, even HTTP + JSON. The thing that sets gRPC apart from HTTP + JSON is performance. It serializes and deserializes faster, and uses less data on the wire.
@@MrCompSciGuy You should ONLY use gRPC over rest if data compression is the overriding concern. Very few applications require the extreme message compression that Protocol buffers can deliver. If flexibility and decoupling is what you need, which is most applications, then go with REST. Remote procedure calls are an obsolete and less flexible alternative to REST messaging. Distributed cloud-capable applications are easier to design and implement with a message passing metaphor than with a networked implementation of the old C function call. RPCs are strictly point to point and are not typically amenable to real-time redirection for load balancing or when network failures occur. To say that gRPC should be used when you need to scale is to show a fundamental misunderstand of gRPC and REST based architectures. gRPC does not scale well because of tight coupling.
@@just-squirrels You can achieve most of the performance gains by using protobuf alone, the performance comes mostly from the tightly packed universal serialisation format, not from gRPC.
@@emilysort that’s a great callout!
A backend in python will never be fast anyways 😂. Just teasing. Thank you for this grpc lesson
2:43 A lot of boiler plate. So what do we do? We write a lot of gRPC boilerplate to replace the boiletplate.
What else could we have done?
Write a more generic way of sending requests to your api, or "helper" functions for each request in their own class or util containing most requests in their own respective function that just return the data or anything that is needed based of the request.
Your generic approach literally sounds like the gRPC implementation lol
@@diegocastaneda4325except that its not and its just a rational way to implement REST
Why are you talking about the REST API, but showing the HTTP JSON API? What the hell?
Have you read REST dissertation in the first place? Using words “you are actually invoking a remote procedure call” is borderline insane and reeks of ignorance.
REST API can utilize protobufs if you so desire, for crying out loud. It doesn’t dictate exchange format. What it does dictate, however, is to _not call remote functions_.
too much code for this gRPC thingy, i'm stickig to REST all day.
"That's a lot of boilerplate"
*rewrites in Java*
Okay bro
My backend (python) acts mostly as a client to fetch data from different 3rd party endpoints which are all REST and I dont control.
My frontend is decoupled and, in a different language, react.
So, how would gRPC help in this case?
The only opportunity for me to use gRPC is if a) i can use between my frontend and backend or b) i have calls in my backend that consume endpoints in the backend API.
Currently, there are none.
My api is not public.
just an update, I realized I can run multiple services in my backend and then I can have the api endpoints in my backend use gRPC to work with backend services - kind of like an api gateway
Well for you it seems like you're talking about frontend -> backend. And there imo it kind of makes sense to use REST. Mainly because doing frontend -> backend with gRPC is a bit of a pain.
Especially in this case, it seems like you have your backend which is basically 1 or 2 endpoints. And all they do is some business logic + call other REST endpoints.
Whenever you migrate something, you have to compare the cost vs benefit you gain. In this case, it doesn't seem like you would gain a lot. Just make sure to keep your REST API simple (and that should generally be the rule you go for, keep it simple). gRPC really only starts simplifying when you get larger apps or very performance intensive ones.
You have some serious skill issues there using REST. You are writing Python in 90s way.
nothing in CS is straight A.
It all comes with its own compromises
You any day need APIs like rest/gql however you try. You have to send data yo some client
subliminal messaging worked. I subbed
That assumes that management would allow it, but management believes that REST is the way to go.
You don't buy Gucci bags because you need and handbag do you?
1:35 whoooo in the world inspired you to use morph animation on code??
3:59 🤦♀ as beautiful as the concepts taught in the video can be, the animations choice is absolutely worst.
be simple man - just a plain "record edits on code & play on reverse" is far far better than these "mind boggling" - "eye twister" hodgepodge 😭
ill never take advice from people who use windows software willingly
Dont use grpc in your backend. Use graphql.
Okay, now I have to rewrite my backend for the 5th time.🫠
You have a lot to learn my friend. RPCs are an archaic technology. Software engineering has outgrew it. First of all gRPC forces a tight coupling between the components involved. We've learned to avoid tight coupling for a reason. It is a fundamental principle of microservices architecture. It is painful to watch developers make the same mistakes over and over again.
JSON didn't exist when Roy Fielding wrote his dissertation on REST, but it is a useful "self-defining" message syntax. Protocol Buffers are anything but self-defining and require a complex system for distributed schema management to work at all. That may be justifiable if data compression is the overriding concern, but it makes loosely-coupled microservices impossible to implement. A properly designed RESTful solution is a far better match for the implementation of microservices architecture which is what MOST web services are today.
Remote procedure calls are an obsolete and less flexible alternative to REST messaging. Distributed cloud-capable applications are easier to design and implement with a message passing metaphor than with a networked implementation of the old C function call. RPCs are strictly point to point and are not typically amenable to real-time redirection for load balancing or when network failures occur.
Nobody can even agree on what is REST and what is not
I have to say. I disagree with every single point you made.
> First of all gRPC forces a tight coupling
It really doesn't enforce more tight coupling than REST. It just prevents you from accidentally messing up the server client contract. If anything, it gives your microservices a well-defined interface and that will in the long run be to your benefit.
> implementation of microservices architecture which is what MOST web services are today
Are you really sure about that? I'd claim that most serious applications in the industry today use some sort of RPC. Even if they don't use something open source they'l have implemented their own version. Of course, then you also have your message passing interfaces as well. But it's impossible to work at any scale without contracts, you'll go under in downtime.
> Distributed cloud-capable applications are easier to design and implement with a message passing metaphor than with a networked implementation of the old C function call
I agree that for a lot of cases you should probably use message passing instead. But REST is as much message passing as gRPC, and even if doing message passing, having your messages be a protobuf is still going to give you better typing.
> and are not typically amenable to real-time redirection for load balancing or when network failures occur
This is just straight up false. You don't think Google (which have used RPCs basically their entire history) face network failures or dynamic load balancing (when they probably have the world's most advanced load balancer with Slicer, which is a very interesting paper that I'd recommend you read).
To go truly loosely couple with your backends you better use message queues
protobuf != gRPC. gRPC is only built on top of protobuf, but you can use protobuf by itself very simply and at very little cost. It doesn't enforce a style or framework onto your codebase for the most part, the only condition is that you need a compiler and a library to deserialise. Other than that it can be treated almost the same as JSON or similar.
@@emilysortnot exactly the same. The great thing about JSON is that data is human readable and self describing, which is huge for debugging