💌 Inquiries: thecodinggopher@gmail.com
👨‍💻 𝐋𝐞𝐚𝐫𝐧 𝐭𝐨 𝐛𝐮𝐢𝐥𝐝 𝐆𝐢𝐭, 𝐃𝐨𝐜𝐤𝐞𝐫, 𝐑𝐞𝐝𝐢𝐬, 𝐇𝐓𝐓𝐏 𝐬𝐞𝐫𝐯𝐞𝐫𝐬, 𝐚𝐧𝐝 𝐜𝐨𝐦𝐩𝐢𝐥𝐞𝐫𝐬, 𝐟𝐫𝐨𝐦 𝐬𝐜𝐫𝐚𝐭𝐜𝐡: Get 40% OFF CodeCrafters: https://app.codecrafters.io/join?via=the-coding-gopher
❤️ https://www.patreon.com/TheCodingGopher

👇 My recommendations 👇

✅ 30% OFF with promo-code FLYT30 on the best proxy service – FloppyData: https://bit.ly/floppydata_the-coding-gopher

✅ 20% OFF with promo-code YTGL20 on the top multi-accounting browser – GoLogin: https://bit.ly/gologin_the-coding-gopher

These are the tools I trust—check them out! ❤️

The Coding Gopher

RPC, or Remote Procedure Call, is a critical communication protocol in distributed systems, allowing for code execution on remote systems as if they were local. This method abstracts networking complexities, making it ideal for microservices and internal systems that require efficiency and strict contracts. Unlike REST, which uses HTTP verbs and is better for external APIs, RPC offers granular function-level control, better performance with binary formats like Protobuf, and advanced capabilities like streaming and retries. gRPC enhances these benefits with efficient communication and built-in logging and metrics, making it a superior choice for modern backend architectures.

99% of Developers Don't Get RPCs

RPCs have been around since before the Internet. Most web developers fail to understand or utilize them because they don’t have a programming background, but rather a website building one. As (well said) in the video, gRPC is not useful for public APIs but really makes a difference (in $$$$ if we use hourly-billed cloud computing) for internal APIs.

Nicely done, very useful
today I learn something new, it was much clearer than just reading documentation about RPC :)
I have not yet tried to implement this method, but with the upcoming project
Where will microservices be involved I need to try to implement this logic :)

as if RPC’s are complicated or new - standard and easy shit!

Most people HATE the idea of having to run generation functions to know if the contract is valid EVERY time you make a change. Personally, the idea of generating contracts for development is really a huge pain. GraphQL suffered from this and has basically died, as a result. The problem that RPC does not solve (of REST for that matter) is the fact that calling one server/client to another is NOT something you can guarantee the state of. The second you involve any kind of statefulness (even if it is a contract) you increase the complexity by magnitudes in larger scale systems.
I am not saying RPC is bad, I am saying that it is not just “better than REST”. REST embraces the idea that you can’t guarantee what state the server is in and leaves that up to the engineers. Whereas all these various solutions add layers of abstractions and code generation you “just have to trust” and every single change to the API requires “rebuilding” the generated contracts.
I think people who don’t have experience with things like SOAP and GraphQL might be easily bought into things like this, but this idea and the concepts around it are OLDER than HTTP, itself. The idea of trying to enforce state FORCES all servers within the system to generate the SAME contracts across the entire ecosystem and constantly do validation and verification of ALL communications in a way where, ultimately, you are still just putting lipstick on a pig and hoping everything is correct.
Again, I am not saying RPC is bad. I am saying that it carries with it, it’s own problems also. People have been trying to kill REST before it was created for 30+ years.

Interesting. Instead of having a controller for the routes, you put them in a proxy server. cool