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!
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.
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.