So, first of All, What is ExpressJS ?

ExpressJS is a minimal and flexible NodeJS web app framework designed to make developing web apps and APIs much faster and easier. it's almost unfair how easy it is to spin up a server with the help of ExpressJS. while ExpressJS is not a part of NodeJS, it is not a built-in module or anything like an HTTP module, it is a standard when creating web applications with NodeJS.

To get started with ExpressJS, we need to install the package (I'm assuming you are familiar with NPM) open the integrated terminal in your visual studio code, navigate to your root path, write "npm install express --save" to have the package added to your NodeJS project. After installation, we get access to the ExpressJS object. We create an instance of the express object by importing it into our file and instantiating it. And after instantiation, we have our server instance with a bunch of cool methods from the express library that makes our development experience smoother as opposed to doing everything from scratch with vanilla NodeJS. e.g creating the HTTP module from scratch, calling the createserver method and a lot of that configuration stuff, setting default headers, express handles most of that for us....( cool, right? )

some of the methods we'll get straight out of the bag from ExpressJS library are;

1. The "GET" method

2. The "POST" method

3. The "PUT" method

4. The "DELETE" method

5. The "LISTEN" method

6. The "USE" method

7. The "ALL" method

We have a couple more methods available to us but as a backend engineer whose primary job is to create APIs, Handle requests from the browser, and send back responses, these are mostly the methods we'll be using.

Just by looking at the method names, we can get an interesting idea of what they do. they are mostly self-explanatory. but I want to briefly talk about each one anyway.

The first 4 methods represent HTTP verbs. when we talk about the HTTP request and response messages, one of the things we'll be looking at in the HTTP request message is the HTTP verb and which represents what a user is trying to do, whether read a data, insert data, update data or delete data.

1. GET method: All browsers perform a get request by default. when you open your favorite browser and try to go to a website the browser is performing a get request. sending a get request to the server to get some resources hosted on that server. and the GET method from ExpressJS makes handling the request and sending back responses easy.

   This method takes 2 arguments, the path(that holds the resource user is trying to get) and a callback function that executes to handle that get request. The callback function also takes 2 arguments( req and res), they represent the request and the response objects from the browser and the server respectively. the request object holds information about the request from the browser(URL the request is coming from, message, header) and the response object, as you might have guessed, we get access to that in ExpressJS to send a response back to the browser. we can have as many get requests as possible handling different paths (routes) to get different resources on our server.

2. POST method: This handles requests from the browser to send data/resources to our server. say we have a registration form where a user inputs their name and email, and the information is sent back to the backend using a POST method. we handle and get access to data being sent to our server with the post method.

3. PUT method: This is just a method to update some resources that the user might have sent to the server. where we not only get some information on the request body to update resources, we also send back responses about the updated resources

4. DELETE method: as simple as it sounds, this is used to send a delete request from the browser to the server, to delete some resources on the server

5. LISTEN method: This is a method we use to listen to requests from the browser. we pass in the port we want our server to be listening on as an argument to the method e.g 5000. and a port is just a communication endpoint for our HTTP server. an endpoint where our frontend and backend communicate. I believe port 0-1024 has been taken by other programs so we can't use them but in local production, the port is usually an arbitrary number and you can use basically whatever you want.

6. USE method: this is responsible for middleware, a very crucial part of ExpressJS. we use this method to pass in middleware to all or specific routes. as opposed to manually adding middleware to each route which is tedious and could be time-consuming depending on the number of routes we have. we can call the USE method and pass in a route(optional) followed by the middleware function as arguments and it applies the middleware function to the routes we specify. Another important thing to understand about using the use method is that the order matters, if we place our USE method that's holding a middleware, below a route, that route automatically get omitted and the middleware won't get applied to that route. so it's recommended to always place all of our USE functions at the top of our page, specifically, above all the routes. We can also execute multiple middlewares in the use method, we place the middlewares we want to execute in an array and pass it into the use method as an argument. e.g app.use([authorize, logger])

7. ALL method: Let me paint a scenario, if the user(browser) tries to access a route/resources that do not exist on our server, the default response that ExpressJS sends back is simple (cannot get /path) text, which is a 404 status code, a bad request, to send a better error or a customized error message because they are obviously trying to access a resource that does not exist. The All method handles all HTTP routes on our server, and that makes it perfect to set up an error message response that we send back to the browser. it takes 2 arguments, a route and a callback function. We can pass in * to represent all routes in our app and the callback function takes res and req objects(of course) using the response object(res), we can send back a "resource not found" message and if a user tries to access a resource that's not available on our server, they get that instead error response of the default express error.

In most cases, we typically use ExpressJS to either set up an API(application programming interface) or set up templates with server-side rendering.

Depending on what we are trying to do, we need to know how to configure our app to send and receive data.

To use ExpressJS to set up an HTTP interface(API) to interact with our data, we have to configure data to be sent back with our response using JSON, we have a res.json() method from ExpressJS that does all the heavy lifting for us e.g setting content-type, stringify our data. and we have a middleware that parses incoming requests from the frontend and allows us to get access to the JSON data. (express.JSON). so we can get and send data in JSON format.

NOTE: the main function of an API is that our server provides data and any frontend app that wants to access and use our data, can simply perform HTTP requests to our API and use our data. (that's why our data has to be sent back and forth with JSON)

To use ExpressJS to set up server-side rendering where we will set up templates and send back the entire HTML, CSS and javascript ourselves, we have a RENDER method to do that.

Middlewares In ExpressJS

Middlewares are functions that execute during the requests to the server. each middleware function has access to the request and response object. middlewares are a very important part of ExpressJS because of the flexibility they give us. middlewares are everywhere in ExpressJS, you can even make an argument that express applications are nothing but a bunch of middleware mashed together to make one big application. so, middlewares are not one of those topics you can just skip or avoid, it's absolutely important to grasp the idea behind it and know how to use it. Another reason why the middleware is so powerful is that we can set up a property in the middleware and attach it to the request object and so, any routes that are using the middleware also get access to whatever properties we might have set up in the middleware (how cool is that?). Middleware truly allows us to structure our applications like lego blocks where we get pieces of functionalities and combine them to get a fully functioning express server. we also have a couple of built-in middlewares from ExpressJS to make our development experience smoother. e.g express.static (makes our files static so that they are publicly available), express.json (to parse our JSON files at the frontend and make them available)

Another important thing to always remember about middleware, to prevent our app from being stuck in limbo, we need to always call the next() function to pass current middleware to the next middleware, unless you're terminating the entire cycle with a response in the middleware function. . . we also have third party middleware functions we get from npm. the bigger our ExpressJS application, the more middleware functions we'll most likely use.

Route Parameters in ExpressJS

Say we have a situation where we have a list of products we are returning as a response to a get request coming from a route, and we want to be able to return a particular item with a specific ID as opposed to all the products, this is actually a common scenario in web development as a whole, where we want to get a specific user data or products. Problem is, we need a way to get the ID of the resources that's been requested on the request body to the backend so that it can be used to write the logic to return the single product. Route parameters are the perfect solution for this. on the request object, we have access to the route parameters. whatever comes right after our path is what we are setting as parameters, it comes along with the request object as a string and we can access it on the request. params object. once we get the id back from the params, we can then use it to write the logic to find a specific product and because of that solution the route params from ExpressJS gives us, we don't have to hardcode values and set routes for each single products which is a very ineffective way of setting that up anyway. I like to think of route parameters as placeholders where the user passes data and using request params, we can access that data and use it to effectively solve that common problem of sending back a product/item based on the data(usually ID).

Query String Parameters In ExpressJS

Query string parameters(URL parameters) are a way for us to send a small amount of information to the server using the URL. we usually use them as parameters to maybe query databases, filter results etc and it's really up to us to decide what parameters are accepted. we set it up by passing a property name e.g "search" after the API route, then a question mark, and then, a query parameter and a value. so we get to return data based on the property name and value we set up in our URL as a query string(cool). another interesting use for query strings is to set up paginations. we set up a property name, question mark and then key-value pairs that are supported by the setup. and of course, we can get access to the query strings in ExpressJS setup on the request query object(req.query)

Routers in ExpressJs

This is an important middleware that allows us to group multiple routes. the express.Router() function is used to create a new instance of the router object for handling requests. also makes it easy to differentiate requests. In summary, setting up our projects with routers keep our file clean, and much easier to read.

Controllers In ExpressJS

Controllers are functions that execute when a request to a certain route is made. they are the code that processes and outrightly handles requests. controller functions help keep our files lean, organized and easy to read.

As an ExpressJS newbie, Having a solid understanding of some of the methods and concepts I have written here, makes using ExpressJS much more enjoyable and helps improve your backend development skills in general.

Hope you learned one or two things.

So, First of all, what is NodeJS?

NodeJS is an environment to run javascript outside of the browser. created in 2009 and was created on top of chrome's v8 javascript engine. In layman's terms, the creator of nodeJs, Ryan dahl basically ripped out the v8 engine and build node on top of it (cool, right?). I particularly love the large community around NodeJS, I think it's the perfect backend language for a newbie to learn and to really understand backend development. It's never been easier to build full-stack applications since both the frontend and the backend of your app are essentially built in the same language (our beloved javascript). As a person that started his/her coding journey with javascript, I get the advantage of avoiding the steep learning curve of learning a new programming language altogether just to learn backend development. (all thanks to nodeJs!)

First of all, to really understand NodeJS and really grasp most of its core concepts and what's going on behind the scene, one needs a very solid understanding of some of JavaScript fundamentals. callbacks, promises, async-await...

I'd also love to clarify some of the differences between browser Javascript and NodeJS. first of all, we do not have access to the dom in NodeJS unlike in browser javascript, which means, no fetch APIs, no geolocation, and those cool browser APIs. we do not have interactivity, our node apps are purely server-side apps, and they consist of only logic. I know that may sound like a disadvantage but there are some cool features that nodeJs provides, that, in my opinion, makes up for it. eg filesystems. in browser javascript, we don't have access to any form of filesystem whatsoever. but in node, we do(cool, right?) we can access info about our operating system, and respond to a network request, amongst other things. Another interesting thing about NodeJS is that it's based on versions, unlike browser js where our app performance is based on the browser of the user where some of our features may not work. our nodeJs app will not break just because there was some upgrade in the browser or anything like that. it makes maintaining a NodeJS application much easier. Also, in node apps, we have access to modules by default(it's hard to imagine a nodeJs app without modules honestly), whereas, in browser javascript, modules are optional.

Installing NodeJS is fairly straightforward. All you have to do is navigate to nodeJs.org, pick a version, and install it. Unless you get a weird or unusual bug, NodeJS should be available on your local machine. To confirm if you have nodeJS installed correctly, go to your terminal, type "node --version" and you should see the version of node installed on your machine. Great.

After installation, the next question I'm sure you'd have is "what next? how do we get node to evaluate and run our code", well, unlike in browser javascript, where we just add our javascript file to our index.html and let the browser do the rest. In nodeJS, we have 2 options. REPL(read, eval, print, loop) and CLI executable which essentially means running our application code in node. and honestly, REPL is for playing around, CLI is effectively for every other serious business.

I'm not going to talk about the REPL, as I previously said, it's just a playground, we are mostly going to be executing our NodeJS programs with CLI executable. so, create a new folder, open it with Visual Studio Code, and create an app.js file in the folder with a basic, simple javascript program that logs something to the console. now, in order to run the cool program you've just written in NodeJS, you simply open the integrated terminal in Virtual Studio Code, navigate to the directory of the folder that's holding the file(app.js) and type in the keyword "node" and then the file name of the code you want to be evaluated and executed and hit enter. (eg node app.js). unless something goes wrong, your app.js file should be evaluated and executed. Congrats, you've just written your first nodeJS program.

once we have executed our first NodeJS application, we are set for a deeper understanding of the backend Language. the next important thing I'd like to introduce to us, Is global variables. Remember, since we don't have a browser on the backend, we don't have access to the window object, so, again, no access to cool APIs, that's where the global variables come in, and what we mean by global variables are essentially variables can be accessed from anywhere in our application. no matter how complex or nested our NodeJS application gets, we'll always have access to the global variables. we have a lot of global variables and honestly, I could spend this entire article writing about them but I only want to introduce us to a couple.

1. dirname: to give us the path to whatever directory we currently are on

2. filename: to give us the current file name

3. require: which is basically a function that allows us to use modules

4. modules: which gives us information about our current module(file)

5. process: which gives us information about the environment where the program is being executed

I believe these 5 are some of the essentials to really understand the concept of global variables, as a newbie. again, there are more and with time as we get to use and work with NodeJS, we're going to get introduced to them. but for now, understanding the ones I listed up there is a great starting point. and that's why I want to talk about modules next...

Modules in NodeJS give us the flexibility of splitting our code into multiple files, where we can just import different parts of our application in a central file, thereby, keeping our main file leaner and more organized. its syntax is similar to that of es6 modules, so, if you're familiar with es6 modules, you're already a step ahead. another thing about modules is that it is encapsulated code, which means we only share/export what we want. we decide what functions or variables we want to export or share with another file. Also, every file we create in nodeJs is a module by default. a module created by us, the developer.

We also have a couple of built-in modules created by some very smart people, available to us to use. OS modules, path modules, Filesystem modules, HTTP modules to name a few(we have a couple more...) and if you're interested in learning about more modules, I'm sure the NodeJS docs would be of great help. I'd like to talk briefly about some of the built-in modules I cited up there.

1. The OS module is a built-in module that provides many useful properties and methods for interacting with the operating system, as well as the server. all we have to do is create an instance of the os object and we out-of-the-box get a couple of in-built methods and properties on that instance that we can use to get information or communicate with our operating system. e.g info about the current user, info about the system's uptime, type of OS, storage memory of the OS etc.

2. The path module is another built-in module that provides many useful methods for interacting with our current path. create an instance and you get a bunch of methods to get some information about the current path. eg path.join which joins a sequence of path sequence, path.basename to get the base of our path, path.resolve returns an absolute path etc...

3. The fileSystem module is another interesting built-in module that helps us to, you guessed it, interact with our file system. and the name of the module is FS. create an instance of the fs object and we get a couple of cool methods to do some cool stuff with our filesystem. one important note about fs is that we essentially have two flavors to choose from, either asynchronous (non-blocking) or synchronously(blocking). and depending on our setup/what we are trying to achieve, we get to decide if we want to read/write to filesystems asynchronously (non-blocking) or synchronously (blocking), isn't that cool? synchronously, line by line, while asynchronously, a way that we can delegate blocking codes to the kernel of the system and then invoke a callback function when the blocking code resolves.

4. The HTTP module is also very important in nodeJs. also in-built, it essentially allows us to set up a web server. where we can listen to incoming requests from the browser and respond to that request with our response. so we get some methods when we create an instance of the HTTP object. eg HTTP.createServer, to whip up our server to listen to requests, we also get the request and response object to listen to requests on the server and a response respectively.

I'll stop here about built-in modules. next, I'd like to talk about some core concepts in NodeJS.

Some Core Concepts To Have A Deeper Understanding Of NodeJS ;

1. A very important concept in NodeJS I'd like to write about is Event Loops. I could dedicate this entire write-up talking about it and it still would not be enough. but I obviously want to paint an idea of the general concept behind it. the event loop is basically what allows NodeJS to perform non-blocking input and output operations, even though javascript is single-threaded by offloading operations to the system kernel whenever possible. PS Don't stress if that definition sounds like gibberish to you, the most important thing to remember is "offloading". we are essentially telling Node "hey, run immediate tasks first and after you're done with those, then check if we have any callback functions, then execute". let me paint a better scenario; say we have multiple users using our app (because it's so popular lol), and one annoying user decides to make a request to our API to get some information from the database that might take a while, instead of making all the other users that might need something not as serious/time-consuming from our API, wait, we essentially skip the database call from the annoying user and hand that off to the kernel of the system and go on executing other task and only when we are done with the other "straightforward tasks", do we then check back with the kernel and basically say "hey are you done with that task I handed to you?" if yes, we execute. and so on and so on. Event loops are literally our best friend because, without it, it'd be impossible to keep all our users happy.

2. The next concept I'd like to talk about is an asynchronous pattern of writing code in nodeJS. I briefly wrote about filesystems and how we can synchronously or asynchronously write files to the system. In, NodeJS, we will mostly use the asynchronous pattern of reading and writing files to the system, because that means we are not blocking the event loop which is great, it's also easy to see how we could get lost in callback hell. say we want to read a file(that might take a while) and write a file which is probably going to take some time too and another read file, since we'll be nesting callback inside the callback, inside callback, you could easily get trapped in a call-back hell. it is important to understand alternatives and neat workarounds. to understand how to asynchronously write clean code. how to set up our asynchronous code on top of each other and a common way to achieve that is by promisifying our code.

3. For a deeper understanding of nodeJS, we also need to understand what event-driven programming is. in browser-side javascript, the browser provides a bunch of APIs of some events that we can use to trigger functions, think about the way event listeners work in javascript. onclick of a button, a function runs, onhover of a button, do this. Basically, it's the same idea in NodeJS, we have something similar. Technically, as our program executes even in nodeJS, it is in part being fired by an event. (when I get to this route, fire up this function. we are listening to an event that a route is being triggered, and then firing a function).

   event-driven programming is a style of programming that is in part determined by the events that occur as the program executes. we use event-emitters to listen to events and to fire programs in our NodeJS application. Again, think of it as the way event-listener works in browser-side javascript. NodeJs depends heavily on event-driven programming under the hoods.

4. Another important concept to understand to get started with NodeJS, is the way browser/frontend interacts with the server. Basically, the way HTTP messages are exchanged and structured.

   A browser sends a request(usually a get request by default) to get resources that are hosted on the server, the server analyzes the request and sends a response back to the browser. on the request message, we set a method(get by default), and we have a header and a body, the header and the body are mainly additional information from the browser to the server. The response message carries the status code, headers and also body to send additional data back to the browser. that's just a brief overview of how the HTTP messages are being exchanged back and forth between the server and the browser

   A server makes resources available to the frontend/browser. servers don't have interfaces, their work is mostly repetitive, and all they handle are a bunch of requests and send back responses conditionally, and that's why it must always be available, the faster it sends resources to the browser, the better the user experience, obviously. note: the request message is what the browser/frontend is sending, and the response message is what the server is sending back. NodeJS is basically a programming language we are using to send that response back to the browser/frontend/user. once we have a decent understanding of how HTTP works and how HTTP messages are structured, you are ready to create your server and work with NodeJS

There are some concepts or topics that I might not have covered that still needs to be learned to be a World class NodeJS developer, but knowing and understanding some of the concepts and information I have put on here sets you on that journey. I hope you learned one or two things reading the write Up as I put a lot of effort into writing it.