The Future of Back-end Programming
Programming has come a long way since its beginnings. At first, engineers were both creators, programmers and users of the computers. Long time after a need emerged for users of the software to be physically separate from computers where the software is actually running and a new paradigm was created — separation to clients and servers.
In the start of web applications server application was responsible to create HTML for browser to display and handle actions like adding, editing or deleting. At first there was no JavaScript and CSS, so all that was considered programming was done by the same programmers that created application part running on servers. Later when application processing demands grew higher and client’s computers grew stronger there came an idea to move some of the processing to clients. And so there came a separation on front-end and back-end programming. This indicated that there is a need for specialization of programmers too.
Today, when front-end grew in terms of technology, frameworks and tooling, many developers tend to think of back-end as a thing of the past. Most young developers prefer Angular, React or one of many JavaScript frameworks and consider these a silver bullet, all-mighty solution for any problem. Even to a point that there is no need for back-end. So, is back-end dead?
Let’s go through what can be done by using which technologies.
User interface with all the input and display elements and styling could be naturally done in HTML and simple CSS (or any variation). Once you go to domain logic with objects and operations changing them, it’s not so clear.
Today, web applications are built to service a large array of needs in many different domains. Some of these are very small. So when one tries to map it to code, perhaps there’s not much (or anything) to map. Perhaps this domain does not have to be reused from multiple applications. Perhaps it can be implemented in front-end too.
When you consider larger applications in terms of domain or applications that have a higher number of clients, things move toward a lean client which is focused on UX and a rich and complex server-side application which services these clients. More If clients are not only browser-based front-end applications and include platform specific applications for Android, iOS or similar this makes even more sense because of application maintenance and deploying new versions, both of which are easier to do on server.
When it comes to persistence, which is needed by huge percent of applications, it is usually done in databases and sometimes in local files. But, for a front-end application local (in client’s computer) database does not exist and only possibility is to use local storage in browser. This is only meant and natural to use for smaller amounts of data. So, if a front-end application needs persistence of data — it needs a server-side database. Database is not usually accessible from JavaScript directly. Hence, persistence needs some server-side application to store and fetch data.
If there is an existing application or a suite of applications that are working and collecting data on users, feature usage and similar this data might need some processing and transformation to other forms of data. This processing can only be done at the time of creation (which is expensive and cumbersome for a real feature) or by an application that runs as a service on servers.
When there are larger applications that need some integration between them, this is usually done by exposing services over back-end applications that offer data in common formats. Some of these services process large amounts of data and need message queuing systems and scalability over micro-services in clusters to handle that properly.
Today, back-end is used by any system larger than the very small. While it may be very thin for smaller applications it may also be very complex for larger systems. Any large business moves toward the latter. All that is changed from initial web applications is that traditionally back-end technologies are not exclusively used to build all parts of the system. Also, technology reasons have cut this in half and front-end and back-end might be considered as separate applications.
As specialization is a general tendency in software development, it is so in back-end as well. We might talk about different aspect of back-end programming: server-side for web sites, services, integrations, business domain, micro-services, message queuing systems and database programming. Depending on the technology stack, you can choose a variety of frameworks and libraries, many of which are modern, lightweight, maintained and widely accepted in the community.
So back-end is still here. And it’s here to stay.
