
When we start bringing in routes to Express.JS, we want to separate routes into another folder.

This what our file structure should look like

    ___________________
    > Node_modules
    > Routes
    — — — home.js
    — — — users.js
    app.js
    package-lock.json
    package.json

    _____________________

In each route file, we will want to import express and Router()

```javascript
const express = require(‘express’);
//this is like creating a mini express app, or a plugin
const router = express.Router();//syntax include, remember that all of these are functions.
router.use; //important to keep in mind that this does not to an exact route match
//get, post, put, delete will all do and exact route match
router.get;
router.post;
router.put;
//not one hundred on this but I’m sure that destroy is something like this
router.delete;module.exports = router;
```

To use our new route files, we have to import them and call them with the use() express method.

```javascript
//IN app.js
const express = require('express');
const app = express();const myRoute = require('./routes/<file name>');
const anotherRoute = require('./routes/<another file name>')const bodyParser = require('body-parser')
app.use(bodyParser.urlencoded({extended: false}))app.use(myRoute)
app.use(anotherRoute)app.listen(3000)//easy peasy
```

## Let us make a 404 error.

```javascript
//js executes from top to bottom
...app.use((req, res, next)=>{
 res.status(404).send('<h1>Page not found</h1>');
 })
//we can always chain res whit .status(code number) or .setHeaders(header)app.listen(3000)
```

## Filtering Paths

Another cool feature of express.js is we can filter paths.

```javascript
//all we have to do is add and argument to app.use('/route', routeName)
...
app.use('/admin', adminRoutes)app.listen(3000)
// keep in mind this only works if your have to routes with the same path but not the same method like sorouter.get('/add-product', (req, res, next) => {
  res.send('<form action="/admin/add-product" method="POST"><input type="text" name="title"><button>Add Product</button></form>')
});
//notice that the acton still uses /admin that is becuse we will still be going to /admin/add-productrouter.post('/add-product', (req, res, next) => {
  console.log((req.body.title))
  res.redirect('/')
})
//again we redirect to /admin/add-product
```


Intro to using Express.js Router


Failure is foremost, and success is secondary. Web developers in any scope are failures, and proudly so. Development implies change, taking what is available and changing it into something new or different. Many times in history, we have had an unanticipated outcome that created something innovative. Failure is not an option to the skeptic, and a skeptic would say, “avoid failure at all cost.” Failure, however scary and trepidatious, is an option and a good one too.

One of the best examples of success from failures is “Percy Spencer,” a self-taught electrical engineer. While working on an active radar, Percy Spencer noticed that the microwaves had melted a chocolate bar in his coat pocket. Eighty years later, nearly everyone in America has that failure sitting on their kitchen counter. Percy was not trying to build the microwave But, look at the impact it has had on our society.

To indirectly address the skeptic, who believes that failure is not an option. It is easy to confuse failure with apathy because giving it “the old college try” does not cut it. Failing means putting in the time and effort to seek growth and innovation. To quote the great Lucile Ball — “ I would rather regret the things I have done than regret the things I have not done.” Failure is the pursuit of success, and what defines a person is not how they celebrate victory, no. What defines a person is their capacity to fail. I would Like to believe that I’m a failure through and through.

```js

```


Web Developers are Failures


However, especially in software development, optimization is important as it is better to learn at the speed of O(n) rather than O(n\*2). This blog is all about building your own philosophies. So without further ado, here are mine - Code is an art form, and as developers of art, we must perfect our craft. Take, For example, code challenges like on Leet Code or Hacker Rank. The user receives a problem like “Given Two Arrays checks if either array contains a common item returns a boolean.” We could write some very simple easy to read code like this.


How to be a Better Software Engineer


**Static Generate** means that we Pre-generate a page during build time. This way, all HTML data that make up the content is already loaded into the page during the build time. By build, I mean that the app is pre-rendered during the app’s deployment.

After your app has been deployed, pages are prepared ahead of time. Allowing them to be cached by the server/ **CDN**(content delivery network) serving the app. Now when a client requests the server, the pages can be severed to the client if any incoming requests are being resolved.

Only inside the pages folder, we can use :

> **Can be added to any page file under the pages directory**

```js
export async function getStaticProps(context){...0}
```

NextJS will automatically pre-generate. But we want to tell NextJS which files we wish to be pre-rendered; we can do that like so:

```js
const HomePage = (props) => {
	return (
    	<div>
        	<li></li>
            <li></li>
            <li></li>
        </div>
    )
}
// we always want to return an object with a key props
// The cool thing about this function is that instead of rendering the component function first we'll execute the getStaticProps function get our data and then render that data into the HomPage component.
export const getStaticProps = async() => {
    return {props: {
        products: [id: 'p1', title: 'Product 1']
    }}
}

export default HomePage
```

NextJS first executes the **getStaticProps** and then renders the **HomePage()** component.

