Web application architecture, Part I: minimal app

83
beginner
basics
In this article we review the architecture of minimal web application, how it's different from web sites and why you'd like to know it.

Even if you don't code it's always very useful to understand what you are building and why it's constructed in this way, not others.

In this article we review the architecture of very minimal web application and tell you how it works:

Backend and frontend

All web applications has 2 fundamental parts: the backend and the frontend.

The backend is a program that is running on the server. This program consists of the code that does all the important thing that is better to hide from the end users:

  • register / login / change passwords
  • database operations
  • inner logic
  • account maintenance
  • routes control
  • communication with 3rd party libraries and so on.

The frontend part works in the browser and consists of JavaScript code. It also includes HTML and style files, images, data files but its main goal is to provide the logic for the immediate interaction with users.

For example, it can be:

  • obtaining data (like user name and password)
  • validating data before sending to the server
  • providing visual effects that makes the experience rich and interactive
  • providing services for data processing - like editing texts and images, doing calculations, showing data and providing its editing.

The frontend code should never expose any sensitive information or data that can be used in malicious way. For example, many 3rd party libraries gives the access to their data and functions. To make some changes sometimes it's enough to "show" them some key (that is the long sequence of letters and numbers) but you don't want to put it to the frontend because it can be easily obtained - browsers can't hide the JavaScript code. Moreover, many browsers have utilities to show the code in more convenient and readable way what, of course, makes the developer's life easier but the same moment makes the code even more vulnerable because everyone can see your code easily.

There is no way to make the code unreadable because JavaScript is not compiled into the code that a computer can understand (eventually is, but only when it's already read) so the golden rule is "never store or use any sensitive information in JavaScript".

Technology used for our web applications

We use Python for the backend but not only a pure language - it's a framework created specifically for the web applications called Flask

All the frontend code is written in JavaScript framework called Vue.js, we also use any other libraries that can help to develop the code faster like jQuery or Lodash.

The structure of the minimal web application

It's shown in the following picture:

It may look a little bit messy on the first glance but there is a definite logic.

Backend (red files) are the root files application.py (Python file) and config.py that are responsible for starting the application and loading its configuration (important data). Other backend files are API files (functions for interaction with browser) and so-called "blueprints", or module files. We have only one main module (blueprint) in this app.

Backend templates (orange) are HTML files responsible for showing information and views that users see. They could be the backend and frontend ones. Here are backend templates that actually are rendering on the server and returning the final result to the user. It may be useful for SEO purpose (search engine optimization) or to hide the logic of application. We will touch the SEO problems in another article.

Frontend files (blue) can be found in the /js folder. It's the files servicing pages (JS code is loaded into browser coupled the pages).

Service files (green) are not used during the running application but we use them to:

  • install all the frontend and backend files and libraries used in app
  • specify the type of application and how to run it (instructions for the server)
  • build the front end code and transform it from the presentation readable to developers into the presentation that is more convenient for the browser.

Where are backend and frontend parts in Caravel Studio

Now, let's have a look at our project in Caravel Studio. Where are these parts can be found?

Web page layout and stylesheets are definitely the frontend parts (it's not about where these editors work but about what code they produce - both produce frontend code):

If we look at the workflow we used in the previous tutorial (How to create a landing page with email form) we can see both parts in action:

User event and Edit control modules are both the frontend parts. User events just listens to anything happening with a web page while it's working in browser. Edit control also set up properties of controls on a page in browser.

The Send email module is different, though. It's actually a mix of parts. First of all, it sends the request to the server (with email data) and it's done in browser. But on the server the backend part works - it gets the data, initiates email sending and sends the result back. Currently, Caravel Studio doesn't have any pure backend parts but it will have many in the nearest future.

When we publish, or deploy our app, it generates backend and frontend code, sets up the structure shown at the very beginning of this article, and build the final project that will be sent to the server after.

Questions and answers

If webpages are just HTML code why can't we just put them into the folder on the server without running any server-side application?

We actually can. Such "applications" are called "static websites". They consist of set of pages. You can't put any logic there because there is no "backend" side and therefore, the server will work only with webpages that can contain JavaScript code. 

Another problem is the routing. If you want your route looks like www.mysite.com/about rather than www.mysite.com/about.html you have to change the server's configuration what can be a challenge.

What does the rendering process include?

The Python (Flask) engine goes through the HTML code and, if it sees some variables to be inserted from the data, it does. So, the template at the beginning doesn't look pretty much as a valid HTML code because of stubs - but the engine fills them up and returns as a normal HTML page.

How do I know which information is sensitive and should be hidden, and which one is okay to work with in JavaScript?

When you asked any keys or password, or information like credit card data - it's all the sensitive information. But in some cases exposing keys is ok. For example, if you want to add Google analytics to your website you put the code with their key right into the web page. And there is nothing wrong here - because this key is only used for obtaining analytical data but not for reading or changing it. The rule is simple: if the answer to the question "What happens if a bad guy gets this data?" is like "something awful" - don't expose this data in JavaScript.

Should I worry about the code the Caravel Studio generates? What if it handles the data in a wrong way?

Well, all of us are just people, of course... but we are people with more than 16-years experience so don't worry. We not only put everything in right places, we even don't store the sensitive information in our database. Every password is stored as encrypted string, and we don't store your web app's configuration data at all (we just send them directly to the server which handles it).

If you liked this article, please share it (buttons on the left). Thanks!

Comments

Bert Neleon
July 02, 2019 18:50
Hey,
I've recently heard about such tool as "obfuscator". Can it help to hide the Javascript code from being visible?
Tnx
Caravel Studio
July 02, 2019 19:17
Hi Bert, 
thanks for your question! 
Actually, obfuscators make JavaScript code less readable replacing normal variables and functions name, making the code less readable and tense. But they can't hide it. Browsers have tools making any code "prettier". So, if somebody would like to understand how the code works and maybe, intervene when it's working, nothing can prevent it. That's why the golden rule is "never put sensitive information and functionality" to the frontend.
Hope, it helps.
{{newComment.name}}
Just now
{{newComment.content}}

Leave a comment

Your name:
Your email (never shown here):
Your comment:
Thanks! Your comment has been published!
{{errorComment}}

Get up to date

Get access to the latest news, tutorials, books, giveaways, and useful information for creating web applications

You are good! We will send you updates and release notes as well as any other useful stuff.
{{error}}