The idea is to make a software system that could accept data collected from various sensors in the building and make it accessible to the building manager. Whenever I am presented with a task like this, I like to begin by drawing a C4 model for the software system, which presents it as a series of increasingly detailed diagrams.
In the first diagram I examine how the software system interacts with the world. This diagram should exhaustively answer who are the user classes that interact with it, how does it fit in with existing systems and so on. Putting some effort into this may prevent a costly surprise down the road (for example: multiple sources of truth, missing administrative component, third party API that's hard to integrate).
This diagram looks deeper into what containers (which don't always equal a docker container or virtual machine) are necessary for the software system to perform its duties. If there are more user classes (for example sensor installer, sensor panel content administrator, homeowner) and more internal and external systems (mail alerts, phone apps, admin panels), this diagram can get very busy. For now, it's fairly simple: a web front-end, a back-end, and data store.
The next level in C4 model is component diagram, but I find the above two levels to be detailed enough to start with. With the bigger picture taken care of, it's time to choose the technology stack and append it to the diagram, as I've already done above. The list of factors I took into account are as follows:
- solid, should be able to handle edge cases and rough use
- simple to understand
- needs to be runnable locally on Linux with docker-compose installed, no additional dependencies
- the system needs to be deployable to the Internet
- automatically (CI/CD)
- for free
- needs to be served over HTTPS
- self-maintaining (no manual data deletion or entry)
Due to the criteria above, I had to start my technology choices with where I was going to deploy the system and work my way backwards from there. In another project, I'd try to identify the bottleneck or most critical factor and satisfy that first (for example, 100 000 simultaneous WSS connections), then put heavy emphasis on development convenience, simplicity (KISS), resilience and (auto-)scalability.
My first thought was Netlify (big JAM-stack proponents) as they are a great one-stop platform for static web apps with the BE as cloud functions in the same repository as the FE. From previous experience, in about 24h it's possible to go from idea to 3 devs, designer and two content managers simultaneously working on the same project, all the while without sacrificing content persistence and development ease. Choosing this option would dictate a Typescript static web app with Typescript lambda functions back-end. However, the data store would need to be on an another platform, which would make CI more complex and the whole system harder to manage.
Out of the cloud platforms, Google Cloud with its generous free tier was another strong contender. In my opinion, its advantage over Microsoft Azure is better documentation and better cloud console / control panel. A possible stack there would be Golang or Node.js / Express back-end running on their App Engine (standard environment), a Cloud Storage Bucket serving the static front-end and Cloud Firestore NoSQL database. The problem with that is the fact that Cloud Storage is HTTP only if you don't have a custom domain.
As it happens, Google's Firebase platform, a convenience layer on top of their main cloud services, has features tailored specifically to web or mobile apps. I've previously used some of its services in Typescript React Native apps and to prototype web apps, and it has certainly been satisfactory. With its web hosting service (HTTPS automatic), lambda function possibility for BE, and Firestore data store, it seems to be the most suitable deployment environment.
Going with the deployment environment of Firebase dictates
- static web app (Typescript, React)
- cloud functions as backend (Typescript)
- Firestore as data store