![]() This was a huge obstacle for an engineering organisation that does independent and frequent rollouts. But more importantly: new APIs (methods, fields) were only visible to the Web Apps when the platform API was regenerated and re-deployed alongside the gRPC REST Gateway. Our Web App teams still needed to write JSON parsing code and client-side object representations, write the HTTP client libraries with the right calling conventions, and occasionally peek into the Network Console of the browser to figure out an odd networking error. ![]() While this solution saved us from having to hand-write API-server-side code, it still had numerous drawbacks. The approach we took was very similar to the one described here. At the same time, they were meant to consume the same gRPC platform APIs as our clients and CLI tools, so we needed to find a way to expose them.įortunately, with gRPC REST Gateway, there exists a code-generator of REST+JSON API bindings for gRPC apis based on. Since there was no support for using gRPC from a browser, the Web Apps teams were an exception to this culture shift. By leveraging the protocol buffers backwards and forwards compatibility, the question of “ Do I need to add this field or not?” or “ What does this field accept?” stopped coming up. This has allowed teams with different areas of expertise (SDK, backend, CLI) and different language backgrounds to have a single way of expressing contracts and expectations. proto definitions, which provide the schema for gRPC services, became the standard way of thinking about services: they’re the first thing we converge on in design-discussions and the canonical documentation of how things work. The latter fit our bill perfectly, and after initial spike and validation we decided to adopt it company-wide. Initially we went with REST and HAL, but the burden of re-implementing and maintaining clients for the plethora of languages (C++, Java, Go, C#, Objective-C) started to eat into our time to do what we really like, solving the actual problems our customers have, and we decided to look for something else.Īt roughly the same time, Google open-sourced gRPC, the next-generation of their in-house RPC library based on the then brand-new HTTP2 protocol with support for code-generating clients and server stubs in multiple languages (C++, Java, Go, C#, Objective-C, NodeJS…). Early on in the development of our platform, we decided on the importance of strongly typed, well documented APIs. Keep up to date with the latest from Improbable Sidenote: why gRPC in the first place?Īt Improbable we’re building SpatialOS, a PaaS offering for spatial-aware simulations that leverage existing simulation models, game engines, and visualisation clients written in multiple languages.
0 Comments
Leave a Reply. |