say we made a web app the basic structure of the web app would be: Note: for clarity we assume we are using React, express and Mongodb;
- Front-end
- Back-end
- APIs
- Databases
Front-end
The front-end is a graphical user interface of the application this is the part of the application a user sees and interacts with it is from this section that the user
- inputs data
- reads information Since the front end is what the user sees (WYSIATI) this part of the application has to be top notch it has to
- capture the users attention and hold it
- accessible to all users (screen readers and what not)
- interactive
- intuitive i believe that this section should also have some very essential features like
- secure
- optimized
Back end
The back end is the logic of the site this is the stuff that the user cannot see but is essential for the site to work , consider this analogy; say our app was a restaurant , the Front end would be the diner where individuals get to sit down and eat, this is where the individuals are allowed to see the back end is the kitchen where the chefs make the users meal based on the users requests and the API would be the waiters who communicate the users requests to the kitchen so that the chefs can satisfy their appetite i believe that all good apps should have
- well defined functions(menus if you where to use our analogy)
- secure
- Should not be viewable by the regular people
- should be efficient and well able to meet the need of all its users at a given time
API
The API is what connects the front end(GUI) part of the application to the Back end(logic) part of the application in our restaurant analogy the API would be the waiters ... waiting for users input and relaying it to the chefs and then when the chefs are done the waiters carry the dish(result of the carried computation/ operation) and return it to the user like any good waiter , a well designed API has well a given set of protocols there are various designs for APIs one of the most common and the one we will be talking about today is REST(REpresentational State Transfer) which should;
- have reasonable route paths
- have a document that explains what each route does
- return the right status codes
Database
One of the reasons why i decided to use the restaurant analogy is because of how well it explains how databases say we worked in the above mentioned establishment that served the very best dishes we would need a secure place to keep our fine ingredients and save them from rats, cockroaches and other places and that's where the storeroom(database) comes in .It is a place we can securely store data provided by users or any form of computation but unlike the storeroom it has to be able to store data for very long periods of time and perhaps store it more secure as very sensitive information can be used for malicious events if said sensitive data was to be left exposed to everyone i believe that a database should be
- fast
- easy to retrieve data from
- secure
- efficient
- not accessible to the public