Modern applications are consumed by different types of users. Users also have multiple entry points to applications. For example – a user might access the same application from the mobile app and visit the application using the laptop another day. Product owners, Application architects, and developers all have to realize that this is going to be the thread in the future. Two future interfaces that are currently popularized are Chat bots (Messenger, Telegram) and Home assistants (Alex, Google Assistant).
Layers of the Architecture
Main three layers of the architecture include the User Interface, Application Services Tier (AST), Core Services. Your application users’ primary point of contact is the user interface. Once the user does an action on the interface, the application services tier is engaged to serve the user. Application services tier facilitates the action by invoking the required core services.
Usefulness of AST
Application Services Tier provides quite a bit of useful features but most importantly it provides the necessary decoupling of Core Services from the User Interface. The core services set is reusable across multiple application services tiers. The same application can have multiple interfaces which could be Mobile Apps, Web Apps, or even Chatbots.
Application Services Tier provides below services:-
- Application specific logic
- Authentication and Authorization
- Logging and Monitoring
- Push notifications
- Session flows
- External API Integration (Facial recognition, Voice etc)
Modern Application Architecture
Now we have to understand how the application service tier will integrate with other components. Rather than explaining it in an abstract context, I will use an example. Our application is a Food Ordering Chatbot. Our core services are provided by a third party that contains the data of restaurants and the food ordering services. How does our application look in this context?
When a user first interacts with the Facebook Messenger bot, AST engages the app logic in creating a user and replying back to him with a greeting. When the user requests a restaurant recommendation with certain attributes, AST consumes the Core service, in this case, Food Delivery service to request a recommendation. AST also caches the results before returning to the user. This reduces future consumption of the core service.
Once our application is decomposed to the above layers, we will be able to improve our development practices as well. Testability increases since we are able to mock the Core services. An integration test suite can be completely written as if the Interface is interacting with application services tier that would connect to the mocked core services. Another integration test suite can be facilitated to test the core services. This could be used to validate the contract of the core services throughout the product incubation period.
Rapid development of the user interface is possible since the application tier is aware of the user interface consuming the data. Further more, modern technologies such as Swagger documentation makes the development practice faster with generators for Services.
Due to the decoupling of the user interface from the core services set, we are able to independently innovate and experiment with the user interface and application services tier. This gives us the possibility to iterate into Modern communication technologies such as GraphQL.
Technical Architecture of AST
Inside the AST, there are few components. The facade component is responsible for understanding communication protocols such as GraphQL, REST, Web hooks etc. The facade component then hands over the data to a middleware chain. Middleware chain can perform the security checks, logging and caching. The app logic layer is responsible to invoke the core services. There will be several app logic components written that would support push notifications, session handling and external service integration. The cache implementation could be Redis, or MemCache. The App logic layer can utilize an ORM or an ODM to be independent of the database required.
If you look closely at this – this looks quite a bit similar to the micro-services architecture. But this architecture doesn’t require additional API managers nor Message Brokering features. Going forward, this architecture can be improved further more to add such functionality if there is a requirement.
Application Services Layer can be summarized as a pattern that can be used to iterate product development faster. Further more it provides clarity going forward in the iteration cycles due to the loose decoupling it has on the core services tier. The architecture also provides quite a bit of extension points to make the development process smoother with integration testing in isolation.