An All-API-Approach to software development
In this blog post, I’ll try and take you through some of our thoughts on software architecture for farmee.OS. Let’s shed some light!
Our smart farming operating system is split into two parts: hardware interfaces and a cloud portal. Let’s call the latter the brain of the farmee world.
The portal is where logic takes place – it is designed to be a massively scalable web application, consisting of a server part and web based GUI. We use React for the latter and we think the hype is true: it is that good (and fun, too). But since times are changing fast, especially in the web development world, the thing that endures will not necessarily be the GUI technology. Thus, we use our own farmee API to connect the GUI to the brain. This makes it future-proof and a highly flexible:
- Changing the frontend technology?
- Developing mobile or desktop apps?
- Integrating third party services?
- Some brilliant idea like “You can now control your water cycle with your smart watch”?
Yes, yes, yes and yes! This high level of flexibility is crucial for us, since we don’t know what future farmee-farmers are going to do with farmee.OS, yet.
Growing in units
We group hardware modules into units. A unit defines an area where plants grow – no matter if it is a small garden patch, a huge farming site, or a grow rack aboard a Mars spacecraft. As you can see, those units are massively heterogeneous – in fact the only thing we know is that we do not know them all and probably never will.
Therefore, we develop a standard language for those units to talk to their brain (by the way: we do not necessarily limit this to the farmee.OS-cloud – let’s think a little bigger here).
Coming up with a new language
Let’s flippantly call this an All-API-Approach – we try to be the Ludwik Lejzer Zamenhof of technology farming (yes, we just want to mention that funny name in a blog post). So, this is what we do to create the farmee-Esperanto:
- Every source of data and every business logic action can be accessed via a nicely documented (Home – Swagger), clearly understandable Application Programming Interface (“REST style” :))
- We talk JSON (JavaScript Object Notation – Wikipedia) and a lot of our RnD time goes into document structures, which describe the data and processes which appear in the world of technology farming.
All the freaking stuff happening behind this communication layer is rendered irrelevant, for instance:
- Our hardware modules mostly utilize Python and usually come in all flavors of raspberry
- We’re Symfony-guys and use it for our cloud software
Oh yes, we can hear you screaming: “Oh no, Raspberry, my kid uses that at school – what about full professional industrial boards?!” and “OMG PHP, is it 1999 again? Why don’t you use GOlang or be really cool and 1970ies and all and use C?!”
The thing is: you can do everything! Our APIs bundle micro and not-so-micro services to be as powerful and flexible as possible (when it comes to software development, “pragmatic” is our favorite word).
At a glance
- Everything, everything is accessible via the API
- Hardware modules talk to the API via http
- The business logic happens in the central unit, this is also where “the soil of all living plants” is located: data, data and – did we forget to mention? – data!
- While Hardware units aren’t dumb as f*** they are basically the executing part of the system
- Our system is open: if you meet the standards, you can be a part of it
Diving deeper
- We develop a Symfony-based API application
- We use SQL and NoSQL technologies for data storage
- Hardware units need to have a http client and talk to the application via APIs, beyond that requirement nothing is limited or even based on proprietary technologies
- At developing stage, we mainly use Raspberry Pis and control them with Python Scripts
- We use ReactJS for the GUI
- Yes, we test automatically (PHPUnit, jest) and we do like that whale (Docker)