A new JavaScript project: NestJS and NextJS
Hi! and welcome back to another blog post. Today I will talk about 2 important technologies for JavaScript, NestJS, and NextJS. I’m going to talk about what they are, why we use them, and their main components.
NestJS
A Node.js framework for scalable serverside applications with Typescript.
- NestJS provides a suite of tools that take advantage of either fastify or express, to facilitate rapid development and readable code.
- Supports REST and Graphql for your APIS.
- Offers the opportunity to build a full-stack application using the model view controller pattern.
NestJS has a ton of built-in modules to work with: Databases, handle security, implement streaming, and much more.
This technology has its own command-line tool: we can create a new project by doing >> nest new my-api . When we create a project this way, we will be provided with a codebase pre-configured with Jest for testing and setup with Typescript.
A controller is the fundamental building block of the framework. It is responsible for handling incoming HTTP requests and returning responses back to the client.
To implement a controller we simply do:
- Add the controller decorator to a class, then inside the class, we can implement methods and decorate them with HTTP verbs.
- By default, that will create an HTTP endpoint on the root URL.
- You can pass a string to the decorator to change the route, or implement dynamic route parameters.
Nest also provides other decorators to control status conde and headers inside the class decorated with @controller().
Moreover, parameter decorators can be used to access the request parameters or body. Lastly, the return value from the method is the response body that gets sent back to the client.
We can use the CLI to automatically generate more controllers to keep your code organized as it grows in complexity. In addition to controllers, there are also providers.
Providers are a class that contains shared logic throughout the whole application and then, they can be injected as a dependency where needed. Any class with the @Injectable() decorator can be injected into the constructor of another class.
A provider can be implemented as:
- A guard to handle role-based user authentication.
- As a pipe to efficiently validate and transform values in a controller.
Finally, the module decorator @Module(), allows code to be organized into smaller chunks where it can be lazy-loaded to run faster and in serverless environments.
NextJS
Allows us to create fast search engine optimize react apps, with zero configuration.
A traditional react app is rendered client-side:
- Where the browser starts with a shell of an HTML page, without any rendered content, from there, the browser fetches the JS file containing the react code to render content to the page and make it interactive.
There are 2 big drawbacks with client-side rendering:
- The content is not reliably indexed by all search engines or read by social media link bots.
- It can take longer to reach the first contentful screen when a user first lands on the web page.
Next is a framework that allows you to build a react app but render the content in advance on the server, this way, the user or search bot will see the full rendered HTML as the first thing.
- After that initial page is received, client-side rendering takes over and it works just like a traditional react app.
- The best of 2 worlds, fully rendered content for search, and highly interactive content for users.
Inside a Next project we have a pages directory where:
- Each JS file defined here exports a React component that represents a route in the application.
- The file structure mirrors the actual URLs that the user will navigate to.
In addition, Next provides its own router to make navigation seamless.
Data fetching
Next can perform multiple server rendering strategies from a single project.
Static generation: render all pages at build time.
- Also called pre-rendering, allows you to render your pages at build time.
- Each page or component can implement a function called
getStaticProps(). - This way it can fetch data from a cloud database, and then pass the data as props to the component.
- Then, you can build your app to render all the HTML locally and upload it to a storage bucket where it can be cached by a CDN.
- This strategy is great for a blog or any app where data doesn’t change often.
Server-side rendering: Generate each page at request time.
- If data in your app changes often use server-side rendering.
- Builds the HTML page each time it is requested by the user.
- In the component, we do data fetching with the
getServerSideProps()function. - Instead of running during build time, this function runs at request time, which means that the page will fetch the latest data on the server each time a new request is made.
- This strategy is great for pages with rapidly changing data.
Incremental static regeneration: Regenerate single pages in the background.
- This strategy is something in between the last 2.
- It is implemented by simply adding a revalidate option to get the static props.
- Next can regenerate whenever a new request comes within a certain time interval.
Resources and more info
That would be everything for this week. Have a great day and see you in the next post!
