Bootstraping Sell-it Locally

Let's rewind a bit. "Sell-it" was my final project from a fullstack bootcamp in 2017, here for more info.

In this chapter we are going to install its dependencies, configuring the setup, and executing a basic flow.

Installing dependencies

It is always nice having a good up-to-date documentation that shows you the steps to configure the project, so let's peek at the README.md. Looks like we need NodeJS, npm, bower, and MongoDb.

The catch? No clue about the versions 😐

To determine the Node.js version that supports your project, you can check various sources. We can look at docs like README.md, package.json (engines), .nvmrc file, the CI/CD pipeline or a Dockerfile if the app is Dockerized.

In my case, none of these options are available, so I'm going to inspect the dependencies declared in package.json and package-lock.json and refer to its GitHub repo for a compatibility table with Node.js. For instance, node-sass is a popular Sass library with bindings to specific Node.js versions, in their Github there is a table of compatibility to compare the version of node-sass you have with the compatible Node.js, visit their compatibility table here.

With NodeJs configured we can just run npm ci to install the deps declared in the package-lock.json.

Bower is already included in the package, eliminating the need for a global install. A npm@postinstall script in package.json appears to install the dependencies declared in bower.json, and they will be placed in the location specified in .bowerrc.

Now it's time to install the deps and voilà! 🎉

Notes on installation

At this moment I'm not going to review the dependencies used in the package.json nor update the security issues as the idea is to incrementally work on it.

When you want to be more accurate, in my opinion it is better to check the exact versions declared in the package-lock.json as it contains the current installed versions because the package.json does not reflect the current state.

It is important maintaining the package-lock.json to keep consistency across different installations, and even though we can have problems with dependencies of our dependencies that can have marked the semver to get the latest minor or so on..so it is not 100% safe but much better that not having a package-lock.json. There are alternatives like pnpm that handles much better the dependencies.

Docker-compose

To handle MongoDb, I'll inspect the Mongoose version in the package-lock.json and determine compatibility. Mongoose versions only work with specific drivers of MongoDb, similar to node-sass. Sell-it uses mongoose@4.11, so we can set up a Docker-compose to configure a MongoDb instance since I won't be setting up MongoDb locally. Additional information on the compatibility of Mongoose and MongoDb can be found here.

services:
  mongodb:
    image: mongo:3.6
    volumes:
      - sell_it_local_db:/data/db
    ports:
      - 27017:27017
  
volumes:
  sell_it_local_db:

Notes on using a version of MongoDb

Choosing a version of MongoDb like I did is not 100% accurate, there can be deprecations across minor versions that can broke your current queries, but for the sake of the experiment, I'll keep this one.

There are strategies that we can do if we don't know what version of database the project uses, like checking in our case the mongoose version (risky) or preparing a suite of tests to compare the output of them with the production records, for example using characterization test

Configuring environment variables

Post-deps, we dive back into the README.md and find we need a .env setup. here is a description of the variables needed.

As you can see there is a mix in casing the variables, and some of them have a confusing naming.

After a bit of detective work, here's our final env setup that I will push as .env.example:

# SERVER PORT
PORT=3000
 
# DB, NO NEED FOR CHANGE
DB_URI=mongodb://localhost:27017/sell-it-loca
 
# AUTH, USE YOUR MAGIC WORD
SECRET=<SECRET>
 
# CLOUDINARY CONFIG ## 
CLOUDINARY_API_KEY=<CLOUDINARY_API_KEY>
CLOUDINARY_API_SECRET=<CLOUDINARY_API_SECRET>
CLOUD_NAME=<CLOUD_NAME> 
 
# TEMP FOLDER USED FOR MULTER
UPLOAD_FOLDER=temp

There were some variables that looks like weren't used:

# WE ARE USING DB_URI
urlDb=mongodb://localhost:27017/NAME_DB
 
# I THINK WE USE ONLY SECRET
SECRETKEY=XXXXXXXXXX 

And this one refers to the library node-geocoder that I used to reverse the geolocation based on coordinates from the browser to save the city of the user. Apparently I was using the Google provider but I will use a free one that makes the job

# DELETED
API=XXXXXXXXXXXX 

Notes of configuration environment and start the server

It is very important to maintain consistency across our app no matter the style you use (although for env variables is common using uppercase), but at least maintain consistency.

Some of these variables I would not personally add it as .env (if they are not secret no need for that), but I won't touch code unless is strictly necessary by the moment.

With all this jazz sorted, time to fire up the server. Run npm run dev with docker-compose up -d and project's alive and kicking. We can check either the webserver or the admin to see that at least it is running.

Complete register flow

After installing, configuring, and bootstrapping the project, it's time to validate a little bit all the setup by registering a user.

Eureka!

The register process leads you to a register page that request you the location via Geolocation API and some data where after succeed, you must login and edit your profile with a photo. I'm not going to talk on the process nor how it is handled but there is a lot for improvement.

Notes

Previous to being able to register a user there were some issues that I addressed:

node-geocoder error

The first issue involved the configuration of the node-geocoder library, set to use the Google provider requiring an API_KEY. Fortunately, this library supports alternative providers, and I found teleport to be an ideal, free solution.

fix multer destination path

A peculiar observation was the creation of a new folder at the root with a Windows structure (C:/Users/toni/Pictures) after starting the server. This was due to a hardcoded path in the code, a remnant from when I was using Windows during the project's creation 😏. The fix involves using the same value as process.env.UPLOAD_FOLDER to remove images after uploading them to the Cloudinary service.

index on favourites

There was a 'unique' property in favorites causing index problems. I removed it as it was empty by default, resolving the issue.

Recap

In this chapter I wanted to focus on installing the dependencies and configuration needed to boot the server again as well sharing some insights on how we can find a working NodeJs version if our project does not provide any info.

The project suffers from outdated documentation, a common issue in software projects. In my opinion, it's a collective responsibility within the team to update documentation when discrepancies or outdated information are discovered. This not only aids others but also enhances our own understanding of the project.

Lastly, there's minimal error management, a critical aspect in production apps. From logging to error control and providing proper feedback to users, robust error management is essential.

Finally 👉 here are all changes made

Thanks for reading it! 🙌