Application Server Architecture

I want to share some thoughts about the code structuring within an application server. In this article I use the pretty much generic term ‘application server’ to relate to the server that is executing the main parts of your applications logic. It could be implemented using PHP, Python, Java, Go-lang, Ruby or of course, as most content in this blog, Nodejs/Javascript.

When I got into software development it was all about MVC. Describing the separation of data, logic/code and view. The data or models where implemented using active records, DAO libraries or some mixed form. Views where often implemented using various template languages. JSP, twig, ejs, jade/pug. You pass in data and it generates the HTML the user should see. In the last years, single page applications with angular, vue or react kind of became the standard. Controllers represent the code that get executed when the user trigger the call of an API. Based on these three components, you can find hundreds or thousands of graphics and diagrams showing them arranged in various ways.

As we have today usually SinglePageApplications, I think we can start removing the V from our application servers MVC. I want to propose a different model for your mind. The model of pipes. On the one end, the commands flow in on the left, read or update data on the right. In between is your code. It is important, that the logic, commands, API calls, function calls only go horizontally. They never go vertically and they never go in circle.

How to achieve this?

On the one end you have controllers, in nodeJS they can be express router, graphql resolvers or similar, On the other hand you have data, using sequilize or a DAO library, it does not only access your database, but also third party services. In between is where the interesting logic is. You might want to call these services, Some services directly provide access to a single table, such as the user table. These services, should not have any other services as their dependency. Otherwise you might end up with circular dependencies.

Instead, when you have a functionality that effects multiple tables and other services, you introduce a higher level service. Now it is possible that your application grow, and you will