Point by point: what you need to know about the backend for a beginner in web development

This article lists the key aspects to consider when creating a backend in the context of full-stack web development. It will acquaint beginners with the basics, and for more advanced programmers it can be useful as a checklist.

1. Authentication

Most applications seek to acquire new users, so a mechanism needs to be developed to allow users to register, authenticate, and change their credentials.

There are two main types of authentication:

  1. Remembering the previous state – implemented using sessions. The user logs in once, and then gets the opportunity to freely move around the application and access protected resources (such as banking transactions or Snapchat selfies) without sending data that confirms their login again.
  2. It does not remember the previous state – it is implemented using tokens. Users do exactly the same thing, but each time the HTTP request is made, the user needs to send a credential. This is usually done with REST APIs. The current gold standard for stateless authentication with tokens is JWT.

There is also a more advanced scenario – multi-factor authentication. It enhances application security by adding additional layers of protection to login and password. Google and Amazon have good examples of implementation.

OAuth is another common scenario. It gives users of your application the ability to register and log in with one click using an account of one of the social networks. Authentication occurs due to the fact that users provide your application with some of their data from the social network, but do not enter it manually.

2. Roles, Permissions and Access Control

Many people confuse authorization with authentication, not realizing that these are different concepts. Authentication determines how the user logs into the application. Authorization, on the other hand, determines what the user has the right to do after logging in.

Confused? Let me explain in more detail. The point of the authorization layer is to grant permissions, maintain the security of personal information, deny access to specific actions and, where required, revoke privileges so that some users do not sneak into the accounts of others and see their private photos. The permissions logic is simple:

User x can do action y on object z.

Let’s apply this in a specific situation: Sharon is an editor and can edit posts. Then you need to define:

  • Sharon’s role is editor;
  • its action is editing;
  • the objects with which she can do this are posts.

How it works? Simple: boolean variables. You return True / False depending on what and who is allowed to do with a particular object. So, can Sharon edit a particular post? Return True if she is an editor, return False and deny access to the post if not.

3. CRUD – Create, Read, Update, Delete

You cannot create users or grant permissions without knowing how to work with resources: create, read, edit, and delete them. This means that you need to learn how to manage application resources, and most often databases are used for this.

But what is a resource? If you are building a bookstore, then books are resources. If you create a group, it is itself a resource and its members are resources too. And also every post or account they use. For example, it could be an official letter to the government, a postcard, or a movie they are trying to buy.

This is where your data structure model comes in. You will need to understand how to solve the following tasks:

  • how to create new data;
  • how to edit them;
  • how to update and delete them.

This is what CRUD looks like when working with the Ruby on Rail framework, which provides an Object Relational Mapping (ORM) layer:

  1. #create a new student record
  2. student Student.new first_name ‘Ann’,: last_name ‘Smith’,: birthday ‘1986-08-11’)
  3. #save the above entry
  4. student.save

Also, your resources rarely exist in isolation. Most often they are associated with some kind of relationship or association with other resources. Let’s take a look at a scenario where you want to store information about pairs that a student has. You can create a child resource in student and save it:

CRUD - Create, Read, Update, Delete

Doesn’t it look and read like regular English? But you still have to learn, because in reality, tasks very quickly become overgrown with difficulties! Therefore, you need to learn how to work with databases, choosing the right model for yourself: relational or NoSQL.

Note that for CRUD tasks, you will also need to learn how to validate input and check permissions before you do anything with that data.


To manage resources in your application (such as books or accounts), you need to implement a software layer that accepts requests and generates responses. This is where you get to work with routes and controllers. They enforce the constraints of REST, a style of software architecture for distributed systems.

In a typical Ruby application, the route looks like this:


What happens in the system at this time:

  1. A request for a photo with this route comes and is transmitted to the controller using the show method.
  2. This method, by accessing a resource from a database or another API, generates and transmits a response in HTML or JSON format.
  3. The client (in this case, the computer’s browser) receives a response and displays the photo on the screen.

Requests can come from many sources (called clients). Most often, requests for a web application are generated in the browser input form. But, if you are writing a backend for a mobile application, then the client is the API of the application, and it sends GET, POST, PUT, DELETE requests from the application.

You can design a responsive system by creating a REST-aware API. This API is called RESTful, read more about it in the detailed article.

5. Forms and states

Forms are the most common way for users to communicate with an application. Basically, through them, users enter all the data.
You need to create forms to interact with the backend: if a user orders a ticket to a concert, then the form should look like a grid of seats:

Forms and states

