I was recently in San Francisco meeting customers and gathering feedback for our Engineering teams. While in the Bay Area, I took part in the gRPC Conf 2019 in Sunnyvale on the 21st of March. In this blog post, I’ll share my highlights from the conference and, because we don’t use gRPC yet, give a glimpse of how our Engineering team explores new tech.
Briefly, gRPC is a remote procedure call (RPC) framework.
- You describe your interfaces with the same shared definitions. Protocol Buffers are recommended for this.
- Using these definitions, you can generate code (stubs) to access each of your services. Instead of creating API queries, you instead call functions in these stubs.
- Internally, gRPC uses HTTP2 for efficient data transfer and also provides load balancing options.
- As a result, you reduce the bootstrapping needed to integrate to another service.
My top three highlights from gRPC Conf 2019
Joe has a long history with RPC frameworks and says gRPC is his favorite. This talk was the most relevant one for a company without previous gRPC experience (like us) as it highlights the best practices and digs deeper into the pitfalls. The surprises and pitfalls in gRPC were a recurring theme at the conference. The most common ones are:
- Always set a deadline for your RPC requests and automatically lint that the deadline is set. Otherwise, some requests may reserve resources indefinitely and cause your servers to slow down over time.
- You should also support JSON and HTTP/1.1 for your customers and external clients because HTTP2 is not supported everywhere.
- Having good API design and evolution guidelines will save you a lot of headache, because it’s a good way to work with the nuances of protocol buffers and different languages.
This talk builds on the excellent blog post from Dropbox on migrating from a legacy RPC to their new gRPC-based framework Courier. Merhdad’s talk has a few nice additional details. If you are wondering how to share and update protocol buffers between your services easily, Dropbox solves this by using a monorepo with Bazel. They have also created their own stub generator to include custom rate limiting and authorization before deserialization (which is a huge boon if your payloads are big).
Maximizing learning for yourself and your team
Smartlies are encouraged to visit conferences that are relevant to their work and professional growth. Conferences help you network and learn especially from the big players who do software development at large scale. We believe that by maximizing our learning, we prepare ourselves for the challenges we will face in our future product development.
Maximizing learning is a communal effort. We write detailed notes of all the conferences we visit and share them with the whole company. Sharing learnings sparks discussions and amplifies opportunities to learn for all of us. The notes may come in handy later when developers debate technology choices. While we believe development teams should be free to choose the best tech for a given problem, we have grown big enough to appreciate a certain level of consistency between teams, their tech stacks and their principles of development.
Before committing to a new technology, we do careful assessment and experimentation with it. Experimentation is usually carried out by a single team and scoped only to a few services. If the tech proves its value, it is rolled out to the rest of the teams. Once, a development team worked with Scala+Slick+Play for three months until we realized that the stack was too cumbersome to work with in the particular use case. The team scrapped the Scala project and recreated the same functionality with Ruby on Rails within days.
Does gRPC have a future in our tech stack?
All in all, gRPC has some very promising ideas and benefits. gRPC in particular, would help us with generated API stubs and unified pluggable authentication. This would help us to generate code to reduce the bootstrapping needed for a new service and its integrations. Anything that helps us improve the development speed is of utmost importance.
There are other technologies with similar benefits to gRPC we are already working with. For example, we are using openAPI in a few of our services and we are familiar with how it works with tech stack. We need to also consider if we want to use either, or both, of these technologies.
Smartly.io is growing fast, which means we are constantly figuring out ways to do things better at scale. As a direct action from the conference, we are currently establishing a more rigorous API Design guide internally. As we are living in a polyglot environment with an increasing number of services, there are many benefits to doing this even if we don’t end up using gRPC.
Learn more about the life of a software developer at Smartly.io at www.smartly.io/developer.