The Dream Architecture

Many programs are web and mobile apps these days. Although different apps may solve different problems, they still have many shared needs.

I will attempt to escape from reality a bit and dream. Somethings may not be so simple yet, or tools may not exist, but there should still be practical reasons behind these wishes.

The dream architecture should have solutions to what most apps need: Logging, collecting metrics, automated testing, and deployments.

There should be no vendor-locking, a.k.a. it prefers open-source, or at least open protocols and interfaces.

It should be opinionated, have default tools to most common challenges. This doesn’t mean there should be only one way to do one thing. Every solution has tradeoffs, so no solution-locking.

It gravitates to a single programming language — possibly JavaScript, or perhaps, something that compiles to JavaScript. Any developer in the project can understand what the backend and frontend code is doing. Some features might need to be more performant and implemented in another language. Remember, you can have more than one opinion.

It makes code and component sharing between platforms possible. Although there are enough differences between iOS, Android, and browsers, there are still enough to share.

HTTP should be used to fetch pages and assets. Web sockets are the primary way to communicate with the backend. This way, the backend can be more proactive, and the communication can be more performant and in-sync.

The frontend should be able to operate offline where possible. I wonder if there’s a protocol that can make merge conflicts seamless. Or, at least, there should be a tool to detect branching and provide options to overwrite, accept, and merge.

The dream architecture should prefer views and materialized views over caching. Getting caching right is tricky. Instead of dealing with two unrelated systems, cache and DB, the backend should use views to compute on-demand and materialized views to pre-compute. Caching should only be used for non-critical data. Choosing correctness over performance is generally a better tradeoff.

The world is huge, and most people don’t speak English. Internationalization may not be needed for a minimum lovable product, but the capability shouldn’t be tacked on.

For fast development experience and easy debugging, all pieces should be able to run locally. And the subset of data should be available. Why do we only care about scaling up? Scaling down to one machine is good too.

It is all about tradeoffs, but no feature should be too hard or impossible to implement that otherwise be possible. If the tradeoff is around performance and a feature depends on it, it is okay to change the opinion.