Author: Dawid Adach
Angular app architecture
Most of the modern application consists of 2 parts: Font-end and Back-end
What is Front-end and what we use?
It's all about presentation.
Frontend which is often called a client is a code which is running in a browser. It's responsible for our presentation part (User Interface). Within Angular we are using HTML, CSS (or Sass) and Typescript to build a front of our application.
Fronted is responsible for displaying data and presentation logic. This logic decides what happens when user clicks on a button or picture or what to do when user navigates to a different page.
Backend usually consists of three parts:
- Application (code)
- Server (on which Application is running)
Backend is used to store the data and it's processing. If you finished a previous tutorial where we have built a Todo App, you probably have noticed that after refreshing a browser, our data were lost. That's because Angular doesn't store the data itself. Instead, it uses an Application Programming Interface (API) to connect to the Back-end system and store data there.
API is a set of functions and/or procedures exposed locally or globally that allows the other applications/clients to create/manipulate/obtain certain data from a server. Although it might sound scary, it's actually quite simple. Let me illustrate it on a real-life example. Each API has certain endpoints and operations. We can call (call = send a request) different endpoints with.
Now, imagine a harbor. Yes, harbor like this one:
So we have:
- A Harbor which is equivalent to our Backend Application
- Multiple Docks which are similar to API Endpoints
- Different Ships sailing which are same as our Requests
- Containers on our ships which carry some Data
Imagine that you sit in another harbor and you want get some stuff from another harbor. What do you do? You send a Ship, to specific Harbor, which goes to a particular Dock, load Containers and come back to you. And this is exactly how API works. While using API you are also sending your Request (Ship), to specific Application/Endpoint (Harbor/Dock) to obtain/give certain Data (Containers)!.
It might sound funny but it really work the same way. For example - if you send your ship to the wrong dock, most probably you won't get containers which you wanted. Same with API if you confuse endpoints. If you send a wrong data (containers) they won't be accepted by the server, similarly, wrong containers won't be accepted by customs in destination harbor. There might be one difference though. Ships don't sail as fast as requests flies :)
Spread the word: