An Introduction to gRPC | LaunchPad Lab

At LaunchPad Lab, we advocate for our team members to explore new technologies and uncover opportunities to connect our clients with a full range of powerful digital solutions.

Recently, our team has been exploring gRPC, a high-performance Remote Procedure Call (RPC) framework that connects services from different programs. For many businesses, using an RPC framework is best suited for a client-server interaction (such as a query and a response).

Curious to learn more? Keep reading for our take on the gRPC framework.

What’s an RPC?

Remote Procedure Call (RPC) is a protocol in which one program requests a service from a program located in another computer. Although it calls the function locally, it’s actually happening elsewhere. This form of client-server interaction is not new — request-response protocols date back to the 1960s in the earliest iterations of computers.

What is gRPC?

Originally, gRPC was developed by Google under the name Stubby with the goal of connecting various microservices built with different technologies. In 2015, Google changed the name to gRPC and the platform was made open source. Within a year, gRPC was adopted by several prominent companies, including Netflix, Square, Lyft, and more.

How is it different from REST?

REST (REpresentational State Transfer) means the server will transfer to the client a representation of the state of the requested resource—REST, however, isn’t a protocol. It’s a method of designing and organizing code.

While REST is human-readable architecture, RPC is a machine-readable protocol. APIs built only with REST don’t cover everything an API can do. While purely RESTful APIs cover most of a simple web application’s needs, fitting everything into the REST paradigm can be tricky and an RPC framework can cover the edge cases not suited for REST.

Why use gRPC?

There are a few reasons to use the gRPC framework:

Generate client libraries

At LaunchPad, we believe that anytime a computer can do extra work for you, it’s a huge benefit. With the gRPC framework, client libraries are coded to interact with your API and create a request or process a response. This prevents developers from having to write extra code for client libraries—and it’s especially beneficial if you’re maintaining an API and offering a client library.

gRPC automatically generates documentation, which is both machine-readable and human-readable. The gRPC code itself serves as a list of the provided services that is clearly readable. Additionally, there are plugins available that will generate HTML documentation such as protoc-gen-doc.

Generate helpful documentation

A microservice architecture arranges an application as a collection of services that are highly maintainable, loosely coupled, and independently deployed. This architecture enables quick and reliable delivery of large, complicated applications—and ensures that a business can evolve and scale its technology stack.

Connect a suite of microservices

If your business uses a variety of microservices, gRPC is a great option. It allows you to write microservices in whatever language you need, but connect them with a gRPC generated client library.

Why shouldn’t you use gRPC?

If the REST architecture fits your API needs perfectly, using the gRPC framework probably isn’t necessary. Using gRPC adds a layer of complexity and maintenance to applications, and if your business doesn’t rely on a slew of microservices, staying with a simple REST architecture is likely best.

However, if you’re building an app that will grow in complexity and scale, it’s always best to set yourself up for success in the early stages.

Ready to learn more?

If you’re looking for a partner to elevate your digital experience, LaunchPad Lab is here to help. Our team can help you differentiate yourself from your competitors with an amazing digital experience.

Schedule your free Discovery Call with us to learn more.

Daniel Schadd

Developer

Daniel graduated with a degree in history and decided to work on computers. His first experience with the Macintosh II in the school computer lab sparked a love of tech that hasn't faded. As a historian, he keeps an eye on the bigger picture - approaching projects holistically to solve real business problems. When he isn't coding, Daniel can be found deep diving into Wikipedia and Youtube.