It’s my understanding that the limitations of the arduino platform, caused the current software to be tightly coupled.
The Spark however is a whole diferent beast, it was the architecture that got me attracted to the Spark in the first place, before I heard that BrewPI had switched to Spark.
The standard Spark architecture gives a lot of flexibility.
- A generic program can be built and deployed to the device
- Functions can be exposed as web services through either the Spark cloud or your own local cloud instance
- Operations on the device can be invoked from whatever platform you would like, it could be a basic HTML5 application, a native android app, it could even be integrated into other software like BeerSmith
This architecture is nicely decoupled. You don’t have to understand native programming concepts to contribute. Once the program on the BrewPI Spark has matured, it might not even change that often, and most changes would be done in the UI layers.
I hope the future architecture of the BrewPI Spark will be decoupled, as it enables different people to focus on one or two specific parts, without needing an understanding of how everything works at all levels.
I have done a quick sketch of how I imagine such an architecture.
What are your thoughts, where are the BrewPI architecture heading?