Don’t Use REST APIs in your Backend, Use gRPC
When it comes to building APIs for your backend services, many developers default to using REST APIs. While REST APIs have been a popular choice for many years, there is a better alternative available – gRPC.
What is gRPC?
gRPC is a high-performance, open-source RPC framework developed by Google. It uses HTTP/2 for transport and Protocol Buffers as the serialization format. gRPC allows you to define remote service methods in a simple and concise way using Protocol Buffers, and then generates client and server code in multiple languages.
Benefits of using gRPC
- Performance: gRPC offers better performance compared to REST APIs due to its use of HTTP/2 for transport and Protocol Buffers for serialization.
- Strongly Typed APIs: gRPC allows you to define service methods and data structures using Protocol Buffers, which provides type safety and better code generation.
- Bi-directional Streaming: gRPC supports bi-directional streaming, allowing clients and servers to send multiple messages back and forth in a single connection.
- Automatic Code Generation: gRPC generates client and server code in multiple languages, making it easier to build and maintain APIs.
- Interoperability: gRPC supports multiple languages and platforms, allowing you to build APIs that can be used by different clients.
Conclusion
While REST APIs have been a popular choice for building APIs, gRPC offers better performance, type safety, and code generation. By using gRPC in your backend services, you can build high-performance and interoperable APIs that meet the demands of modern applications.
So, next time you are building APIs for your backend services, consider using gRPC instead of REST APIs for a better development experience.
A backend in python will never be fast anyways 😂. Just teasing. Thank you for this grpc lesson
Dont use grpc in your backend. Use graphql.
subliminal messaging worked. I subbed
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
Why are you talking about the REST API, but showing the HTTP JSON API? What the hell?
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 😭
You have some serious skill issues there using REST. You are writing Python in 90s way.
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.
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_.
What about a framework that provides an object called foreignServer, that has all the exposed functions of the other server, and you can call `let x = await foreignServer.myFunction(param1, param2)`, then the framework will automatically serialize it into JSON or whatever is most efficient, and call your other microservice, receive the request through it's component there, and decide what function to call, then return the result, but to you it looks like any other function call. You can specify the ip adress of foreignServer with an environment variable. You could also expose functions on a server using this framework with decorators or registration functions eg `function doSomething(param1) {…}; exposeFunction(doSomething). Type definitions would be generated and shared across server's codebases (im sure there is a way to do this, maybe the typing needs its own server for your editor to call) and maybe it could even work across languages but if not then that's good too. Everything is abstracted. Does such a framework exist?
Why not just make things similar to existing things so it's faster to learn. Same thing with dockerfiles, that should just be an extension of bash script. There are probably some edge cases I am not thinking of or main cases once stuff gets more complex than the projects i work on / imagine working on, I guess right.
The most horrific code i've ever seen. Thank god I dont have to work on that project
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.
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.
Okay, now I have to rewrite my backend for the 5th time.🫠
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.
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.