Perks of a decoupled architecture

Context

The context of this article entails decoupled web architectures. If you’re a developer, an architect or a product manager, this should assist you in designing better workflows for your team, modularize code, isolate bugs and have enhanced overall stability of your web application.

Introduction

Broadly speaking, any production-ready web application contains a front-end (mobile/web), a back-end, a database, an application server and a static file server. The idea is to separate this web system, into smaller components that can be maintained independently.

Decoupling, in it’s broadest sense, means to separate or dissociate components. In terms of a web system, it essentially means to have separate front-end and back-end systems.

Project Structure

Consider the following stack for a web system:

• Front-end: AngularJS
• Back-end: Django
• Application server (for Django): uWSGI
• Static file server: nGinx (also used as a reverse-proxy)
• Ansible for deployments
• Postgres Database

Note: The purpose of this article is by no means limited to this technology stack, any framework/tool can be used to implement such an architecture.

The project can (should) have 2 Git repositories.

• Front-end Repository: Store all your Angular code here
• Back-end Repository: Store all your Django code here

The production server will have to be set up by installing various packages necessary for the web application to function (I shall be covering best practices on setting up a production server on a different article, later on).

Details

REST Back-end

Having a completely REST back-end will help serve different types of clients, be it web or mobile. One back-end for all.

The Django Rest Framework provides an intuitive and easy work-flow to develop your REST APIs.

Sessions

Gone are the days of using sessions. REST in it’s truest sense detests using sessions for your application. Your APIs should be stateless. Switch to a Token-based auth and design your APIs to be RESTful. A good source of REST best practice: https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

User Authentication

Use JSON Web Tokens for your user authentication. Your app may allow user registration with OAuth2 with providers such as Google, Github, Facebook etc. and/or the traditional e-mail signup. JWTs play nicely with both auth-flows.

Front-end

Upon successful registration/login, all concurrent API calls from the client will include a Token in its headers. This token will be used to fetch the user on the back-end for further processing. No sessions, no headache, period.

SSH

Make sure all communication happens over SSH, if not your tokens will be exposed on the web. This can cause serious security problems.

Deployments

Since you have 2 different repositories for your front-end and back-end code, you deployments can also be decoupled.

Your back-end services may reside on a different set of servers as your front-end modules. Your front-end server’s system dependencies will be different from you back-end’s. Separate deployment scripts can and should be used for your project.

Advantages

Having decoupled architectures has its perks.

In terms of engineering/development:

• Modular code: You can split your code into separate & clean modules
• Bugs are isolated to either front-end or back-end
• Scalability becomes easier and more manageable. Having a REST back-end opens doors for micro-service patterns as well (more on this later). Also, when you do away with session-based back-ends, it becomes easier to scale your application to millions of users.
• Unit, integration and stress testing can have separate work-flows. Testing, in general, becomes more manageable and effective

In terms of product management:

• Separate work-flows can be developed for your teams
• Teams can be built around specific components of your stack. Need to improve the UI/UX? Hire a JS/CSS guy. Need to scale your database? Hire an experienced developer. Once the architecture has been set-up, you can build your teams according to the needs of your application
• You can standardize protocols for your team specific to their work
• Team rotations can be regularized to eventually make all developers comfortable will the entire stack
• Rapid prototypes can be developed without the need for interference of back-end resources
• Since teams will be separated based on services, coding practices can be standardized both specific and generic to teams. For example, knowledge of specific HTTP codes should be circulated to all product teams
• Since multiple minds will work on different components of a feature, overall feature stability will improve and the software development becomes more, agile if you will

Conclusion

Having decoupled architecture will save a lot of time and effort for both technical and business teams. The code becomes more manageable, systems become more scalable and predictable.