**getStaticProps** not only allows us to write server-side code but also allows us to import node modules such as **fs** node files system.

```js
//as long as we don't attempt to use this in the client side code Next will split this away from the client side render. so the client wont see this import.
import fs from 'fs'
...
export const getStaticProps = async() => {
//normally we would not be able to run the fs.readFile() method but with Next we can actually import this in here and use the same way we would in a node application.
    fs.readFileSync()

    return {props: {
        products: [id: 'p1', title: 'Product 1']
    }}
}
```

Other cool things we can do with NextJS.

```js
//we can actually import what ever node modules we want as long as we only use them in the getStaticProps method
import path from 'path';
...
export const getStaticProps = async() => {
    //process is a global object that can be accessed anywhere with in a node application. Because nextJS doesn't read getStaticProps as a client file we can use the process object.

    //cwd = current working directory. and will actually view the current directory as the top level.
 const filePath = path.join(process.cwd())
    return {props: {
        products: [id: 'p1', title: 'Product 1']
    }}
}
```

> SIDE NOTE: keep in mind that **JSON**, is a global object just on both browser-side and with node.

We can test our build by running

```js
npm run build
npm start
```

This will allow us to see what is being built for our application…


Static Generation with getStaticProps


Before we begin, I need to add a bit of a back story for context. Don’t get me wrong I love computers, I built my own after all and, I have been known to go red-eyed trying to solve the simplest hardware issue with my computer but, I never thought of myself to be a tech person. I never thought I belonged to the community. Anyway, before I found “Flatiron” I was an English major and, not a very good one at that, something about the late-night workshops snobbishly tearing apart other people’s writing left me unmotivated. I did love writing I just always thought it lacked community and real collaboration. There was a common theme that always focused on the past and never what was happening now.

With all that being said and, going back to the “whole website changing the direction my life stuff”, my decision to be a software engineer was reflective of why I didn’t want to be an English Major. When I’m learning about programming, I feel like I’m moving forward focusing on the future, not the past it’s not as poetic as being a writer, but it feels relevant. I would like to take a sec and say I have nothing against writers, it’s just not my cup of tea. I decided to study software engineering, at least with Flat Iron, because it was tailored to everything I wanted, straight to the point, job readiness, and a community that I could relate to, let’s not forget that money-back guarantee. All of this won’t paint a sparkling image of why I made my decisions but why I will stick to it, I think what it


Why I choose Software Engineering


It is essential to keep in mind that Node.js only uses one JavaScript thread.

The question here is, how do we make multiple requests?

**Event Loop —** The event loop does not handle the incoming file but it does handle the callback so that when our code is sent to the worker pool, where the heavy lifting for our app takes place, it will then trigger the callback once the worker pool is done (like when we write a file), which is then handled by the event loop.

**Worker Pool:** The worker pool works independently of both the event **loop** and the **request**. This will run on a separate thread from the event loop.

![worker pool](how-multiple-requests-work-with-single-thread-event-loop-and-blocking-code2.png)

**More on The Event Loop**

The event loop is run by Node.js. It keeps Node.js running, and handles all the Worker Pool callbacks. It does this by lopping over Node.js code. Keep in mind that the event loop has an order in which it goes through the callbacks.

**Event Loop Order:**

At the beginning of each loop, the event loop:

- First checks to see if there are any Timers such as SetTimeout, setInterval these are all callbacks()
- Then, the event Loop will check to see if there are and Pending callbacks() that might have been deferred. If those callback() operations are finished, the event loop would then, in turn, execute said callback().
- Poll: After the above have been looped through, the poll phase will begin. This basically means that the event loop will retrieve any new I/O events and execute their callbacks. If the callbacks can not be completed, it will then defer that callback and come back on the next iteration and check back to see if it is ready to be executed. The poll phase will also check if there are any timer callbacks due to be executed and if so, will jump to timer execution.
- Check will execute immediate callbacks() and only execute after all other open callbacks have been either executed or deferred.
- Close: Now at the end of the event loop iterations, Node.js will execute any fast event callbacks().

* Finally we might exit the process, but only if there are any open event listeners.

- Poll Phase aesthetic example

![pool phase](how-multiple-requests-work-with-single-thread-event-loop-and-blocking-code3.png)

Poll phase aesthetic example (when checking timer callbacks)

Event listeners on the Node.js server

When we open an event listener with Node.js createServer(), this is an infinite reference that will never close, so our event loop will never exit.

In other words, the createServer() method by default never exits.

That’s it. Hope you found this article helpful. Thank you.


How Multiple Requests Work with Single Thread, Event Loop & Blocking Code


No just kidding the purpose of this file is to have more than one story. Unfortunately, I'm only writing this out because I'm some how so lazy I'm doing extra as to actually write this entire blog. Anyway I really hope that you enjoyed my rant about my own laziness. Goodbye and so long se la vi I do.
