Getting Started

Frontend

Introduction

The entry point of every NextJS app is the _app.js file located in the pages directory. In this file, we have provided several key customizations to serve the needs of almost every full stack application. That is, most apps need certain public pages, such as a landing page, sign in page, and sign up page; other than these, most other pages are going to be protected. In our template, we have wrapped all of our protected pages in a 'Wrapper' component that wraps all protected pages with a navigation bar, optional sidebar, and other bits that only authenticated users will be able to utilize. Public pages do not have these by default, and so they must explicitly include components like a Navigation bar.

In addition to the Wrapper Component that will wrap all protected pages with certain elements (see components/Layout/Wrapper to customize), we also have another higher order component called ProtectRoute that will handle session logic. That is, we only want users to see our protected pages if they are logged in, and otherwise be redirected to a sign in page. We also want users that are logged in to automatically go to the Dashboard (authenticated user entrypoint)if they attempt to go our homepage by typing in the website URL in their address bar.

Making pages accessible by public

To add pages that are accessible by public only (e.g signed in users will be redirected), add the route as a string to the ROUTES_ACCESSIBLE_BY_PUBLIC_ONLY constant.

Backend

Introduction

Unlike most Javascript frameworks, NextJS includes a powerful feature called server less functions. Think of it as the backend for your application that, when put on a server less framework such as the one provided by Vercel, will listen to API requests, do the necessary logic to process those requests, and provide a response. Unlike traditional servers, these servers will not be constantly "on" and will only activate when a new request is received, thus saving resources.

In NextJS, each "route" is a file in the pages/api folder. For example, address for the signup route for our application is located at http://ourdomain.com/api/users/signup, and internally it is located in pages/users/signup.tsx. Within each of these files, importing the route module from server/middleware will provide you with all http methods (.get, .post, .patch, etc). From there, you can synchronously or asynchronously handle the request and response. For this, we recommend using the controller pattern.

Controller Pattern

For each route, all routes for that category should be grouped into one folder. For example, all routes referring to users should be placed within the api/users folder. And all functions for handling these requests referring to users should be placed in a UserController.tsx file within the server\controllers folder.

Controller

Each controller should extend the Controller class. The most important thing that you will be access now within your route handlers is the database, which can be accessed by referring to this.req.db. In addition to access to the db, you can also access several important helper methods to assist with sending back responses. See server\controllers\Controller.tsx for more information.