Frontend vs. Backend - General Web Dev Introduction

In computer science, we describe "backend" and "frontend", and these explicitly mean:

Frontend: This is the app that you see, in your browser, specifically. Frontend can also generally mean any client that you interact with, think "Front-facing for the public, so it could mean a desktop app as well, or a phone app. A client is any consuming piece of code (ie. A a part of your backend code, for example, could be considered a "client" that is using another library... it's a client from the libraries perspective... just trying to show the vagueness of the term client).

Backend: The server environment (whatever the front-end talks to at a remote location). The server receives requests from the clients (can be any frontend, web, mobile, desktop, etc), and the backend server fulfills those requests, which means talking to a database, making other remote requests to APIs, gathering the data and returning it in the response, usually in the form of JSON (javascript data notation), if it's a REST API, which most backends are. Typically in programming we want to make all classes and structures as discrete as possible... following the SOLID principles (see link in post)... this means that all classes/functionality should basically only have one purpose. If something needs to be broken out to a new class, then do so, if you care for maintaining the code, but it's not necessary. I've definitely written giant one-file classes before... whatever gets the job done. Most backends are "REST API's", because they only need to expose an API to the clients (endpoints to hit for data), and then REST implies it's just objects/classes being manipulated in a CRUD (create, read, update, delete), which you'll see most backend API libraries referencing.. and some that can automate all this (ie. ORM - object relational managers... do the job of managing your object classes, their relationships, and querying the database to get all those objects into your code to respond to the requests).


To maybe make that all easier to understand, I'll run through a typical frontend/backend example.

