Weekend Thoughts on Loosely-Coupled Architecture

This article is to summarize a very high-level overview of loosely-coupled web systems architecture along with some of its advantages. In software development, coupling typically refers to what extent different software components/modules depend upon each other. With tightly coupled components, each component and any supporting dependent objects must be present at execution time as well as compile time. On the other hand, loosely coupled components can operate independently from one another.

As a developer, architect or a product manager, loosely coupled architecture is helpful in designing better workflows which will modularize the code, fence off the bugs and have an enhanced overall stability of the system.

Introduction to Decoupling

Generally, web applications contains some common components like a front-end interface web or mobile, a back-end service, an application server, a database. The idea is to look at this web system as a set of smaller components that can be maintained independently.

Decoupling means to separate out or dissociate various components so that they could have their own separate development cycle with minimal dependency. At level one, it essentially means to see the front-end and back-end layers as two separate components. Back-end can further be broken down in various sub-components as per their nature of business or responsibilities. Here, the path going towards microservice architecture.

Project Structure

Envision the following stack for a web application:

• Front-end: Ember.js + CSS
• Back-end: Java + Jersey
• Application server: Glassfish
• Messaging: Kafka
• Database: MySQL
• Load balancer + Reverse proxy: HA-Proxy
• Deployments: Ansible

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

The project can have two separate Git repositories.

• Front-end Repository: To store frontend Ember+CSS code
• Back-end Repository: To store backend java code

Details

REST Back-end

Accessing the back-end with REST APIs is pretty much standard when question is to serve different kind of clients, be it web or mobile. One back-end for all. Sessions have become obsolete nowadays. In fact, REST in it's truest sense, discourages use of sessions in applications for getting/setting the attributes.

Application's APIs should be stateless in nature. These should be designed using the Token bases authentication mechanisms.

The Jersey Rest Framework provides standard APIs to develop REST implementations.

Use of session object is obsolete now. REST in it’s truest sense, discourage using sessions for the application. APIs should be stateless. APIs should be designed using Token based auth to be RESTful. Here is a good source of REST best practices.

Messaging

Asynchronous messaging becomes an important aspect in a loosely coupled architecture. Use of Apache Kafka can greatly improve the inter-communication between different modules of product.

User Authentication

Use of JSON Web Tokens is standard for user authentication purposes. User registration can be done through OAuth2 with providers such as Google, Github, Facebook etc. and/or the traditional e-mail signup. JWTs can be used with both authorization flows.

Front-end

Post successful login, following API calls from the client should include a Token in their headers. This token will be used to get the user on the back-end for further processing. No sessions, no headache, period.

All communication must be over SSH, otherwise, tokens can be exposed on the web which could cause serious security problems.

Deployments

Since there are two different repositories for front-end and back-end code, decoupling of deployment procedures would also be a nice idea. Again front-end and back-end services would have a different set of dependencies so separating out deployment is much sensible.

Advantages

In terms of engineering/development:

• Codebase would become modular hence can be separable into clean & cohesive modules.
• Bugs are isolated to either front-end or back-end which would definitely shorten the resolution path.
• Scalability becomes easier and more manageable. Having a REST back-end would open up way to micro-service patterns as well. Also, in the absence of session-based back-ends, it becomes easier to scale the application to millions of users when needed.
• Loose coupling ensures that the components/services are decoupled from other components in location, protocol, and time.
• Unit, integration and stress testing can also have separate work-flows. Testing, in general, becomes more manageable, fast and effective.

In terms of product management:

• Specialized work-flows can be developed among teams.
• Teams can be built around specific components of the stack. Need to improve the UI/UX? Hire a UX guy. Need to support mobile devices? Hire experienced mobile app developers.
• Standardization of protocols or tools for team specific to their work is possible. Can be useful to limit the development cost also.
• Team rotations can be regularized to eventually make all developers comfortable with the entire stack. Improves the overall knowledge breadth of the team.
• Less inter-dependencies aids in development of rapid prototypes.
• Since teams will be separated based on services. Coding practices, common practices across project can be standardized both specific and generic to teams. For example, specific icons packs or HTTP codes should be circulated to all product teams.
• Also aids in better implementation of the Agile model.

Conclusion

Building and deploying applications using a loosely coupled architecture provides various advantages like scalability, resilience, maintainability, extensibility, location transparency, protocol independence, time independence, systems become more scalable and predictable.

If there is anything that you guys would like to add to this article or if you find any slip-up, feel free to leave a message and don’t hesitate! Any sort of feedback is truly appreciated.

Thanks!