When the user starts interacting with the form, you need to do the following:

  1. Based on the application rules, validate the information entered by the user and show errors or a successful validation message.
  2. Change the name of a state or form depending on who is trying to do what.
  3. Allow the transfer of data entered by a verified user with sufficient rights to the backend for processing.

6. API

For your application to become really popular, you need to start sharing data with other applications. For example, say you’re a music company and you want streaming services like SoundCloud to deliver your content, and users can buy your music directly from their app. This is where the API comes in.

The term API, an abbreviation for Application Programming Interface, refers to the infrastructure that allows other applications to interact with yours.

The main stages of writing an API:

  1. Create an API server. The stage involves providing secure access to the resources that you want to transfer to clients. If you have a bookstore, your API will provide book titles, prices, and publisher information to other sites and resellers.
  2. Protect the server using application IDs and secret keys.
  3. Make clear, interactive documentation that allows other developers to view and interact with each other and with you.

7. Notifications by Email, SMS and Webhooks

When a user takes an important action in your application, for example, subscribes to updates, creates a new account or project, he must know whether this action succeeded or not.

Notifications are a way to inform your user about the status of an action and help them organize the workflow in your application.

For different cases, you can use different notifications:

  • notifications on the app screen;
  • emails (email verification or purchase confirmation);
  • SMS (authorization or completion of a transaction);
  • real-time webhook notifications for chatbots who have accessed your application on different platforms, for example, Facebook, Telegram or Slack;
  • Regular emails with purchase invoices and subscription billing information.

8. Subscription and tariff plans

Thinking through tariffs only seems unimportant, but in fact it is often necessary. You will have to learn how to create tiered pricing plans and assign specific roles, permissions, and privileges to users who subscribe to a specific plan. It’s also a good idea to learn how to provide dynamic pricing based on the properties that form each pricing plan. For example, buying a new server on AWS or DigitalOcean gives users the right to choose memory, processor, etc.

Useful tips for designing tariff plans:

  • highlight the recommended option;
  • allow users to choose currency and payment period (month year);
  • provide the first month for free for successful user engagement;
  • highlight reviews;
  • sell benefits instead of features;
  • let users know that they can opt out at any time;
  • allow users to select features of interest and configure billing plans.

9. Interaction with the payment gateway

You will need to process your credit card information using forms that usually look like the interface of an online store.

During the transaction you need:

  • ensure that credit card information is not stored, passed to other parts of the application, and securely sent to the payment gateway for processing;
  • accept payment if the transaction was successful and send a notification that the payment was successful; otherwise, send a notification about the failure and invite the user to try to pay another time.

You can also use third-party services, such as Paypal, that allow you to integrate their interface in the form of a form (or button) into your application, and then transactions will be partially controlled by this service.

Don’t forget about invoices people need transaction documents to pay taxes, etc

  • create a section with accounts, which is part of the user profile;
  • make convenient sorting and export of transaction data in the form of invoices in PDF format;
  • make sure users can email these invoices to themselves.

How does the payment gateway work:

  1. Your checkout forms send the purchase details to the payment gateway for processing.
  2. The payment gateway transfers the transaction data to the merchant’s bank.
  3. The merchant’s bank transmits this transaction information to the bank that issued the buyer’s card to authorize the transaction.
  4. The bank that issued the buyer’s card either approves or rejects the transaction and sends the information to the seller’s bank.
  5. If the transaction is approved, then the bank transfers the funds to your account.
  6. Once approved, the third-party payment gateway sends the transaction details and response to your app.
  7. Finally, you send a notification to the buyer telling you if the transaction is approved.

10. Uploading files

It is very likely that when users start working in your application, they will store their data in it, which is not only information in your database, but also pictures, videos and PDFs. So you will need to:

  1. Allow uploading only files of certain formats.
  2. Check files for exceeding the allowed size and reject downloads that are too large.
  3. Show the download progress to the user.
  4. Make sure the download is asynchronous and does not disrupt the frontend.
  5. Allow user to mark files as private public.
  6. Allow the user to export the loaded data.
  7. Create a media library to filter and manage files (optional).

11. Third party APIs, frameworks and packages

Ruby, Elixir, PHP and JavaScript already have thousands of packages that can be customized and applied to your application. They are easy to embed with the command on one line in the terminal:

Third party APIs, frameworks and packages

If you don’t include third-party code in your ecosystem, then you have to deal with low-level issues like session creation, hashing and protection against CSRF attacks, and the like, instead of focusing on the high-level tasks that make your application unique.

Most often, frameworks are composed of separate packages, which, if desired, can be replaced with more suitable for your tasks. You can evaluate the quality of the package source code by the following points:

  • repository badges;
  • date of the last update;
  • passed tests;
  • popularity, for example, according to the rating of users in the stars;
  • number of resolved issues and open pull requests.

