GIT-USERNAME-HERE REPO-NAME-HERE APP-NAME-HERE PUT-TECH-STACK-HERE API-DEPLOY-URL-HERE

PUT-TECH-STACK-HERE
Explore the docs »

Report Bug · Request Feature?

---

This will be a comprehensive README for the sake of both prospective employers and fellow cohort peers, and whomever else would be interested in some of the techniques I've learned creating my frist Fullstack application. As a bonus, this README has some interesting implementations, though I won't address them here.

If you'd like to test the server via Postman, visit the client app...

here

...register a user, grab your Bearer Token in dev tools, and use this endpoint: https://glacial-basin-85263.herokuapp.com/setapp/v1

---

Nothing much to say here, simple SQL code to seed the database

Bog-standard setup using Knex

I use this to configure all environment variables and export them from a single source. You can then access these via destructured imports:

const { NODE_ENV } = require('./config');

Most of the setupp here is standard, with some particular use of conditionals and environment variables to configure middleware options. Note the absence of importing express, I'll get to that a little later...

You may have already noticed that there are actually many [ index.js ] files peppered throughout the app. These are known as "barrel" exports, and have a few advantages when dealing with a complex file-directory. The index file in the [ routes ] folder has a short explanation, but I'll also put it here:

/*
|--------------------------------------------------------------------------
| BARREL EXPORT FILE
|--------------------------------------------------------------------------
| How-To barrel-export components:
| const thingsRouter = require('./things/thingsRouter')
|
| module.exports = {
|   thingsRouter
| }
|
| Why? Readability:
| const { thingsRouter, stuffRouter, userRouter } = require('./routes')
*/
const usersRouter = require('./users.router');

module.exports = {
  usersRouter
};

You can see this in action in [ app.js ]:

Note that the import doesn't point to the index file. Node perceives [ index.js ] files as points of entry and the default file to grab exports from, essentially making it an implicit file in import statements

Not strictly necessary, but this can help prevent typos, along with making changes to the database less tedious to update throughout the app.

A simple Winston logger, though bacause Heroku doesn't support writing logs in this way, the transports aren't created during production.

Though it may be inconsequential for a server of this scale, it should be known that every time you import a package from node_modules there's a memory cost at runtime, made worse by doing a destructured import. Express is costly to import (~750K unzipped), so I came up with this method here, resulting in importing Express only once in my entire server.

I can create both the app and jsonBodyParser (which is just middleware), and extract the Router() method itself (to be used as a sort of local "helper" function). Beacuase these are now local dependencies, I can import these wherever I want without an impact on runtime performance.

These are used to extract and validate request body values on a per-route basis, serialize any user-inputs, then creates a completed object passing it on to the next middleware. There are a few helper-functions at the top to DRY up the code a bit.

There's nothing too special here, just basic Token authentication, password encryption, and error handling/formatting.

A brief overview of the database:

This isn't 100% representative of the current database implementation, but from a relationship view this is how the Server operates. Currently, the following tables are implemented: users, songs, sets, songs_sets