My simple view of web app architecture: Thin Server
What follows is by no means a novel approach to building web apps. It just happens to be the way which I believe allows us to build them in a manner that’s fast, flexible for the future, and mobile app {native or web} friendly.
I’m oversimplifying intentionally, but I see two architectural components for modern web applications: UI Layer and a REST API. Nothing more. The technologies used to build each piece are really up for debate, but the UI will likely be mostly Javascript (I suppose you could use Dart ;)), and the API will be composed of some reasonable backend technology (Java, PHP, Python… whatever works for your team).
This approach is similar to that used on Twitter.com, as described here on their engineering blog, though I think they’ve tweaked it since the time of this post:
One of the most important architectural changes is that Twitter.com is now a client of our own API. It fetches data from the same endpoints that the mobile site, our apps for iPhone, iPad, Android, and every third-party application use. This shift allowed us to allocate more resources to the API team, generating over 40 patches. In the initial page load and every call from the client, all data is now fetched from a highly optimized JSON fragment cache.
What I love about Twitter’s approach, is that moving to an API-first design allowed them to shift more resources to API development. This implies that it simplified the web app’s front end development in the process. This allows the team to have specialists in front-end (JS) and backend, allowing each group to play to their strengths; each group moves faster. Some developers will also move across these boundaries, and that’s great, too. But the point is that there is a clear boundary enforced by a clean API contract.
This simple architecture has many advantages:
- Clear separation. The user interface is completely separate from data and much of the business logic. Sure, you’ll have some business decisions to make in the UI Layer, but they should be rather trivial. Keep the complexity hidden behind the API whenever possible.
- API-first. It fits perfectly well with an API-first development model. One in which developers on the backend can build perfectly testable API end points ready for public, or private, consumption.
- Mobile-first/Reuse. Ensuring we build great a API layer, also known as the UI Services Layer, will enable us to build native/hybrid mobile apps with great velocity.
- Flexible front-end. Front end technologies continue to evolve; even Javascript has a new competitor in Dart. For this reason, having the UI separated from the backend, by the API, could serve as a great advantage as the web continues to evolve.
- Multi-language. With some developers well-versed in Java, and others in Python (or other languages), it seems that building an API layer could be done in multiple languages and tied together with what looks like a single REST API contract. This would keep the language difference hidden behind the API, and not bleeding into the UI layer.
- Dogfooding the API. If the plan is to make parts your API public, then it would be great to have your web applications consuming it just like third party developers. Ensuring that bugs and issues get worked out long before customers hit a snag with the API.
To see the pros and cons for thin server, the approach I’m describing and fat server, the alternative, take a look here.
Again, I risk oversimplifying the solution, but I think this design has great benefits and will help teams to move very fast on front end web and native mobile development. Building with these two simple layers (UI + API) helps keep complexity down, reuse high and retain flexibility for future UI framework changes - as they’re sure to come.
Let’s move faster and keep our app architecture simple.