DEV Community: Neil James Monzales

The day I discovered monorepo

Neil James Monzales — Sun, 04 Jun 2023 13:41:41 +0000

Intro

Hello fellow developers!

If you're like me, you may have spent some time working with microservices and have grown accustomed to the flexibility and independence they offer. However, as your project grows and evolves, you may find yourself feeling the pain of managing multiple codebases and the overhead of coordinating changes across teams.

That's where monorepos come in. A monorepo is a single version control repository that contains multiple projects, each with its own set of dependencies. This allows for better collaboration and easier code management, as everything is in one place.

Why use it?

Normally (in javascript ecosystem), monorepos should be easy to maintain, setup, and deploy! Imagine doing a fix for multiple services in a polyrepo microservice, or even doing feature on the API and in the app. You have to clone and install the dependencies of each service, test, and deploy each per repo. Seems a lot of work, right? But with monorepo, you can easily do this in one repository, and apply the changes in one go! That's the beauty of monorepo.

Why not use it?

You don't have the time to do it.

Kidding aside, there really are some troubles on setting up a monorepo especially if you're not in the javascript ecosystem.

Language Oriented - While there might be language specific support for setting it up, it still might require a lot of work! Also, if you have a multi-language microservice setup, it would take time to perfectly nail it!
Inconsistency - For larger teams, it might be difficult to maintain numerous file changes in the same/different file, which may lead in breaking the app. This, however can be solve to which teams should own the service or app.
Machine dilemmas - Since it has lots of services inside the project, IDEs might hang when installing dependencies, and running multiple services concurrently. This might also be an issue on CI/CDs as base runners might not be able to accommodate large amount of packages cached/uploaded artifacts which might make extra costs on you.

What should I consider when setting it up?

Within the JavaScript ecosystem, several utilities already exist to support the establishment of a monorepo architecture. Npm, Pnpm, and Yarn are among the prominent tools utilized for this purpose. These tools offer valuable features and functionalities that facilitate the management and organization of monorepo projects, streamlining development workflows and improving code sharing across multiple packages.

There is only one thing you need in order to setup your Node JS monorepo, and that is Node itself. Upon installing node you can choose whatever tools you want on how you want to configure your project from scratch, or you may also want to consider using build systems such as Turborepo or Nx for quick and easier setup.

TLDR;

While there are lots of problems solved by monorepo, it also has downsides. Scaling it might cost you a bit or more, but might save you time.

For reference you can take a look on my old repo which uses yarn workspaces. You can fork, clone, and play with it locally. Happy coding!

If you have any implementation or articles that discusses monorepo setup in other languages aside from javascript, or any appreciation/detestation with monorepos, please leave a comment! I would love to see some discussions about it! 😄

Publishing your first Typescript npm package using Github actions

Neil James Monzales — Thu, 14 Apr 2022 20:06:10 +0000

As Javascript/Typescript developer, have you ever dreamed to publish an npm package? If yes, then I'll walk you through the steps I've done to publish my first npm package.

Things we're going to use/tackle

Github actions
Npm

What you need to know

Git
Git tags
Nodejs
Typescript
Github
Github Secrets

First thing to do

You have to create your github repository. and then clone it and initialize your node application using

npm init

After setting up your project, you have to take a look at these package.json properties:

{
  "name": "<@org_name>/<pkg_name>", // you can simply just add the package name and omit `"<@org_name>/` if you don't want to publish it into a certain organization
  "version": "1.1.2", // update this if you want to release a new version of you package
  "main": "lib/index.js", // entry point of your package
  "repository": {
    "type": "git",
    "url": "git+https://github.com/<username>/<repo_name>.git"
  },
  "keywords": ["node"],
  "author": "<your_name>",
  "bugs": {
    "url": "https://github.com/<username>/<repo_name>/issues"
  },// add these for devs/collaborators to submit an issue on your repository
  "homepage": "https://github.com/<username>/<repo_name>#readme", // add these to show the homepage of your package
  "typings": "./lib/index.d.ts" // add this to have a typescript badge in your package, this shows that your package has built in types
}

Configure your typescript application

Add the following dev dependencies:

# using yarn
yarn add -D typescript @types/node nodemon ts-node

Then we have to create tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es6",
    "noImplicitAny": true,
    "removeComments": true,
    "preserveConstEnums": true,
    "sourceMap": true,
    "outDir": "lib",
    "moduleResolution": "Node",
    "rootDir": "./src",
    "allowSyntheticDefaultImports": true,
    "declaration": true,
    "types": ["node"],
    "esModuleInterop": true
  },
  "compileOnSave": true,
  "exclude": [
    "node_modules/**/*",
    ".webpack/**/*",
    "_warmup/**/*",
    ".github/**/*",
    ".vscode/**/*"
  ],
  "include": ["src/*.ts"],
  "buildOptions": {
    "assumeChangesOnlyAffectDirectDependencies": false
  }
}

