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:

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.

 
61
Kudos
 
61
Kudos

Now read this

Nike’s iOS-first mobile strategy

http://mobile.theverge.com/2013/2/11/3976734/nike-not-working-on-fuelband-android-app Right now, we’re focused on iOS and the web I think this hits upon a continuing trend. If your app is targeting up market North Americans, then you’ll... Continue →