Since we will use node, we initiate node program manager, and put '-y' which means we will say 'yes' for all the questions.
And of course we need express!
To make our server reopen itself every time when we update our code!
It's much convenient with 'nodemon'!
And we can change the script for starting server in package.json file
Make app.js file
Keep in mind: "app.js" is our main-entry file that starts the Node / Express server, handles (and distributes) incoming requests etc.
Listening on port 3000 means that we'll be able to send Http requests to <domain>:3000.
On our local machine, that's "locahost:3000" (localhost is an alias for our local computer - it's only accessible from inside our own computer).
And we organize the structure a little bit!
Usually we use 'auth.js' file but since we might use this file in controllers folder, we make 'auth.routes.js' file in routes folder.
Check once again with MVC pattern
Our usual way has been like this.
Make the route and put the route there and use funtion also, so every route we needed to define the variable to use it for the function and the code seems quite messy.
Now we have controller! which connects our models with views and routes by containing the functions!
We will export the functions which will be in this file as an object which we can use to group multipe values or functions together and here we can also add a key for each exporting function!
It looks much simple!
And now we need to go to app.js file to make it aware of these auth routes
We use app.use which is a built-in method in the express app object that allows us to add a middleware that will be triggered for every incoming request before app starts listening because we do want to check for every incoming request if this request is for one of these two routes.
Therefore we want to use our middleware for every incoming request and we do it like this.
Our controller functions will then only be executed if the incoming request mathes the criteria laid out here, so if it's a get request for one of these two paths.
Fix views with EJS engine
After installing ejs, we should notify our code that we will use EJS so go to app.js file and set 'view engine' as 'ejs' and the next line of it, we say where they should view (read), and the path to get to there.
However, to write the path for it, we should use 'path'. It is recommended that we use the built-in path package becuase this allows us to create a path that will be recognized on all operating systems.
We want to start with a path to the overall project folder and nodejs has global variable for that!
It's __dirame variable
And as a second value of this path we write 'views' to construct an absolute path to this views folder in this project.
And we fix the file order a little bit, put 'auth', 'cart' and 'product' folders in customer folder which we newly made!
So we only have 'admin', 'customer' folders in views
In views, we have includes folder to put the files will be applied commonly for the each url and this is 'head.ejs'.
Here I closed </head> tag but we shouldn't do this if we wanna include some code inside of <head> tag!
header.ejs looking
And now we move to signup.ejs file and we will include 'head.ejs' and 'header.ejs' files.
We use <%- %> NOT <%= %> cause we don't want to escape raw data!
or we can separate again only for the footer and just use ejs engine and include it also!
To be able to extract the email from the incoming request on the server, we also have to give this input 'name' attribute which is another built in HTML attribute on input elements, because the name which we assign here will be the key which we can later use on the server side to extract the value entered by the user in that input field.
It is quite common to use a paragraph instead of forms to basically mark and group our different form inputs and labels that belong together!
Just fill it other information also!
And now connect it to the 'getSignup' function
Improve the looking of our webpage
Input the google font in our head.ejs file
And we made public folder and again made styles folder inside of it to put css files.
We don't have to set the href "../../../public/styles/base.css" cause we set it at app.js file so it will find this in public folder
So we should make an app.js file to know about the existence of public folder
Since we didn't close this <head> tag in head.ejs file we can import any link in each file.
When we import the style file, usually the order doesn't matter that much except the situation that if we use the same item in each file and try to overwrite it.
We set box-sizing to border-box this controls what the width of an element will be in the end, if the border and so on counts into the width or not. We got a behavior that makes working with widths a bit easier with border-box!
We can't use inheritance for setting the "box-sizing" property because that is a non-inheritable property! font-damily on the other hand IS inheritable!
Set CSS Variables for convenience!
It's much better using global CSS variable than using * (all selector) because if we use '*' it visits all the webpage to apply the styles but it we just use global CSS variable, it just applies the effect on webpage and this webpage will inherit the feature.
body {
background-color: var(--color-gray-500);
color: var(--color-gray-100);
margin: 0;
}
And we can use our variable like this
For width and height, "%" refers to the available width / height of the parent element - in this case the <body> element (which is the parent of <main>)
h1 {
text-align: center;
color: var(--color-gray-300);
}
form {
max-width: 25rem;
margin: var(--space-8) auto;
padding: var(--space-4);
background-color: var(--color-gray-600);
border-radius: var(--border-radius-medium);
text-align: center;
}
form a {
color: var(--color-primary-200);
}
form a:hover,
form a:active {
color: var(--color-primary-400);
}
If we will change the database of modify it, we should use 'post' method
const mongodb = require('mongodb');
const MongoClient = mongodb.MongoClient;
let database;
async function connectToDatabase() {
const client = await MongoClient.connect('mongodb://localhost:27017');
database = client.db('online-shop');
}
function getDb() {
if (!database) {
throw new Error('You must connect first!');
}
return database;
}
module.exports = {
connectToDatabase: connectToDatabase,
getDb: getDb
};
Now we will connect this to mongoDB We should install mongodb package to use it conveniently!!
With "connect(...)", we connect to a MongoDB server - NOT to a single database. That happens in a second step with help of the "db(...)" method - this establishes a "connection" to a specific database on the overall database server.
In class user construction, we define many variables there but only email and password would be mandatory, because if we just give only email and password to this class then other value will be automatically set as 'undefined' so it is optional technically!
Objects can be created with "object literals" (-> {}) or with help of classes. Both approaches work - with classes, you create objects based on a clearly defined "blueprint" (with clearly defined properties and maybe also methods), with object literals, you create objects "on the fly" without any pre-determined structure.
"Methods" (i.e. functions that are bound to an object) can be added to objects that were created without a class as a blueprint too. BUT: if you define a method on a class, EVERY objects that's based on that class will automatically have that method - a pretty powerful and useful feature!
"address" will be a nested object / document. This is absolutely fine and common when working with NoSQL / MongoDB databases. In a SQL database, you might instead work with a separate "addresses" table where you then connect users to addresses via "address_id" fields.
We can encrypt the password with hashing but after encrypting we can't take it back with decrypting!
We usually import third-party package first and then our own package!
Why we have two middlewares that deal with CSRF tokens: The third-party middleware ("csurf") helps us generate the token + checks incoming tokens for validity - our only middleware just distributes generated tokens to all our other middleware / route handler functions and views.
Since we will keep using this security tools, we just made a folder for middlewares and put csrf-token.js file!
And we can check in above code that we imported our own middleware!
Now we go to the signup.ejs to use csurf!
We used input type "hidden" which is one of the built-in types.
This is an input which is not visible to the user and which is not meant for the user to be populated with data, but which instead is already there and sent along with the request!
This has to have a special name for which the CSRF package will look and that's "_csrf"
And we will also put this for login.ejs
But still it doesn't work well cause we don't have any session management!
So now we will go to the app.js to fix error handling code!
First of all, we should write a code to generate our own middleware to handle errors and we can just separate it to organize
So we made error-handler code in middlewares
And make 500.ejs file to show when the error occurs and we put it in 'shared' folder and move 'includes' folder also inside of it.
And since we moved 'includes' folder, we should fix some routes we set for the includes!
And since 500.ejs is right next to includes folder since we moved it to be together in Shared folder our 500.ejs code will refer includes code directly, don't have to go inside the routes.
<%- include('includes/head', { pageTitle: 'An error occurred' }) %>
</head>
<body>
<%- include('includes/header') %>
<main>
<h1>Something went wrong!</h1>
<p>Unfortunately, something went wrong - please try again later.</p>
<p><a class="btn" href="/">Back to safety!</a></p>
</main>
<%- include('includes/footer') %>
Session Management
We need to install two packages to get help with session management, express-session and connect-mongodb-session
first thing is to manage session with express and second one is to save the session into the mongodb we are using it now
And to manage this, we make config folder and put session.js file inside.
Here we set the function for saving the session into our database and also the other function to set an configurate our session
We need to write an object here cause the express session package which we will use wants an object with all the configuration settings that we can set for creating such a session
The res.locals is an object that contains the local variables for the response which are scoped to the request only and therefore just available for the views rendered during that request or response cycle.
This property is useful while exposing the request-level information such as the request path name, user settings, authenticated user, etc.
Next vs Then in node.js
next() : It will run or execute the code after all the middleware function is finished.
return next() : By using return next it will jump out the callback immediately and the code below return next() will be unreachable.
In the function app.use((req, res, next), we have three callbacks i.e. request,response and next.
So, if you want to use next() then simply write next() and if you want to use return next then simply write return next().
Let’s understand these two by an example.
Using next(): If you have any middleware function and below the next() you have some lines or function that you want to execute, then by using next() you can actually execute the lines or function because it runs the code below next() after all middleware function finished.
Using return next(): If you have any middleware function and below the return next() you have some lines that you want to execute, then the lines which are below return next() won’t be executed because it will jump out the callback immediately and the code below return next() in the callback will be unreachable.
import express from "express"
const app = express()
// API for the testing of next()
app.get(
'/next', function (req,res,next) {
console.log('hi there ');
next();
console.log('you are still here');
}
)
// API for the testing of return next()
app.get(
'/return-next', function (req,res,next) {
console.log('hi there');
return next();
console.log('you are still here');
}
)
app.listen(5000,()=> {
console.log("App is running on port 5000")
})
Output :
next(): Hit ‘http://localhost:5000/next’ in your browser. Here the line which is below the next() is executed successfully and “you are still here” is shown in the output.
return next(): Hit ‘http://localhost:5000/return-next’ in your browser. Here the line which is below the return next() is not executed and “you are still here” is not shown in the output.
