I have an app-in-progress which will use multiple frontends - a web console built with TypeScript/React, a native Android app (Java or maybe Kotlin if I feel adventurous), and a CLI (Rust) all talking to a server (Rust for now, but I'm considering a jump to Spring), with some IoT devices reporting in. I've got bits and pieces of each of these individual components working but this is still very much in the planning stage (and ambitious - this is a long-term idea).
I'd like to use the opportunity to learn how gRPC works and began looking in to capnproto. It seems like a great idea and designed to tackle this exact scenario, but starting to actually implement this is giving me pause.
I feel like I am adding a lot of technical debt for a situation that could likely be handled just fine by a good old RESTful API. Are the benefits going to outweigh the code weight, or do I not understand this tool well enough? Is it worth it to build a REST version first, even though if I do decide to change down the road the switch would require significant rewrites?
I can't tell if I'm running toward something because it's actually a good idea or because it looks cool and I haven't tried it yet. I'd love to hear your thoughts! How are you using gRPC?
Top comments (8)
A few thoughts on this
Separe your code in layers, with the idea that when you need to change from a rest to rpc will only need to replace one class
Test the easiest solution you can implement on the client you can do fast iterations (aka not mobile), with abtests and feature flags.
Monitor everything, from both sides, requests, latency, errors, bandwith ..
RPC calls are suited on long term connections, like server to server, which is the oposite to IoT where the connection is the biggest problem.
As for the code weight I dont see one, most protocols have auto generated clients and servers (swagger, protobuffer).
Beautiful. Thank you very much. I definitely need practice with larger architecture. Interesting point about server-to-server, hadn't seen it put so concisely but that makes complete sense. I'll wait and see what my problems actually are before throwing solutions at them!
Also depends a lot on the type of the project.
Commercial - we have to solve real problems, taking into consideration business needs with mature technologies.
Side project - we use what we want to learn, our career needs with new fancy toys.
And to answer your title question, I would consider gRPC when the needs are latency and bandwidth, and/or you want to move most of the computation on the server (remote call), good for saving battery in IoT.
Also securing gRPC calls (in public) is harder (not impossible) than using HTTPS with OpenID.
Also for IoT sensor like devices I would go first on a MQ* platform, that allows to gather and queue messages on edge computers before sending it to the server.
Interesting. The battery issue was partially why I started looking into this - some of these devices will be difficult to access once deployed so as set-it-and-forget-it as possible is desirable. I've only heard about MQ systems, never used it, thank you for the suggestion! This will be my first foray into anything IoT, that's a huge help.
I'm less concerned about security - for context, the overall goal is a monitoring, management, and automation suite for a self-sufficient homestead. I think the whole thing could run on a self-contained LAN with no outside connections at all - a bad actor would need to physically be on the property at which point you've got bigger problems first! Not to say I'm ignoring it, but deprioritizing.
It's definitely in the realm of side project so fancy toys are ok, but your first point was most salient - if I've properly organized the system it really should be a non-issue to try it down the road.
Keep in mind that baking security in AFTER is usually more expensive than planning it from the start.
If you want a fun overview of the issues of lax security in IoT follow internetofshit on Twitter.
An example they recently re-tweeted:
Hah - yikes! Fair enough, duly noted :)
BTW this post by @danielkun might give you ideas:
Where is HTTPS for IoT? (Update)
Daniel Albuschat
Wow! That's an incredible resource, thank you for the link.