On the frontend these days, people mostly use React or Angular, if using any framework (of course there's plenty of others with their benefits/different approaches)... I like to recommend Angular only because it's much better engineered, which you'll hopefully come to respect some day. React is kind of a hack, but it gets the job done, and is thought to be easier, but that's kind of a lie. It got a huge following just because it's kind of dumbed down, and supported by Facebook, and gives the impression that it's easier and simpler for newbies, which might be true from that perspective... Angular looks daunting cause Google always has impressive documentation, and the Angular project comes with a lot of tools and features (very helpful, mind you), but to make a basic app, React and Angular are almost exactly as easy, and I can help answer more of that if you like. See my link in the thread on React vs. Angular comparison (WIP):
https://docs.google.com/spreadsheets/d/e/2PACX-1vS4WUCt9iCrcTLNj5Z4CQ1KBLeiP45RgESflmMIwmrTM5eT7zz7DvL1hEJ_WvgINH1kvBhtsEGOr8by/pubhtml

So we pick a frontend framework, let's say ANGULAR. Now the point of this framework is just to give you a means to paint pixels in the browser more easily, and manage components, then do a bit more complicated stuff like managing Service classes or whatever you need ... both libraries (React and Angular) are "component-based", which means you just write little (or big) modular components, that interact and use each other in a composable fashion. So you could have a component that is, for example, a list of Users. This component could use child components, such as a ListItem or UserListItem component, which is the actual User button, or something representing the user in the list. The UserList component would use the UserListItem as a child component inside of itself. This is how we compose components, which a lot of framework approaches use these days. Making something into a component follows the SOLID principle to try and keep functionally discretely contained in one class/object (a component in this case), so try to design your app components to only have one purpose, each, and compose them together as such. You generally have a main App component which will pull in other page/view components depending on the current route, then those page components themselves will pull in other components for what they need to do...

Now for your questions (I think I answered #2 above):


1. Database creation seems easy, but I can't understand how to connect it to my code?
Is this what node.js do? Does it crud the inputs and communicate with database? If not, what should I use for this procedure?

  
2. I built a form which you put inputs and it displays it using js HTML DOM, is this the client-side backend in general manner?
If not can you give me example for it

Yeah, node is a backend javascript framework (ie. Lives on the server), er, it's actually not a framework, it's just the technology/server that runs there, but node exposes its own very low level classes and functions to build a web server application, so you don't actually *need* a framework to build a web server, on node... but it's definitely easier. The simplest and most widely used node framework is Express. Most other frameworks are based on Express itself, just extending it with more features/helpful tools. The framework I've been using lately on the backend is NestJS, a very nice enterprise level node framework, and am really enjoying it. This backend framework is like Angular on the frontend, where it will give you advanced help, such as automatic Dependency Injection (you can say "This component or class needs this service", and you just put a reference to the service in your class's constructor, and Angular or NestJS will automatically pull in the classes that it needs... DI is a widely used and useful feature of software. Without DI, you have to manually instantiate a class reference inside your constructors, and then set that as a property on the class, to be used later... DI's benefit is that larger application can *declaratively* describe which classes or services to use, at run time... so you could have a config file that says "Use ServiceX class for now..." And the DI system would pull that class in, without having to change code, for example... so could have classes that work different on local/dev vs. production server, but don't worry about DI so much now.

So we have a framework, Express or Nest, etc... now how does it talk to the database? With a simple framework like express, you have to pull in your database classes to talk to it. For node projects, we use the npm registry, has all the packages you need: npmjs.org. Read up on 'npm' project manager if interested in node. So Express would pull in a class such as 'mysql' or 'pg' (Postgres), and those libraries have some functions to connect to a database (local or not). Then you generally write your own "data layer" (can just be a single class), that uses these objects to talk to the DB, doing queries, and then responding with the data, to whatever client/calling code is requesting the data from the data layer... 

With more advanced frameworks like NestJS, they give you what's called an ORM (Object relational manager), where you can basically talk to the DB, manage relationships (very common), and do CRUD operations on literal JS objects, and the ORM will do all the SQL and querying/serializing to the DB for you. With something simpler like Express, you have to write all the SQL yourself(!), which can get messy, but it will also be a bit faster regarding performance than an ORM, so we always consider the tradeoffs... larger applications definitely benefit from an ORM, but if you *really* care about speed and know how to write optimal queries, can do manual SQL queries with the native mysql/pq/etc libraries. However, note that many times we'll consider caching the data, so we don't have to hit the DB or ORM so much, to speed things up in a larger application. There's many different caching approaches (from storing the data directly in server memory, or having an entirely separately intermediate caching server setup before the main backend server is hit, something like Varnish)... don't worry about caching so much right now though.

So to run through an example:

-on the frontend, user updates their profile information
-frontend has some service class, let's say UserService, and then the UserProfile component imports this class (through DI or manually), and then on submit of the form, first validate it on client, then put the data in a JSON object, and ask the UserService to update, ie. UserService.updateProfile(userId, profileJson). However, in a CRUD situations, where you kind of want to keep all service and object manager classes very discrete, can make it more generic: UserService.save(user), and that UserService::save method will just pass the entire User object to the backend /users/<userId> URL as a POST or PUT (POST is generally used for Create, PUT for Updates, but this varies depending on preference). Typically you would POST directly to /users (n user ID) if creating a new user, and then call also POST to /users/<userId> just the same, a different url, for updating... to give you an idea, and can also add more custom endpoints to do more fancy/piecemail/domain-oriented logic.
-So to fulfill this request, UserService makes an AJAX request to the backend (typically every WhateverService class would extend from a base Service class, and then call something like 'this.request(url, options, data)' kind of... then that base request() method does the actual constructing of the arbitrary AJAX requests to the remote server. React doesn't come with a request library, so have to import your own (ie. Axios, nanoajax, etc), but Angular comes with its own Http library to do this automatically, and their library ALSO works using RxJS observable objects, which is really nice... and can let you subscribe to the responses and do a lot more complicated things with them later (ie. Getting automatic object updates).
-Once the AJAX requests sends its JSON to the backend/server API endpoint, the backend server sees this, routes to the corresponding controller or whatever handler to fulfill the request. This controller will generally import (through DI or however) any classes it needs, ie. Service, Repository, etc, to fulfill the request. Typically that works like this:


(pseudo-ish code):

 
UserController {
    constructor(userService: UserService) {}
    
    handleCreate(request, response) {
       // get current user from Authorization header, or cookie, etc...
       // ensure current user exists (is logged in), or has appropriate access for this action...
       
       // get data from request body and validate it, return error if invalid.
       let data = request.getBody();
       
       Validator.validate(data, rules);
       let r = this.userService.create(data);
       response.success(r);
    }
}

UserService {

    constructor(userRepo: UserRepository) {
    
    }

    create(data) {
       
      return this.userRepo.insert(data);
    }
}


Obviously there's a lot to fill in there... how does the UserRepository talk to the DB? Well, typically I extend from a base NestJS Repository, and nest is already configured to talk to the DB on its own in this fashion, and then it's just a simple matter of calling some CRUD operations on the repository. With something like Express, you'd have to write all the repository methods (create, update, delete, get) yourself with manual SQL queries using the native libraries... obviously can become a bit messy.

Hopefully that's something... I know there's a lot to learn and some holes here, so if you want to know more specifically about any areas of frontend/backend, or a particular framework, feel free to ask.