So I started architecting the app I’m writing to satisfy a personal need. It’s an interesting project because I set a few must-haves for this app, and in doing so my architecture design, the approach I take, and the general data structure I use need to remain very intentional.
There are a few design rules I set to follow, but the main points are:
- Ability to be multiplatform: the application should be able to run on any platform I use and have the same or very similar UI
- Locally stored data: store data locally so it can be available offline and not be dependant on any cloud or web services that might go away in the future
- Lightweight: the application should be able to run on new hardware and older, less powerful hardware as well
Originally I was going to make this application a single purpose one, however the more I look at the general architecture and what I want/need this application to do, the more I realize that what I need is more of a combination of the key features that I already have in other smaller applications.
The tricky part of this is making all the native apps and technology work seamlessly with one data source. It should be simple, the data is being saved in json format, but Swift (for iOS and MacOS) and Go (for the command line, web server and linux) handle json in different ways, forcing me to have to change the original design of the data.
But that’s ok. I spent the last few days learning about standards and how to optimize the use of TLS, local storage per device, and json encoding, and I feel confident that I have a simple, lightweight, and secure way to sync data between all the devices, and to store that data locally also in a secure way. I’m really happy that I’m being challenged by the constraints I set to myself. They forced me to learn new things. I had forgotten how much fun (and also frustrating at times) working with and designing a new piece of software can be.
Speaking of design, as you saw above I placed a lot of emphasis on security. This is not only because it would be stupid not to do so, but also because one of the main reason I’m coding this is because a lot of the options out there already have security issues, and I know what can happen when they are exploited.
I’m not a security expert, but I’ve been around systems, software, and the internet long enough to know the badness that comes from poor security practices. So, in order to make sure my head was in the right place, I asked a couple of good friends that are security professionals. We had a great conversation that culminated in a five hour threat modeling and session over beers. It was fun, but also stressful to have those two take my idea and design, and take it apart bit by bit.
At the end, we were standing right in front of a better overall architecture and initial code guidance. As part of this exercise they suggested I read a few sites and articles. Right on! I’m all for learning new things, so, yes, bring it! I found several websites with a lot of information, but three of those websites really gave me a good sense of what to aim at. I ran this by my friends and they both nodded. The sites are:
A few key points from those websites and books: understand what can go wrong, never trust input, and sanitize your output.
It’s hard to get right, for sure, but if you think about it, it makes sense. As a side note, I’m now deep into learning security, threat modeling, risk assessment methodologies, and a new way of thinking about systems/software/data.
In terms of data and how to transmit it, I found a few things that provided a good direction and showed me different ways of doing things. I didn’t implement those as-is, but I took some of those concepts and created something with them. The main information can be found in:
- Lightweight Communications and Marshalling for Low-Latency Interprocess Communication (PDF)
- Lightweight Communications and Marshalling (LCM)
- Communication Between two Programs using JSON
- Differential Synchronization
- Autonomous Data Architecture
- Concurrency Synchronization Techniques Provided in the sync Standard Package
- JSON to Core Data and back
Overall I now have a good sense of where to start working. I have a rough data structure, I have a good way of sharing data between all the native apps and a web server (if needed, I’m not sure yet if I will go that way), and a set of requirements for security. I’ll report on the progress as I work on this. I'm documenting everything, by the way, using ADRs (Architectural Decision Records). Once I have them done, I'll begin publishing them here.
I’m writing this for me, but who knows, maybe someone else will benefit from this app, so I might as well design it, write it, and deploy it the best possible way.