The steps in web development

Traditionally, you have a few steps to create web applications. Just think about Netflix. You have a designer that makes the design of the application. That design needs to be integrated by a UI designer or a frontend developer. Integrating a design means that you transform the beautiful design you made to code (or something that the computer can understand). In the picture below you can see the famous design of Netflix.

Now the next step comes. When you hover over the images, they should start moving and you should be able to play a movie. This is where frontend and backend development come in. The frontend will ask the backend to load the basic data about the movies from the database while the frontend will make sure that there is interactivity (the Friends image starts playing a small movie when you hover over it).

When you press the Friends image, a new window will open. At this moment, the Netflix backend is requesting the movie in the database. This moment is really important, because you don’t want to wait too long for your movie to load. While the movie is loading, the frontend will already show you a picture with a red loader to notify you that your movie is coming.

When the backend is ready retrieving the data from the database. The frontend can play the movie.

Now of course the reality is a lot more complicated than that, especially in Netflix’ case, but that is the general idea.

All the design integrators, frontend developers and backend developers write their code in the codebase. This codebase contains all the code that is written by the developers and integrators to build that application. You can compare this codebase with a gigantic Google Drive with different folders and Google Docs. The folders describe different parts of the application while the Google Docs contain the actual code.

The Texidi app codebase

Just like in Google Docs, different people work together on the same part of the code. When developers change things in the code (add new features, fix bugs), they have to make sure that:

1. There are no mistakes in the code they added.
2. Their code they added does not hurt the existing code. For example, it is a common occurrence that when a bug is fixed, a new one arises because of the fix.
3. The changes in their code do not overlap with changes that other developers made.

This is where tools such as Github, Bitbucket and Gitlab come into play. By using these software development platforms, developers can work together on projects, see what changes have been made to the code, and accept or reject these changes.

So when changes have been accepted, there is still one step that needs to be done. Just because changes have been accepted in the codebase, doesn’t mean they are automatically reflected in the actual website. This is where DevOps, Continuous Integration and the Cloud come in. In the next blog post, you will find out how they make sure that the work that developers do can quickly be reflected on the actual application.

This blogpost is part of Texidi’s mission to make tech understandable for non-tech profiles. Check out other blogposts explaining tech terms in an easy and fun way.

Follow us on LinkedIn and Instagram to be the first to receive the latest news about our new podcast Recs & Devs, our blogposts and much more!

Check our website to learn more about Texidi.