Why you should separate your Fronts and Backs
Of I course I mean the Frontends and Backends.
Frontend is what the user sees and with which she or he communicates. Like a Webpage. Or an app.
Backend is the invisible part. Which stores your data for example. Or provides the pictures.
Now let’s look at the classical example of a web page. The frontend is a browser showing a HTML page. The html describes the page structure and graphics, The backend is a server that can be talked with via HTTP. The HTML of course can’t send network commands, so it needs functions that are built-in to the browser, like…
<img src=’www.mypage.com/photo.jpg’/>
…to show a picture.
Or Javascript functionality that makes some more sophisticated communication, like the address information that you just wrote into a form.
In the http backend however, you have so called ENDPOINTS. The most common ones are called GET and POST. Usually, every frontend piece has one backend piece. Like a GET for the picture to be shown, and a POST to send your address data to the server (backend).
Now there are technologies like Microsoft’s MVC and Razor that try to simplify the development, and offer solutions in which the frontend (html) piece and the backend endpoint are kind of mixed together. I don’t want to go into the details now. But anyway I want to point out that I don’t like it at all when I see this kind of structures!!! It’s a very straight forward way which allows quick programming. But it has a lot of disadvantes in my point of view:
It’s easy to mix logic
That a ‘name’ field mustn’t be empty, can be checked in the frontend. To check if an address is valid, can be a complex operation with other online services involved. That should be a job for the backend. Between these 2 examples is the fundamental difference if there must be a communication through the internet or not. With great availability, speed and prices for internet, we (developers) start loosing the consciousnes for that. But we always have to be aware and stay in control of what happens behind the scenes (behind the browser), and if Getting and Posting stuff is necessary or useful.
It’s easy to create messy data
There’s something called FormData. To be a bit cynical, it’s about packing everything together that the user clicked or wrote in the page, and throw it to the server. The backend programmer then has to take this mess apart and write his software based on that structure. When the frontend developer makes structural changes in the page, it can (at least often) lead to breaking changes in the backend.
It’s easy to look ugly
Not only is it about what data to send back and forth, but also the rendering. Rendering means putting together certain controls and geometries, which is what the user will finally see on the screen. This can NEVER be the responsibility of the Backend. For this, we’re living in a world with too many kinds of devices. Phone, Tablet, Desktop. User input via mouse with keyboard, or touch only, or a mix of both. High resolution 4K and Retina displays and low cost field devices. Or applications that are plugged into other applications, and henceforth limited artificially – like a widgets in a WordPress page.
And these are just the examples for creating a better – but simple – web page. Now there appeared some specialties on my way, that not just recommend – but loudly cry out for – a separation of backend and frontend:
Support different frontends.
This is what happens in my current project. There’s a classical page, and as well a plugin in a Desktop application. If I created just one piece to start with, and write it in the mixed way, then my second frontend would be a much bigger piece of work later on, because reusing endpoints will have became impossible!! But to keep things nicely separated from the start helps you avoiding a lot of problems in our project!
Freedom for the backend
This is about power and speed. Usually it’s firstly about keeping the frontend fast, secondly about keeping the communication slick and cheap, and only in the last moment about helping the backend to be performant. Of course noone wants costly servers, but it’s always easier to make the servers faster than to make the internet connection or the frontend device better- because that’s not in our hands! BUT … for many years, I had the pleasure of working with industrial applications. When you develop a client that shows data from a real realtime system – like Sercos or Profibus – then you will learn that it’s often the backend (the source of the data) that is limited. Or at least that the frontend connections are always less important than the communication between drives and sensors – which often have to communicate every 1 or 2 milliseconds. And if there’s a delay, the machine goes into emergency stop, or the ice cream is literally flying around in the factory! But backend performance can also be a business problem. If your manager asks you to make the backend cheaper – because he’s sure that all our clients have great internet connections and modern devices – then it can be very complicated for us developers to make optimisations, in the case that our backend and frontend are mixed up.
Your application grows into an API
This is the pure logical argument. Perhaps your system starts being a simple online service, to be accessed via a website. Then the business grows and others want to include your services into their pages. Then you’ll really need endpoints that are independent from any kind of frontend. Then you don’t want difficulties to take advantage of these new business offers. Then you’ll whish you had thought of keeping things more apart.
Actually for me, this is part of how I’m looking at architectures. I hope my explanations will help you in designing your systems better. To really master this separation, we don’t just have to try to look at the interfaces, but always stay up-to-date with the standards and technologies involved. Some pieces of the system are indepent of certain implementations – like the concept of DDL, TDL, SPA and OAuth. But then you’ll also have to include the right tools and technologies in your portfolio, that help you implementing these concepts – like Angular, .NET Core and Swagger for example.