A good service is an unnoticed service. This is quite true about the back end of any application. If the back end is implemented flawlessly, it’s almost imperceptible, both for people far from IT and for software developers.
This is why it can sometimes be challenging to explain why backend development takes so much time — often even more than frontend development. The frontend deliverables are more material: you can literally touch and see them. The back end, on the contrary, is mysteriously hidden behind the screen.
Let’s think of an application as a car. It’s really important for a car to have a cool design and be aerodynamic, ergonomic, safe, and beautiful. All of the lighting, buttons, switches, and automatic features should be exactly where the user needs them to be. But no matter how beautiful your car is, it’s designed for driving. This is where the back end steps in. The back end is what’s under the hood. Behind all of those buttons and switches must be functionality, and this functionality is provided by the back end.
Let’s walk through the back end of an application, discover its components, and see what it does.
Long story short: The back end handles requests from the front end. The most common flow looks like this:
- The backend server receives a request from the front end.
- Based on that request, the server performs actions with database records.
- The server prepares and sends a response to the front end.
- The front end decides how to display the response to the user.
Yes, it’s that simple. But the trick for the back end is to perform all the required actions in the most efficient way, spending as little time and resources as possible. That’s why the work of a backend developer is almost imperceptible, especially when the back end is architected and implemented properly.
The back end interacts with the database. In fact, all database operations happen here. Typically, a super-admin or superuser has special permissions to access the database using the back end. The place where they can do this is usually called the admin panel. The admin panel provides full access to all information stored in the database by regular users as well as to information generated by the system: user profiles, posts, comments, messages, payments, etc.
Most modern frameworks, like Django, have a built-in admin panel that requires little effort to work with. A built-in admin panel will have basic functionality such as Create/Update/Delete actions for database records.
In the case of Django, the admin panel is highly flexible and customizable, so it can be tuned for any purpose and offer any functionality clients might want.
Time matters when it comes to operations performed on the back end. Unfortunately, some operations take a lot of time. Sending emails, parsing uploaded documents or web pages, and preparing reports for thousands or even hundreds of thousands of records are all things that take a lot of time. But we can’t afford to keep users waiting a few minutes (or even a few seconds) for a response. For operations that take a while to complete, we can benefit from asynchronous tasks. They allow us to put “heavy” tasks in a queue, respond to the user immediately, and (optionally) inform them when the task is completed.
Let’s take a simple Contact Us form as an example. When a user submits the form, the back end should send an email notification to the super-admin. If asynchronous tasks are used, the flow looks like this:
- The backend server receives the frontend request.
- Based on the request, the server creates an asynchronous task that sends an email to the super-admin and puts that task into the queue.
- Without waiting for the task to be finished, the back end sends a response to the front end.
- The front end receives this response and informs the user that the email has been sent.
As a result, users are satisfied, as they don’t have to wait long for a response. Plus, few server resources are consumed. No matter how many users are submitting the Contact Us form simultaneously, they’ll all receive responses immediately and the emails will be sent one by one from the queue (asynchronously). For Django, the most commonly used asynchronous task queue is Celery.
Another powerful feature provided by Celery is scheduled and periodic tasks. This feature allows you to execute operations with a scheduler. For example, you can schedule daily currency exchange updates, periodic payments, newsletter mailings, etc.
Scheduled and periodic tasks allow the back end to perform heavy and time-consuming operations in the background, with minimal impact on server performance.
Sometimes, requirements dictate the back end use external services, or APIs.
Examples of features and commonly used external services to implement them:
- Push notifications (AWS SNS)
- SMS and phone calls (Twilio)
- Geolocation and geocoding (Google Maps, Google Geocoding API)
- Social authentication (Facebook API, Google+ API, etc.)
The good news is that using external services has a minimal impact on server performance, as almost all of the computing happens on external servers. When external services are used, the back end works only with the results that are returned.
But there are some cons, too: The speed of request processing on external services may vary and may depend on factors like the connection between your backend server and external server and the load on (or even the outage of) the external server.
Nevertheless, the most popular external services are safe and stable enough and are successfully used by thousands of clients worldwide. Along with some alternatives and smart backend architecture, most problems can be solved before they even appear.
Usually, you need to pay a subscription fee to use external services, especially good ones. So if your application is going to use external services, be ready to pay for them. But that doesn’t mean you need to have access to all external services beforehand. Any self-respecting software development company will use its own accounts during development and will provide you with detailed instructions on how to obtain your own account for production.
Any application is a system where every element matters. The back end and front end are two halves of one whole. Going back to our example with the car, a gas pedal is worth nothing without an engine, and the engine does nothing without the pedal.
This article barely scratches the surface, but we hope you’ve gained a better understanding of what happens on the back end of an application.