Split Stack Development: A Model For Modern Applications
Development stacks are a highly regarded topic amongst developers, and for good reason. Choosing the right development stack is one of the first and most important decisions you have to make at the beginning of every project.
The problem with this model is that it tightly couples front-end and back-end development into a single development stack and imposes restraints on technology choices.
But whilst this has been the best solution for some time, this was primarily due to poor performing web browsers not being able to handle complex operations that are required to run a modern day website.
However, IE7 was a long time ago and browsers have come an extremely long way since then. They have evolved from simple page viewers that were limited to presenting content and basic DOM manipulation, to becoming an extension of our Operating Systems.
Since the emergence of more powerful and high performance web browsers we have the opportunity to not only allow more of the processing power to be handled by the browser, but to define a clear separation of front-end and back-end development and move away from this tightly coupled model.
Split Stack Development Modal
Split stack development is an architecture pattern that separates front-end and back-end development into two separate “stacks” which function independently and communicate through an API.
By decoupling front-end and back-end development you eliminate any restraints on technology choices that each may have imposed on the other. This results in completely independent stacks used on the client and the server. For example, you could build the back-end using PHP or JAVA whilst the front-end could be built using Angular or React, a stack that was difficult to achieve previously.
With front-end and back-end split we not only allow both layers to be developed independently, but also simultaneously. Because neither stack is reliant on the other, they can be developed at the same time. At the beginning of a project the API structure is outlined giving clear visibility on how both the front-end and back-end will communicate.
“Content can be driven into the front-end application without any back-end framework in place”
Once this is defined, the front-end can be populated using ‘mock data’ to simulate the API. This means that content can be driven into the front-end application without any back-end framework in place.
The same benefits are also true for the back-end. As requirements won’t consist of any presentation elements, development can be started and completed without actually being bound to a view layer.
Once both the front-end and back-end have been built, the API endpoints are married up and live data is passed between the two.
Skilled Working Environments
As a front-end developer, one of my biggest pain points when joining a project is setting up the development environment. This can be be for a hundred different reasons, but more too often than not, it involves database setups or server configurations, a domain which is not part of my expertise. These are back-end development issues, which a front-end developer shouldn’t have to deal with or try to resolve.
Front-end and back-end developers are different beasts with completely different skill-sets and they shouldn’t have to setup or work within each other’s environments. By having seperate stacks, you eliminate this problem and allow developers to work solely with code and configurations that they are accustomed to, thus allowing them to understand problems, resolve issues and focus on their part of the development project. This allows back-end developers to get on with using server-side technologies to build high performance, robust architectures, whilst front-end developers can focus solely on user experience and visual design.
These are only a few of the benefits of a split stack development model but it can be extended to include a much wider array of benefits; a reusable API, the ability to upgrade layers independently, debugging in isolation and even simple hiring of single-skilled staff. But most importantly, by reducing the dependencies between each layer of the application, you are reducing the chance of development blocks and allowing projects to be completed with potentially less complications and within much shorter timeframes.