This configuration outputs the transpiled code from src/* folder to lib directory.

Excluding files from git

We also have to exclude some files/folders in our repository. To exclude them, we have to create .gitignore, in my case these are the following files I have to ignore:

# .gitignore
node_modules # these are the packages installed in our application
lib          # these are the transpiled output files

Create the application

Now, we have to create files inside the src directory.

└── src
    ├── index.ts # entry point of our application
    └── types.ts # optional

Inside src/index.ts, we can just write anything beyond this point. (We can create a package to check if a number is odd 😏 like this one)

Well just as an example, we can do it! 💪🏽

// src/index.ts
const isOdd = (number: number): boolean => number % 2 !== 0;

export { isOdd };

Create scripts for your package

You have to run your app locally before publishing it. We can create dev script inside the scripts property in your package.json.
You should also add a build script so you can transpile your code into javascript.

"scripts": {
  "dev": "nodemon --watch \"src/**\" --ext \"ts,json\" --ignore \"src/**/*.spec.ts\" --exec \"ts-node src/index.ts\"", // dev script
  "build": "tsc -p .", // build script
}

Publishing our package

We're now ready publishing our first package but first things first.

We have to get our npm access token which you can get in your npm profile
You can generate token by selecting either of these scopes:

Note: You can use automation if you wanted to bypass 2-factor authentication. It is highly recommended to use in your ci/cd

After getting the access token, you can now put it in Github secrets.

Tip: You can find it here. https://github.com/<username>/<repo_name>/settings/secrets/actions

Now we can use github actions to publish our npm package. You can use this yaml file for our publish action.

Note: In the yml file, we're going to publish a new version once there is a tag pushed into our repository

Additional note: In order to create a tag, you have to commit all the changes first in your repository. Then you have to create a tag using this command:

git tag -a <version> -m '<message>' # the tag version should match the package version which can be seen on `package.json`

Once everything is settled, you can push the tag using

git push --tags

You just have to wait and check if the ci/cd succeeds.

Note: If anything breaks in your development, you can reference my project here https://github.com/nljms/ph-mobile-networks

I hope this helps you in your journey building your first npm package! 😄

How to secure your server with SSL in less than 10 minutes

Neil James Monzales — Wed, 17 Nov 2021 04:23:07 +0000

This is a quick guide for engineers who doesn't have broad knowledge in setting up SSL together with nginx from scratch.

Things to be familiar with:

Docker
Nginx
Node (Can be any web framework)

Disclaimer

I won't be tackling in depth topics about docker, nginx, etc.

What we're gonna build

A simple microservice that serves up a backend service which is served in nginx inside the swag container.

Let's dive into it!

Setting Up a Web Server

We're going to create a simple web server using Express JS or you can clone the repository here and https://github.com/nljms/linux-server-swag-demo/.

Once the server is up and running let's proceed to the next step 🙂

Dockerizing the services we need.

In order to build our microservices, we have to create their images first. If you have cloned the repository given above, you'll notice that there were two Dockerfiles (the Dockerfile which serves as the node application image, and the Dockerfile.swag which is a custom image of linuxserver.io/swag

Note: I mentioned before that we're gonna be using nginx on this project. Since we're going to secure the server with letsencrypt, I found an easier way on how to do it in just a few steps with linuxserver/swag image.

You can read more about the documentation here on their documentation

Since the first image is only about the containerized node application. I'll only be discussing the custom swag image.

# Dockerfile.swag

FROM ghcr.io/linuxserver/swag

COPY ./default.conf /config/nginx/site-confs/default

What we only do here is that we replace the default configuration of the nginx inside the image since we're just going to reverse proxy our demo_api service which is here:

   location / {
        proxy_pass http://demo_api:3000;
    }

Note: I only modified the nginx configuration which I copied inside the swag image and put it inside nginx/default.conf file (you can name it whatever you want but just make sure to apply the changes the Dockerfile).

Additional Note: If you notice that we're proxying demo_api instead of a local address, in docker-compose we can have a default network or create a network for the services to communicate by their hostname identical to their container name.

You can check out the compose file here.

Linux Server SWAG image usage:

Inside our compose file, we have the swag service:

  swag:
    build:
      dockerfile: ./Dockerfile.swag
      context: .
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      PUID: 1000 # required
      PGID: 1000 # required
      TZ: Singapore # required
      URL: '${YOUR_DOMAIN}' # required
      VALIDATION: http # required
      DEFAULT_CONF: '${DEFAULT_CONF}' # required
    volumes:
      - swag:/config # I created a volume named swag to persist the config directory inside the container
    ports:
      - 443:443
      - 80:80 #optional
    restart: unless-stopped
    networks:
      - local-network

You only have to provide the URL environment variable which in your case was your domain name (Please make sure that your domain name is available), then run

docker-compose up --build -d

to build the dockerfiles and run it on detach mode. And that's it! Your server is now secured!

You can check the full documentation of linuxserver/swag here

Thank you so much for reading and I hope I helped you in such a little way. Have a great day!