12. Working with Open Source

You will face the fact that already existing packages do not perform the necessary tasks or do it incorrectly. However, there is always an opportunity to customize their functionality for yourself, so learn to work with someone else’s source code. Helpful hints:

  • read the documentation and look for answers before asking questions;
  • visit the official package page on GitHub or Bitbucket, review open and resolved issues, and perhaps you will find a pull request that contains the required functionality;
  • you can also implement the necessary functionality yourself and send it to the authors, contributing to the development of Open Source. If your code is not accepted, simply use your version instead of the original package;
  • if you do have to write your functions from scratch, make sure you create them for universal use so that others can use them too.

13. Management interface

Once you release an app, users will want to manage, customize, and personalize it. To prevent them from breaking anything, it is worth limiting their access by providing a nice and easy-to-use control panel. It is not as difficult to create as it seems, and you can use most of the functions written for it elsewhere.

A good control panel should have the following properties:

  • protection from external attacks;
  • correct display for users with different access levels;
  • nice design and ease of use;
  • focus on the most frequent tasks;
  • the ability to add external components;
  • the ability to replace unused functions with new ones.

14. Caching

A beautiful and user-friendly frontend often consists of complex layered data that can be slow and resource-intensive to display. Without caching, your database will be forced to execute nearly the same queries over and over again, leading to overloads.

Imagine a middleware in your application stack that stores static data and provides it on demand, without going back to the database. This is the cache.

How does caching work in web applications? The following types of mechanisms can be distinguished:

  • content caching. If the content of the web page does not constantly change, then there is no need to regenerate it every time. An entire HTML page can be cached;
  • fragment caching. Sometimes an entire page cannot be cached because it has content that is constantly changing, but there are also parts that change slowly. HTML for these static parts is generated only on the first request, and on repeated requests it is fetched from the cache;
  • data caching. Often, a web application is based on a database, but it is quite expensive to retrieve information from it each time, so frequently used data is cached in the application’s memory or in other storages such as Redis, Varnish, and Memcached.

15. Components

This is more of a frontend, but since you’re a full-stack developer, you need to split your code – both page templates and backend services – into modular components if you don’t want to get confused. In my favorite project, the frontend is organized as follows:

  1. {% include ‘_components / global / _header’%}
  2. {% include ‘_components / services / _masthead’%}
  3. {% include ‘_components / services / _svc-stats_blok’%}
  4. {% include ‘_components / services / _client-list’%}
  5. {% include ‘_components / services / _sol-portfolio’ with {‘brandColor’: BrCore}%}
  6. {% include ‘_components / services / _customers-blok’ with {‘brandColor’: BrCore, ‘topConnector’: true}%}
  7. {% include ‘_components / services / _why-aranca-c’%}
  8. {% include ‘_components / services / _svc_box_grid’ with {‘data’: entry.experienceRichtext, ‘brandColor’: BrCore}%}
  9. {% include ‘_components / services / _featured-case-study’%}
  10. {% if entry.tfilterRichtext | length%}
  11. {% include ‘_components / services / _table-filter’%}
  12. {% endif%}
  13. {% include ‘_components / services / _full-cta-a’%}
  14. {% include ‘_components / services / _kc-content’%}
  15. {% include ‘_components / global / _footer’%}

The above code is from a Twig template that can be easily modified. In addition, if one of the components fails, the operation of the entire page is not disrupted. For example, if your authentication code is in the control layer, it would be much better to remove it from there and form it as a separate component.

16. Version control systems

This, of course, is about using Git and GitHub. For beginners, using Git seems overkill, and its benefits are not obvious, so I suggest thinking about situations that you may encounter while writing code:

  1. If you are going to work with other developers on the same project, then you will use a common set of files. How exactly do you plan to avoid inconsistencies when changing your code?
  2. What if you want to revert an older version and see how you accomplished a particular task before continuing with development?
  3. What if you want to rollback a project to the latest version that hasn’t crashed yet?
  4. What if you want to share your source code? Will you archive it and send it by e-mail every time you add a new feature?
  5. How will you keep track of which files have changed and which have not?

17. Command line

The interface available to the user has a limited number of buttons, which are not enough to fully control the application at all levels. But for this there is a command line that will help you add modules to the infrastructure of your application, test it and put it on a remote server.

18. Questions on Stack Overflow

If you can’t figure it out for yourself, then ask on Stack Overflow. And in order not to seem ridiculous in the eyes of experienced users and get an exhaustive answer, ask questions according to the instructions.

Leave a Reply

Your email address will not be published. Required fields are marked *