Forem: Amplication

Creating a Restaurant Finder Application Using ReactJS and Amplication

Saurav Jain — Mon, 15 Jan 2024 06:16:31 +0000

Introduction

This tutorial will guide you through building a restaurant finder application. This full-stack web application will allow users to search for restaurants based on location (zip code) and view a list of restaurants that match their criteria. We'll create the backend and frontend components and demonstrate how to connect them to create a fully functional restaurant finder.

This tutorial will include how to create a backend using Amplication, create a frontend using ReactJS, and connect the backend created by Amplication to the frontend.

Creating the backend:

In this part of the tutorial, we will use Amplication to develop the backend of our restaurant finder application. Amplication creates a fully functional production-ready backend with REST and GraphQL API, authentication, databases, best practices, etc., in a few minutes.

Go to https://amplication.com.
Login into it or make an account if you have not already.
Create a new app and name it restaurant-finder-backend.
Click on Add Resource and then on Service and name it restaurant-finder.
Then, connect your GitHub account to the one on which you want Amplication to push the backend code and select or create a repository.
Choose which API you want; we will go by the default, and that is both.
Choose monorepo in this step.
Choose the database. We will go with PostgreSQL.
We will create entities from scratch.
We want to have auth in the app.
Click on create service, and the code is generated now.
Go to Entities and click on add entity:
- Entity Name: Restaurant
- First field: name [Searchable, Required, Single Line Text]
- Second field: address [Searchable, Required, Single Line Text]
- Third field: phone [Searchable, Required, Single Line Text]
- Fourth field: zipCode [Searchable, Required, Single Line Text]

Click on Commit Changes and Build, and in a few minutes, the code will be pushed to the GitHub repository. Go to the repo and approve the Pull Request that Amplication created.

Now, you have all the backend code generated by Amplication in your GitHub repository.
It will look like this:

Backend Code: https://github.com/souravjain540/restaurant-finder

Now clone your repository, open it in the IDE of your choice, go to restaurant-finder-backend/apps/restaurant-finder, and follow these commands:

npm install
npm run prisma:generate
npm run docker:dev
npm run db:init
npm run start

After all these steps, you will have a backend running on localhost:3000. As Amplication comes with AdminUI and Swagger Documentation, you can go to localhost:3000/api and view all the endpoints of the API that amplication generated.

Let’s click on the auth and make a POST request by clicking on try it out with credentials admin and admin.

Now click on execute, copy the accessToken, and save it for the auth purpose later.

Now, we have our backend ready and running on our local system. It is now time to move to the frontend part.

NOTE: If you have any problems using Amplication while creating your web application or in the installation, please feel free to contact the Amplication Team on our Discord channel.

Creating the frontend:

In this part, we will build the frontend of our restaurant finder application using React, a popular JavaScript library for building user interfaces. We'll create the user interface for searching restaurants by zipcode, displaying search results, and adding new restaurants.

Setting up React Project:

First, ensure your system has Node.js and npm (Node Package Manager) installed. If not, you can download and install them from the official Node.js website.

Let's create a new React project using Create React App, a popular tool for setting up React applications with a predefined project structure. Open your terminal and run the following command:

npx create-react-app restaurant-finder

This command will create a new directory called restaurant-finder containing all the necessary files and folders for your React project.

Designing the User Interface with Components

In React, you build user interfaces by creating components. Let's design the components for our restaurant finder application.

There will be three main components in our project:

SearchForm Component: This will be the main page of our project where the user will enter the zipCode, and all the restaurants with that zipCode will be shown as a list in the result. It will work in the root directory. (/)
RestaurantForm Component: This page will be responsible for adding any new restaurant to the list of restaurants. It will be a form with all the relevant details. It will work at /restaurants/add.
RestaurantList Component: This page will show all the restaurants available in our database. It will work at /restaurants.

Directory Structure:

To avoid any confusion, the file structure will look like this:

Create a SearchForm Component

Inside the src folder of your project, create a new file named SearchForm.js. This component will be responsible for the restaurant search form. Let's break down the code snippet of SearchForm.js step by step:

Import Statements:

   import React, { useState } from 'react';
   import axios from 'axios';

The code begins with importing the necessary modules.
React is imported to define React components.
useState is a React hook used to manage component-level state.
axios is imported to make HTTP requests to the backend API.

getAuthToken Function:

   const getAuthToken = () => {
     // Replace this with your logic to obtain the token
     return 'ebGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....'; // A placeholder token
   };

getAuthToken is a function that should be replaced with your actual logic to obtain an authentication token.
In this code, it returns a placeholder token.

Axios Configuration:

   const api = axios.create({
     baseURL: 'http://localhost:3000/api', // Adjust the base URL to your API endpoint
     headers: {
       'Content-Type': 'application/json',
       Authorization: `Bearer ${getAuthToken()}`, // Attach the token here
     },
   });

api is an instance of Axios configured with a base URL for the backend API.
It sets the Content-Type header to indicate that the request body is in JSON format.
It also attaches an authorization header with the token obtained from getAuthToken.

SearchForm Component:

   function SearchForm({ onSearch }) {
     // ...
   }

SearchForm is a React functional component that takes a prop named onSearch.
Inside this component, we will create the UI for searching restaurants by zip code.

Component State:

   const [zipCode, setZipCode] = useState('');
   const [restaurants, setRestaurants] = useState([]);

useState is used to define two pieces of component state: zipCode and restaurants.
zipCode stores the user's input for the zip code.
restaurants will store the search results.

handleSearch Function:

   const handleSearch = () => {
     if (zipCode.trim() !== '') {
       // API request to search for restaurants based on the provided zip code
       // ...
     }
   };

handleSearch is a function that is called when the user clicks the "Search" button.
It first checks if the zipCode is not empty.
If the zipCode is not empty, it makes an API request to search for restaurants based on the provided zip code.

Making the API Request:

   api.get('/restaurants', {
     params: {
       where: { zipCode }, // Send the zipCode as a query parameter
     },
   })
     .then(response => {
       // Handle the API response
       // ...
     })
     .catch(error => console.error('Error searching restaurants:', error));

Axios is used to make a GET request to the /restaurants endpoint of the backend API.
It includes a query parameter where with the specified zipCode.
If the request is successful, the response is processed in the .then block, and the search results are updated in the restaurants state.
If there's an error, it is caught and logged in the .catch block.

Rendering the UI:
- The component returns a JSX structure for rendering the search form, search button, and search results.
- The search results are displayed as a list of restaurants if there are any.

That's a breakdown of the SearchForm.js code. It defines a React component for searching restaurants by zip code and requests API to retrieve restaurant data based on user input.

You can look into the final code of searchForm.js: https://github.com/souravjain540/restaurant-finder-frontend/blob/main/src/components/searchForm.js

Create a RestaurantForm Component

Now, let's create a component for adding new restaurants. Create a file named RestaurantForm.js inside the src folder. This component will allow users to input restaurant details and submit them to the backend. Let's break down the code snippet of RestaurantForm.js step by step:

Import Statements:

   import React, { useState } from 'react';
   import axios from 'axios';

The code begins with importing the necessary modules.
React is imported to define React components.
useState is a React hook used to manage component-level state.
axios is imported to make HTTP requests to the backend API.

getAuthToken Function:

   const getAuthToken = () => {
     // Replace this with your logic to obtain the token
     return 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....'; // A placeholder token
   };

getAuthToken is a function that should be replaced with your actual logic to obtain an authentication token.
In this code, it returns a placeholder token.

Axios Configuration:

   const api = axios.create({
     baseURL: 'http://localhost:3000/api', // Adjust the base URL to your API endpoint
     headers: {
       'Content-Type': 'application/json',
       Authorization: `Bearer ${getAuthToken()}`, // Attach the token here
     },
   });

api is an instance of Axios configured with a base URL for the backend API.
It sets the Content-Type header to indicate that the request body is in JSON format.
It also attaches an authorization header with the token obtained from getAuthToken.

RestaurantForm Component:

   function RestaurantForm({ onFormSubmit }) {
     // ...
   }

RestaurantForm is a React functional component that takes a prop named onFormSubmit.
Inside this component, we will create the UI for adding a new restaurant.

Component State:

   const [name, setName] = useState('');
   const [address, setAddress] = useState('');
   const [zipCode, setZipCode] = useState('');
   const [phone, setPhone] = useState('');

useState is used to define four pieces of component state: name, address, zipCode, and phone.
These states will store the user's input for the restaurant's name, address, zip code, and phone number.

handleFormSubmit Function:

   const handleFormSubmit = (e) => {
     e.preventDefault();

     const newRestaurant = {
       name,
       address,
       zipCode,
       phone,
     };

     api.post('/restaurants', newRestaurant)
       .then(response => {
         // Call the onFormSubmit function with the newly created restaurant
         onFormSubmit(response.data);

         // Clear the form input fields
         setName('');
         setAddress('');
         setZipCode('');
         setPhone('');

         // Refresh the page after a successful submission
         window.location.reload();
       })
       .catch(error => console.error('Error creating restaurant:', error));
   };

handleFormSubmit is a function that is called when the user submits the restaurant form.
It first prevents the default form submission behavior.
It creates a newRestaurant object with the values entered in the form fields.
It makes a POST request to the /restaurants endpoint of the backend API to create a new restaurant.
If the request is successful, it calls the onFormSubmit function with the newly created restaurant data.
It also clears the form input fields, and then refreshes the page to reflect the updated restaurant list.
If there's an error, it is caught and logged.

Rendering the UI:
- The component returns a JSX structure for rendering the restaurant form.
- The form includes fields for entering the restaurant's name, address, zip code, and phone number.
- When the user submits the form, the handleFormSubmit function is called.

That's a breakdown of the RestaurantForm.js code. It defines a React component for adding a new restaurant to the system, and it makes an API request to create the restaurant on form submission.

You can view the whole code here: https://github.com/souravjain540/restaurant-finder-frontend/blob/main/src/components/restaurantForm.js

Creating the restaurantLists component:

Next, create a file named RestaurantList.js inside the src folder. This component will display the list of restaurants returned by the search. Let's break down the code snippet of RestaurantList.js step by step:

Import Statements:

   import React, { useState, useEffect } from 'react';
   import axios from 'axios';

The code begins with importing the necessary modules.
React is imported to define React components.
useState and useEffect are React hooks used to manage component-level state and side effects.
axios is imported to make HTTP requests to the backend API.

getAuthToken Function:

   const getAuthToken = () => {
     // Replace this with your logic to obtain the token
     return 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....'; // A placeholder token
   };

getAuthToken is a function that should be replaced with your actual logic to obtain an authentication token.
In this code, it returns a placeholder token.

Axios Configuration:

   const api = axios.create({
     baseURL: 'http://localhost:3000/api', // Adjust the base URL to your API endpoint
     headers: {
       'Content-Type': 'application/json',
       Authorization: `Bearer ${getAuthToken()}`, // Attach the token here
     },
   });

api is an instance of Axios configured with a base URL for the backend API.
It sets the Content-Type header to indicate that the request body is in JSON format.
It also attaches an authorization header with the token obtained from getAuthToken.

RestaurantList Component:

   function RestaurantList() {
     // ...
   }

RestaurantList is a React functional component that displays a list of restaurants.
Inside this component, we will fetch the list of restaurants from the backend and display them.

Component State:

   const [restaurants, setRestaurants] = useState([]);

useState is used to define a state variable restaurants that will store the list of restaurants fetched from the API.

Fetching Restaurants:

   useEffect(() => {
     api.get('/restaurants')
       .then(response => {
         setRestaurants(response.data);
       })
       .catch(error => console.error('Error fetching restaurants:', error));
   }, []);

The useEffect hook is used to fetch the list of restaurants when the component mounts (i.e., when it first renders).
It makes a GET request to the /restaurants endpoint of the backend API.
When the response is received, it sets the restaurants state with the data.

Deleting Restaurants:

   const handleDelete = (restaurantId) => {
     api.delete(`/restaurants/${restaurantId}`)
       .then(() => {
         // Filter out the deleted restaurant
         setRestaurants(restaurants.filter(restaurant => restaurant.id !== restaurantId));
       })
       .catch(error => console.error('Error deleting restaurant:', error));
   };

The handleDelete function is called when a user clicks the "Delete" button next to a restaurant.
It makes a DELETE request to the /restaurants/{restaurantId} endpoint of the backend API to delete the restaurant.
After successful deletion, it updates the restaurants state by filtering out the deleted restaurant.

Rendering the UI:
- The component returns a JSX structure for rendering the list of restaurants.
- It maps over the restaurants array and displays each restaurant's name, address, phone number, and zip code.
- A "Delete" button is provided for each restaurant, which triggers the handleDelete function when clicked.

That's a breakdown of the RestaurantList.js code. It defines a React component for displaying a list of restaurants fetched from the backend and provides the ability to delete restaurants.

Find the complete code snippet here: https://github.com/souravjain540/restaurant-finder-frontend/blob/main/src/components/restaurantList.js

Changing the App.js file:

Let's break down the code snippet of App.js step by step:

Import Statements:

   import React from 'react';
   import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';
   import RestaurantList from '/Users/sauravjain/projects/my-restaurant-app/src/components/restaurantList.js';
   import RestaurantForm from '/Users/sauravjain/projects/my-restaurant-app/src/components/restaurantForm.js';
   import SearchForm from '/Users/sauravjain/projects/my-restaurant-app/src/components/searchForm.js';
   import '/Users/sauravjain/projects/my-restaurant-app/src/index.css'; // Import the CSS file

The code begins with importing the necessary modules and components.
React is imported to define React components.
BrowserRouter, Routes, and Route are imported from react-router-dom for defining and handling routes in the application.
RestaurantList, RestaurantForm, and SearchForm are imported as components from their respective file paths.
The CSS file is imported to apply styles to the application.

App Component:

   function App() {
     // ...
   }

App is a React functional component that serves as the main component for the application.
Inside this component, you define the routes, layout, and functionality of the app.

Event Handlers:

   const handleSearch = (searchResults) => {
     // Handle the search results (e.g., update state)
     console.log('Search results:', searchResults);
   };
   const handleFormSubmit = (newRestaurantData) => {
     // Update the state with the new restaurant data
     console.log('Restaurant data: ', newRestaurantData);
   };

Two event handler functions, handleSearch and handleFormSubmit, are defined. These functions are used to handle data received from child components.
handleSearch is intended to handle search results data, and handleFormSubmit is intended to handle new restaurant data.

Router Setup:

   return (
     <Router>
       <div className="App">
         <h1>Restaurant Finder</h1>

         <Routes>
           <Route path="/" element={<SearchForm onSearch={handleSearch} />} />
           <Route path="/restaurants" element={<RestaurantList />} />
           <Route path="/restaurants/add" element={<RestaurantForm onFormSubmit={handleFormSubmit} />} />
           <Route path="/restaurants/edit/:id" element={<RestaurantForm />} />
         </Routes>
       </div>
       <footer>
         {/* Footer content */}
       </footer>
     </Router>
   );

The Router component is used to wrap the entire application, enabling client-side routing.
Inside the router, there is a div with the class name "App" that serves as the main container for the application.
The h1 element displays the title "Restaurant Finder."

Routes Configuration:
- Inside the Routes component, different routes are defined using the Route component from react-router-dom.
- The routes specify which components to render when certain URLs are accessed.
Route Paths and Components:
- / path is associated with the SearchForm component. The onSearch prop is passed to it, allowing it to handle search results.
- /restaurants path is associated with the RestaurantList component.
- /restaurants/add path is associated with the RestaurantForm component. The onFormSubmit prop is passed to it to handle form submissions.
- /restaurants/edit/:id path is associated with the RestaurantForm component, presumably for editing restaurant data.
Footer Section:
- Below the Router content, there is a footer section with links to the author's Twitter profile and a mention of "Backend Powered by Amplication."

This is an overview of the App.js code, which sets up the routing and components for your restaurant finder application. It defines how different components are rendered based on the URL paths and handles events with the defined event handler functions.

Have a look at the final code snippet of the App.js file here: https://github.com/souravjain540/restaurant-finder-frontend/blob/main/src/App.js

In the end, I encourage everyone to create the frontend by themselves according to their creativity, but if you want to have it like mine, please copy the index.html and index.css file as well.

In the end, your app will look like this:

Root directory(searchForm):

restaurantLists.js:

restaurantForm.js

You can have a look at the complete frontend code here: https://github.com/souravjain540/restaurant-finder-frontend/tree/main

If you have any problem with any part of this tutorial, please feel free to contact me on my Twitter account. Thanks for giving it a read.

Extending GitOps: Effortless continuous integration and deployment on Kubernetes

Levi van Noort — Tue, 26 Dec 2023 09:26:49 +0000

Introduction:

Over the last decade, there have been notable shifts in the process of delivering source code. One of the more recent adaptations on the deployment aspect of this process has been the declarative and version controlled description of an application's desired infrastructure state and configuration - commonly referred to as 'GitOps'. This approach has gained popularity in the context of cloud-native applications and container orchestration platforms, such as Kubernetes, where managing complex, distributed systems can be challenging.

As this desired state is off declarative nature, it points to a specific/static version of that application. This offers significant benefits, particularly the fact that it is possible to audit changes before they are made, roll back to a previous state and maintain a reproducible setup. Without requiring a pipeline to make changes in the application's state/configuration, how can we move to the more recent application version while avoiding manual version adjustment?

This is where Argo CD Image Updater comes in; it verifies if a more recent version of a container image is available, and subsequently triggers the necessary updates of the application's Kubernetes resources or optionally these changes in the associated version control.

Overview:

Prior to diving into the technical implementation, let's establish an overview of the GitOps process and highlight the role of Argo CD Image Updater within this process.

Default GitOps

The first part of process starts with a developer modifying the source code of the application and pushing the changes back to the version control system. Subsequently, this action initiates a workflow or pipeline that both constructs and assesses the application. The outcome is an artifact in the form of a container image, which is subsequently pushed to an image registry.

In a second - detached - part of the process, the cluster configuration repository is the single source of truth regarding the the desired state of the application configuration. Argo CD periodically monitors the Kubernetes cluster to see if the live state differs from the desired state. When there is a difference, depending on the synchronization strategy Argo CD tries to revert back to the desired state.

Extended GitOps

Compared to the default process, in this extended, variant another Argo CD component is added to the Kubernetes cluster. The Argo CD Image Updater component verifies if a more recent version of a container image exists within the image registry. If such version is identified, the component either directly or indirectly updates the running application. In the next section we'll delve into the configuration options for the Argo CD Image Updater as well as the implementation of the component.

Configuration:

Before the technical implementation we'll familiarize ourself with the configuration options Argo CD Image Updater provides. This configuration can be found in two concepts, the write back method and update strategy. Both have options tailored to specific situation, so it is good to understand what the options are and how that equates to the technical implementation.

For this configuration/demonstration the following repositories can be referenced

Write Back Method

At the moment of writing Argo CD Image Updater supports two methods of propagating the new versions of the images to Argo CD. These methods also referred to as write back methods are argocd & git.

argocd: This default write back method is pseudo-persistent - when deleting an application or synchronizing the configuration in version control, any changes made to an application by Argo CD Image Updater are lost - making it best suitable for imperatively created resources. This default method doesn't require additional configuration.
git: The other write back method is the persistent/declarative option, when the a more recent version of a container image is identified, Argo CD Image Updater stores the parameter override along the application's resource manifests. It stores the override in a file named .argocd-source-<application-name>.yaml, reducing the risk of a merge conflict in the application's resource manifests. To change the write back method the an annotation needs to be set on the Argo CD Application resource. In addition the branch the to commit back to can optionally be changed from the default value .spec.source.targetRevision of the application.

From an audit trail and a reproducible perspective, this is the desired option. It provides us with the option to have automatic continuous deployment, while keeping these aspects that GitOps is known for.
```
argocd-image-updater.argoproj.io/write-back-method: git
```

Note:
When using the git write back method, credentials configured for Argo CD will be re-used. A dedicated set of credentials can be provided, this and more configuration can be found in the documentation.

Update Strategies

In addition to the choice of which write back method to use we need to decide on a update strategy. This strategy defines how Argo CD Image Updater finds new versions of an image that is to be updated. Currently four methods are supported; semver, latest, digest, name.

Before looking at their respective differences, we'll need to know what mutable and immutable image tags are. A mutable repository has tags that can be overwritten by a newer image, where as when a repository configuration states that tags must be immutable - it can't be overwritten by a newer image. From the options below each options expects immutable tags to be used, if a mutable tag is used the digest strategy should be used.

semver: Updates the application to the latest version of an image in an image registry while taking into consideration semantic versioning constraints - following the format X.Y.Z, where X is the major version, Y is the minor version and Z the patch version. The option can be configured to only bump, to newer minor or patch versions - it also supports pre-release versions through additional configuration. In the example below the application would be updated with newer patch version of the application, but not upgrading when a newer minor or major version is present.
```
argocd-image-updater.argoproj.io/<alias>.update-strategy: semver
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>[:<version_constraint>]
```
latest: Updates the application with the image that has the most recent build date. When a specific build has multiple tags Argo CD Image Updater picks the lexically descending sorted last tag in the list. Optionally if you want to consider only certain tags, an annotation with a regular expression can be used. Similarly an annotation can be used to ignore a list of tags.
```
argocd-image-updater.argoproj.io/<alias>.update-strategy: latest
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>
```
digest: Updates the application based on a change for a mutable tag within the registry. When this strategy is used image digests are be used for updating the application, so the image on the cluster for <repository-name>/<image-name>:<tag_name> appears as <repository-name>/<image-name>@sha256:<hash>.
```
argocd-image-updater.argoproj.io/<alias>.update-strategy: digest
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>:<tag_name>
```
name: Updates the application based on a lexical sort of the image tags and uses the last tag in the sorted list. Which could be used when using date/time for tagging images. Similar to the latest strategy, a regular expression can be used to consider only specific tags.
```
argocd-image-updater.argoproj.io/<alias>.update-strategy: name
argocd-image-updater.argoproj.io/image-list: <alias>=<repository-name>/<image-name>
```

Implementation:

We'll start out by creating two repositories as can been seen within the overview, a source code and a cluster configuration repository. Theoretically both could be housed in the same repository, but a separation of concerns is advised.

The next step would be to setup the continuous integration pipeline to create the artifact, i.e. container image, that are to be used as a starting point in the continuous deployment process. In this walkthrough we'll use GitHub for our repository as well as GitHub Actions for our pipeline. However this setup can be made in most popular version control/pipeline options.

Continuous Integration Workflow

Within the source code repository under the .github/worksflows/ directory we'll create a GitHub actions workflow, which we name continuous-integration.yaml. This workflow consists of checking out the source code, building the container image and pushing it to the GitHub Packages Image registry.

name: continuous-integration

on:
  push:
    branches: ["main"]
    tags: ["*"]
  pull_request:
    branches: ["main"]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push:
    name: build and push container image
    runs-on: ubuntu-latest

    permissions:
      contents: read
      packages: write

    steps:
      - name: checkout source code
        uses: actions/checkout@v4

      - name: authenticate with repository
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: image metadata
        uses: docker/metadata-action@v4
        id: meta
        with:
          images: "${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}"
          tags: |
            type=sha,prefix=sha-
            type=ref,event=pr,prefix=pr-
            type=ref,event=tag,prefix=tag-
            type=raw,value=${{ github.run_id }},prefix=gh-
            type=raw,value=${{ github.ref_name }}
            type=raw,value=latest,enable=${{ github.ref_name == 'main' }}

      - name: build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

For simplicity sake the image registry is made public so that additional authentication from within the cluster isn't needed. You can discover a detailed tutorial on how to make a GitHub Package public here. If you prefer utilizing a private repository, refer to this guide to enable pulling from the private repository within the cluster.

We can see that after we commit to our main branch that packages are automatically pushed to our GitHub packages image registry.

If we now release everything that is in the main branch with a semantic version of v1.0.0 we can see the newer version of the application image, where the sha-<number> is also placed on the newer image as no new commit was made between the previous push on main and the tag.

Cluster Configuration

For our application's Kubernetes resources we'll create a Helm chart. In the cluster configuration repository, under the charts directory run the following command:

helm create <application-name>

  charts/<application-name>
    ├── .helmignore   # patterns to ignore when packaging Helm charts.
    ├── Chart.yaml    # information about your chart
    ├── values.yaml   # default values for your templates
    ├── charts/       # chart dependencies
    └── templates/    # template files
        └── tests/    # test files

Argo CD & Argo CD Image Updater Installation

Start by setting up a Kubernetes cluster, for this demonstration a local cluster is be used, created through minikube - other tools like kind or k3s can also be used. After installing minikube the following command can be ran to start the cluster:

minikube start

The next step would be to setup Argo CD within the cluster, this can be done by running the following commands:

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

To get access to the running Argo CD instance we can use port-forwarding to connect to the api server without having to expose the service:

kubectl port-forward svc/argocd-server -n argocd 8080:443

An initial password is generated for the admin account and stored under the password field in a secret named argocd-initial-admin-secret. Use this to login with the username value admin and change the password for the user in the 'User Info' . Another safer option would be to use SSO.

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

In addition we also go ahead ad install Argo CD Image Updater into the cluster, this could also be done declaratively as we'll see in the upcoming paragraphs.

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/manifests/install.yaml

Now that we have access to the Argo CD user interface, we'll look at the configuration of Argo CD Applications.

Argo CD Authentication

Before we can configure Argo CD to start managing the application's Kubernetes resources, we need to make sure that Argo CD can access the cluster configuration repository. Repository details are stored in secret resources. Authentication can be handled in different ways, but for this demonstration we'll use HTTPS.

syntax

apiVersion: v1
kind: Secret
metadata:
  name: <repository-name>
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/<organization-or-username>/<repository-name>
  password: <github-pat>
  username: <github-username>

Before we can declaratively create the secret used for authentication we need to create the GitHub Personal Access Token (PAT) used in the password field of the secret. Navigate to Settings on the profile navigation bar. Click on Developer settings > Personal access tokens > Fine-grained token & Generate new token. Set a token name, e.g., argocd-repository-cluster-configuration and set an expiration, I would suggest for a year.

Set the Resource owner to the user or organization that the cluster configuration repository is in. Set the Repository access to 'only select repositories' and set it to access only the cluster configuration repository. Lastly we need to give the token scoped permissions, for the integration to work we need the following: Contents - Access: Read and write & Metadata - Access: Read-only.

./secret/cluster-configuration-repository.yaml

apiVersion: v1
kind: Secret
metadata:
  name: blog-cluster-configuration
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/amplication/bookstore-cluster-configuration
  password: <github-pat>
  username: levivannoort

Apply this secret against the cluster by using the following command:

kubectl apply -f ./secret/cluster-configuration-repository.yaml

When looking at the Argo CD user interfaces, we can see under the settings > repositories whether the authentication against the GitHub repository has succeeded. We should now be able to start using the repository definition in our Argo CD application.

Argo CD Configuration

Now that we're able to authenticate against GitHub to get the content from the cluster configuration repository. We can start defining our Argo CD applications and start managing the application's Kubernetes resources. This can be done in an imperative or declarative manner. For this demonstration we'll configure the Argo CD application declaratively. Lets look at the following manifest:

syntax

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: <application-name>
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/<organization-name>/<repository-name>.git
    targetRevision: main
    path: charts/<application-name>
  destination:
    server: https://kubernetes.default.svc
    namespace: <application-name>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
      - CreateNamespace=true

For instrumenting Argo CD Image Updater we'll need to add the previously mentioned annotations. We're going for the semver update strategy with a argocd write back. As both the chosen update strategy as well as the write back method are the default we don't need to specify these annotations.

Add the following annotations:

argocd-image-updater.argoproj.io/image-list: bookstore=ghcr.io/amplication/bookstore-application

example-application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: bookstore
  namespace: argocd
  annotations:
    argocd-image-updater.argoproj.io/write-back-method: argocd
    argocd-image-updater.argoproj.io/bookstore.update-strategy: semver
    argocd-image-updater.argoproj.io/image-list: bookstore=ghcr.io/amplication/bookstore-application
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/amplication/bookstore-cluster-configuration.git
    targetRevision: main
    path: charts/bookstore
  destination:
    server: https://kubernetes.default.svc
    namespace: bookstore
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
      - CreateNamespace=true

Apply this configuration against the cluster by using the following command:

kubectl apply -f <manifest-name>.yaml

Demonstration:

After creation of the Argo CD application we can see that the application is healthy and running within the cluster. As our application needed a database to be able to run we added a dependency to a postgresql helm chart for running a database in the cluster as well - so additional resources can be seen next to the default Helm chart Kubernetes resources.

If we take an in-depth look on the deployment object we'll see the image tag currently used by the deployment, which is the current last release within the repository - v1.0.0.

When looking at the Argo CD Image Updater logging, we can see that it has picked up the fact that we want to continuously update to the latest semantic version. By setting log.level to debug instead of the default info we get more information around which images are being considered and which do not match the constraints.

Next we update the application with some changes and release the component again with an incremented version 1.0.1:

After the workflow has concluded this newer version should be present within the image registry:

ArgoCD image updater periodically checks the image registry for newer versions per the constraints and finds the v1.0.1 image.

For the demonstration I decided to disable the automated synchronization policy. As you can see Argo CD Image Updater changed the image tag from v1.0.0 to v1.0.1.

Conclusion:

We managed to successfully configure the extended GitOps setup. Any changes made on the application side should be reflected by outputting a container image to the artifact registry, successfully completing the Continuous Integration side. After which in a detached manner the Continuous Deployment process is started by Argo CD Image Updater finding a newer container image in the image registry and updating the declaratively defined image tag for the application. In turn triggering Argo CD to update the application's Kubernetes resource, serving the newer version of the application by updating the deployment with the new image tag.

A possible improvement to the setup demonstrated, would be to switch over to the git write back method, improving the setup by being more reproducible as well as having a clear audit trail.

The application used in this demonstration was generated through Amplication, which allows you to generate production-ready backend services - reliably, securely, and consistently.

Note:
As of writing the blog the Argo CD Image Updater project does not honor the Argo CD's rollback feature and thus automatically updates the application back to the latest version found in the image registry. A solution to this would be to temporary disable the indexing of Argo CD Image Updater for the application and set the image.tag in the Helm chart to the desired version.

Auth0 and Amplication: Simplifying Authentication in Your Applications

Ashish Padhy — Fri, 24 Nov 2023 10:19:36 +0000

Introduction

Auth0 is a cloud service that provides a turn-key solution for authentication, authorization and user management. It is a feature-rich service that is highly customizable and can be used in a variety of ways. Auth0 is a great choice for a wide range of applications, from simple web apps to enterprise applications. It provides a great way to add authentication and authorization to your application without having to build it yourself, and has various integrations with services such as Google, Facebook, Twitter, and more. This along with its passwordless authentication and multi-factor authentication makes it a great choice for a wide range of applications.

How to use Auth0 authentication in your Amplication application

Setting up Auth0 authentication in your Amplication application is easy. You can use the Auth0 plugin to add the required dependencies and configuration files to your application. The steps are as follows:

Create a service in amplication

Start by creating a service within the Amplication platform. Once your service is set up, click on the Commit changes & build button to initiate the build process. Merge the generated Pull Request to move ahead.

Add the NestJS Auth Module

Next, add the NestJS Auth Module to your service. You can do this by navigating to the Plugins section within your service topbar menu.

Also create and set an authentication entity if you have not done so yet. For more information on how to do this, see the Authentication section of the Amplication documentation.

Add the Auth0 plugin

Next, add the Auth0 plugin to your service. You can do this by navigating to the 'Plugins' section within your service sidebar menu, where you'll see a list of available plugins and installed plugins(see screenshot below for reference).

Note: You have to remove other auth plugins already there in the service by inspecting the installed plugins tab. ( Look out for the default JWT Auth Provider added automatically 😉 )

After installing the plugin you have to provide settings for the plugin. You can do this by clicking the settings button next to the plugin name.
After this you can follow the instructions in the Plugin to configure your Auth0 account

To provide a summary of the steps:

Create an Auth0 account
Create an Auth0 application and API
Configure the Auth0 application
Configure the Auth0 plugin

The settings will look something like the following picture:

Then click the Save button to save the settings and commit the changes.

Some things to note:

The domain, clientId, issuerURL, and audience are required fields. These are the values you get from your Auth0 account.

The emailFieldName provided must be present in the authentication entity.

defaultUser will be used to create a default and new users.

Alternative: Automate setup of Auth0 account

If you hate having to setup everything manually, or just don't have access to the auth0 account, then you don't have to worry as I have got you covered. Introducing Auth0 Management API. Using this all the nifty work will be done for you. All you have to do is provide is a access token with necessary permisssions. You can also customise the names 🤖🚀.

For how to get the access token and the permissions required, see the Plugin Docs

After getting these you can add them to the plugin settings as shown below:

Then click the Save button to save the settings and commit the changes. This will trigger a build and the plugin will do the rest for you.

Some things to note:

If there are already actions and api with that name, the plugin will not create them again.

As you can see on this PR from our example repo, the plugin has created the actions and api for us. 🎉🎉🎉

How things work

Manual method :-

The plugin will create the following files for you as seen in this PR.

Adds the required dependencies to the package.json file.

The @auth0/auth0-spa-js and jwks-rsa help in adding the authentication and authorization to the frontend and backend respectively. While react-router-dom is used to add the routes to the frontend.

Adds the required .env variables to the .env file used in the frontend and backend.

Adds ra-auth0-provider to the Admin. This is used to setup Auth0 in the frontend. It provides the authProvider prop to the Admin component, and has requisite login, logout functions.

import { Auth0Client } from "@auth0/auth0-spa-js";
import { AuthProvider, UserIdentity } from "react-admin";

export const PreviousLocationStorageKey = "@react-admin/nextPathname";

export const client = new Auth0Client({
  domain: process.env.REACT_APP_AUTH0_DOMAIN || "",
  clientId: process.env.REACT_APP_AUTH0_CLIENT_ID || "",
  cacheLocation: "localstorage",
  authorizationParams: {
    audience: process.env.REACT_APP_AUTH0_AUDIENCE,
    scope: "openid profile email",
  },
  useRefreshTokens: true,
});

export const auth0AuthProvider: AuthProvider = {
  login: async () => {
    await client.loginWithPopup({
      authorizationParams: {
        redirect_uri: process.env.REACT_APP_AUTH0_REDIRECT_URI,
      },
    });

    return Promise.resolve();
  },

  logout: async () => {
    await client.logout({
      logoutParams: {
        returnTo: process.env.REACT_APP_AUTH0_LOGOUT_REDIRECT_URI,
      },
    });

    return Promise.resolve();
  },

  async checkAuth() {
    const isAuthenticated = await client.isAuthenticated();
    if (isAuthenticated) {
      return Promise.resolve();
    }

    localStorage.setItem(PreviousLocationStorageKey, window.location.href);

    return Promise.reject();
  },

  checkError: async ({ status }) => {
    if (status === 401 || status === 403) {
      throw new Error("Unauthorized");
    }
  },

  getPermissions: async () => {
    if (!(await client.isAuthenticated())) {
      return;
    }

    await client.getIdTokenClaims();
    Promise.resolve();
  },

  getIdentity: async () => {
    if (!(await client.isAuthenticated())) {
      throw new Error("User not authenticated");
    }

    const user = await client.getUser();

    if (!user) {
      throw new Error("User not found");
    }

    return {
      id: user.sub,
      fullName: user.name,
      avatar: user.picture,
      email: user.email,
    } as UserIdentity;
  },

  handleCallback: async () => {
    const query = window.location.search;
    if (query.includes("code=") && query.includes("state=")) {
      try {
        await client.handleRedirectCallback();
        return;
      } catch (error) {
        throw new Error("Failed to handle login callback: " + error);
      }
    }
    throw new Error("Failed to handle login callback.");
  },
};

Adds the logic to get access token in graphql provider as seen in these lines
Adds custom login page to the admin app. This is done by changing the default Login.tsx file.
Adds the JWT Base Strategy to the backend. This checks the JWT token sent in the request header and verifies it using the JWKS key provided by Auth0. This is done by adding the following code to the src/auth/jwt/base/jwt.strategy.base.ts file. And then validating it in the database using validateBase function.

import { ConfigService } from "@nestjs/config";
import { PassportStrategy } from "@nestjs/passport";
import { passportJwtSecret } from "jwks-rsa";
import { ExtractJwt, Strategy } from "passport-jwt";
import { Auth0User } from "./User";
import { UserInfo } from "../../UserInfo";
import { UserService } from "src/user/user.service";

export class JwtStrategyBase extends PassportStrategy(Strategy) {
  constructor(
    protected readonly configService: ConfigService,
    protected readonly userService: UserService
  ) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(), // Extract JWT from the Authorization header
      audience: configService.get("AUTH0_AUDIENCE"), // The resource server where the JWT is processed
      issuer: `${configService.get("AUTH0_ISSUER_URL")}`, // The issuing Auth0 server
      algorithms: ["RS256"], // Asymmetric signing algorithm

      secretOrKeyProvider: passportJwtSecret({
        cache: true,
        rateLimit: true,
        jwksRequestsPerMinute: 5,
        jwksUri: `${configService.get(
          "AUTH0_ISSUER_URL"
        )}.well-known/jwks.json`,
      }),
    });
  }

  // Validate the received JWT and construct the user object out of the decoded token.
  async validateBase(payload: { user: Auth0User }): Promise<UserInfo | null> {
    const user = await this.userService.findOne({
      where: {
        email: payload.user.email,
      },
    });

    return user ? { ...user, roles: user?.roles as string[] } : null;
  }
}

Adds the JWT stratgey code which is editable by users to the backend. This is done by adding the following code to the src/auth/jwt/jwt.strategy.ts file. And then validating it in the database using validate function.

import { Injectable } from "@nestjs/common";
import { JwtStrategyBase } from "./base/jwt.strategy.base";
import { ConfigService } from "@nestjs/config";
import { Auth0User } from "./base/User";
import { IAuthStrategy } from "../IAuthStrategy";
import { UserInfo } from "../UserInfo";
import { UserService } from "src/user/user.service";

@Injectable()
export class JwtStrategy extends JwtStrategyBase implements IAuthStrategy {
  constructor(
    protected readonly configService: ConfigService,
    protected readonly userService: UserService
  ) {
    super(configService, userService);
  }

  async validate(payload: { user: Auth0User }): Promise<UserInfo> {
    const validatedUser = await this.validateBase(payload);
    // If the entity is valid, return it
    if (validatedUser) {
      return validatedUser;
    }

    // Otherwise, make a new entity and return it
    const userFields = payload.user;
    const defaultData = {
      email: userFields.email,
      name: userFields.name,
      username: userFields.name,
      roles: ["admin"],
    };

    const newUser = await this.userService.create({
      data: defaultData,
    });

    return { ...newUser, roles: newUser?.roles as string[] };
  }
}

In this code, if a user is not found in the database then a new user is created with the default roles as admin. This can be changed by the user as per their requirements and needs.

Note :- Please make sure that the field names in the defaultData object are present in the authentication entity.
Also make sure of the role you wish to assign to the user. In this case it is admin.

Adds the User type to the src/auth/jwt/base/User.ts file. This is used to get the user data from the JWT token.

export interface Auth0User {
  nickname: string;
  username: string;
  name: string;
  email: string;
  email_verified: boolean;
  picture: string;
}

The types of the fields in this interface can be changed as per the requirements of the user and generally varies from application to application. You can find more information about the fields here. However, the email field is required as it is used to identify the user. Also, if you want some fields you may have to change the scope in the src/auth-provider/ra-auth-auth0.ts in the frontend.

Customization - Add social connections

With Auth0 you can add social connections to your application. This allows users to login to your application using their social media accounts. This allows you to provide a more personalized, secure and passwordless experience for your users. You can add social connections to your application by following the steps below:

Go to the Auth0 Social Connections page. You will see various options out there as can be seen below.
Here I am choosing GitHub however, you can choose any of the options available. The steps are nearly similar to each other.
After choosing the option, you will be redirected to the configuration page for that option. Here you can configure the connection as per your requirements. You can also add custom scopes to the connection. For more information on how to do this, see the Marketplace documentation.

Note:- Make sure to add the email scope to the connection as shown in the image. This is required to get the email of the user.

Click the Create button to create the connection. This will redirect you to the Connection setup page where you can configure on which apps you should add this.
Now, the connections should be visible in the login page of your application. You can see the login page of the example application below.

Future Work

Make the plugin more customizable by adding more options to the plugin settings. This will allow the user to customize the plugin as per their requirements. Some of the options that can be added are:

Authentication using phone number
Passwordless authentication
Two factor authentication
Adding custom roles

If you have any other suggestions, please feel free create an issue at the Auth0 plugin repo

Outro

Amplication's Auth0 Plugin provides a powerful but effortless way to add authentication to your application. It is easy to use and can be configured in a few minutes thus reducing complexity overhead.

I hope this blog post was helpful to you. If you have any questions or suggestions, please feel free to reach out to me on Twitter, GitHub or LinkedIn. I would love to hear from you.

Node.js Worker Threads Vs. Child Processes: Which one should you use?

Muly Gottlieb — Wed, 25 Oct 2023 09:00:25 +0000

Parallel processing plays a vital role in compute-heavy applications. For example, consider an application that determines if a given number is prime or not. If you're familiar with prime numbers, you'll know that you have to traverse from 1 to the square root of the number to determine if it is prime or not, and this is often time-consuming and extremely compute-heavy.

So, if you're building such compute-heavy apps on Node.js, you'll be blocking the running thread for a potentially long time. Due to Node.js's single-threaded nature, compute-heavy operations that do not involve I/O will cause the application to halt until this task is finished.

Therefore, there's a chance that you'll stay away from Node.js when building software that needs to perform such tasks. However, Node.js has introduced the concept of Worker Threads and Child Processes to help with parallel processing in your Node.js app so that you can execute specific processes in parallel. In this article, we will understand both concepts and discuss when it would be useful to employ each of them.

Node.js Worker Threads

What are worker threads in Node.js?

Node.js is capable of handling I/O operations efficiently. However, when it runs into any compute-heavy operation, it causes the primary event loop to freeze up.

Figure: The Node.js event loop

When Node.js discovers an async operation, it ״offshores״ it to the thread pool. However, when it needs to run a compute-heavy operation, it performs it on its primary thread, which causes the app to block until the operation has finished. Therefore, to mitigate this issue, Node.js introduced the concept of Worker Threads to help offload CPU-intensive operations from the primary event loop so that developers can spawn multiple threads in parallel in a non-blocking manner.

It does this by spinning up an isolated Node.js context that contains its own Node.js runtime, event loop, and event queue, which runs in a remote V8 environment. This executes in a disconnected environment from the primary event loop, allowing the primary event loop to free up.

Figure: Worker threads in Node.js

As shown above, Node.js creates independent runtimes as Worker Threads, where each thread executes independently of other threads and communicates its process statuses to the parent thread through a messaging channel. This allows the parent thread to continue performing its functions as usual (without being blocked). By doing so, you're able to achieve multi-threading in Node.js.

What are the benefits of using Worker Threads in Node.js?

As you can see, using worker threads can be very beneficial for CPU-intensive applications. In fact, it has several advantages:

Improved performance: You can offshore compute heavy operations to worker threads, and this can free up the primary thread, which lets your app be responsive to serve more requests.
Improve parallelism: If you have a large process that you would like to chunk into subtasks and execute in parallel, you can use worker threads to do so. For example, if you were determining if 1,999,3241,123 was a prime number, you could use worker threads to check for divisors in a range - (1 to 100,000 in WT1, 100,001 to 200,000 in WT2, etc). This would speed up your algorithm and would result in faster responses.

When should you use Worker Threads in Node.js?

If you think about it, you should only use Worker Threads to run compute-heavy operations in isolation from the parent thread.

It's pointless to run I/O operations in a worker thread as they are already being offshored to the event loop. So, consider using worker threads when you've got a compute-heavy operation that you need to execute in an isolated environment.

How can you build a Worker Thread in Node.js?

If all of this sounds appealing to you, let's look at how we can implement a Worker Thread in Node.js. Consider the snippet below:

const {
  Worker,
  isMainThread,
  parentPort,
  workerData,
} = require("worker_threads");

const { generatePrimes } = require("./prime");

const threads = new Set();
const number = 999999;

const breakIntoParts = (number, threadCount = 1) => {
  const parts = [];
  const chunkSize = Math.ceil(number / threadCount);

  for (let i = 0; i < number; i += chunkSize) {
    const end = Math.min(i + chunkSize, number);
    parts.push({ start: i, end });
  }

  return parts;
};

if (isMainThread) {
  const parts = breakIntoParts(number, 5);
  parts.forEach((part) => {
    threads.add(
      new Worker(__filename, {
        workerData: {
          start: part.start,
          end: part.end,
        },
      })
    );
  });

  threads.forEach((thread) => {
    thread.on("error", (err) => {
      throw err;
    });
    thread.on("exit", () => {
      threads.delete(thread);
      console.log(`Thread exiting, ${threads.size} running...`);
    });
    thread.on("message", (msg) => {
      console.log(msg);
    });
  });
} else {
  const primes = generatePrimes(workerData.start, workerData.end);
  parentPort.postMessage(
    `Primes from - ${workerData.start} to ${workerData.end}: ${primes}`
  );
}

The snippet above showcases an ideal scenario in which you can utilize worker threads. To build a worker thread, you'll need to import Worker, IsMainThread, parentPort, andworkerData from the worker_threads library. These definitions will be used to create the worker thread.

I've created an algorithm that finds all the prime numbers in a given range. It splits the range into different parts (five parts in the example above) in the main thread and then creates a Worker Thread using the new Worker() to handle each part. The worker thread executes the else block, which finds the prime numbers in the range assigned to that worker thread, and finally sends the result back to the parent (main) thread by using parentPort.postMessage().

Node.js: Child Processes

What are child processes in Node.js?

Child processes are different from worker threads. While worker threads provide an isolated event loop and V8 runtime in the same process, child processes are separate instances of the entire Node.js runtime. Each child process has its own memory space and communicates with the main process through IPC (inter-process communication) techniques like message streaming or piping (or files, Database, TCP/UDP, etc.).

What are the benefits of using Child Processes in Node.js?

Using child processes in your Node.js applications brings about a lot of benefits:

Improved isolation: Each child process runs in its own memory space, providing isolation from the main process. This is advantageous for tasks that may have resource conflicts or dependencies that need to be separated.
Improved scalability: Child processes distribute tasks among multiple processes, which lets you take advantage of multi-core systems and handle more concurrent requests.
Improved robustness: If the child process crashes for some reason, it will not crash your main process along with it.
Running external programs: Child processes let you run external programs or scripts as separate processes. This is useful for scenarios where you need to interact with other executables.

When should you use Child Processes in Node.js?

So, now you know the benefits child processes bring to the picture. It's important to understand when you should use child processes in Node.js. Based on my experience, I'd recommend using a child process when you want to execute an external program in Node.js.

My recent experience included a scenario where I had to run an external executable from within my Node.js service. It isn't possible to execute a binary inside the primary thread. So, I had to use a child process in which I executed the binary.

How can you build Child Processes in Node.js?

Well, now the fun part. How do you build a child process? There are several ways to create a child process in Node.js (using methods like spawn(), fork(), exec(), and execFile()) and as always, reading the docs is advisable to get the full picture, but the simplest case of creating child processes is as simple as the script shown below:

const { spawn } = require('child_process');
const child = spawn('node', ['child.js']);

child.stdout.on('data', (data) => {
  console.log(`Child process stdout: ${data}`);
});

child.on('close', (code) => {
  console.log(`Child process exited with code ${code}`);
});

All you have to do is import a spawn() method from the child_process module and then call the method by passing a CLI argument as the parameter. So in our example, we're running a file named child.js.

The file execution logs are printed through the event streaming stdout while the close handler handles the process termination.

Of course, this is a very minimal and contrived example of using child processes, but it is brought here just to illustrate the concept.

How to select between worker threads and child processes?

Well, now that you know what child processes and worker threads are, it's important to know when to use either of these techniques. Neither of them is a silver bullet that fits all cases. Both approaches work well for specific conditions.

Use worker threads when:

You're running CPU-intensive tasks. If your tasks are CPU-intensive, worker threads are a good choice.
Your tasks require shared memory and efficient communication between threads. Worker threads have built-in support for shared memory and a messaging system for communication.

Use child processes when:

You're running tasks that need to be isolated and run independently, especially if they involve external programs or scripts. Each child process runs in its own memory space.
You need to communicate between processes using IPC mechanisms, such as standard input/output streams, messaging, or events. Child processes are well-suited for this purpose.

Wrapping up

Parallel processing is becoming a vital aspect of modern system design, especially when building applications that deal with very large datasets or compute-intensive tasks. Therefore, it's important to consider Worker Threads and Child Processes when building such apps with Node.js.

If your system is not designed properly with the right parallel processing technique, your system could perform poorly by over-exhausting resources (as spawning these resources consumes a lot of resources as well).

Therefore, it's important for software engineers and architects to verify requirements clearly and select the right tool based on the information presented in this article.

Additionally, you can use tools like Amplication to bootstrap your Node.js applications easily and focus on these parallel processing techniques instead of wasting time on (re)building all the boilerplate code for your Node.js services.

Top 6 ORMs for Modern Node.js App Development

Muly Gottlieb — Wed, 11 Oct 2023 07:22:44 +0000

In modern web development, one can confidently predict that constructing robust and efficient Node.js applications frequently necessitates database interaction. A pivotal challenge in databases-driven applications lies in managing the interplay between the application code and the database.

This is precisely where Object-Relational Mapping (ORM) libraries assume a crucial role.

What is an ORM?

ORMs serve as tools that bridge the divide between the object-oriented nature of application code and the relational structure of databases. They streamline database operations, enhance code organization, and boost developer productivity. In this article, I will delve into the significance of ORMs in Node.js app development and examine the top six ORM tools you can employ to enhance your development workflow.

Importance of ORMs in Node.js App Development

ORMs bridge the gap between the object-oriented programming world and relational databases, making it easier for developers to interact with databases using JavaScript. Here are five key benefits of using ORMs in Node.js app development:

Abstraction of Database Operations: ORMs provide a higher-level abstraction, allowing developers to work with JavaScript objects and classes rather than writing complex SQL queries. This abstraction simplifies database operations, making code more readable and maintainable.
Database Agnosticism: ORMs are often database-agnostic, which supports multiple database systems. This flexibility allows developers to switch between databases (e.g., MySQL, PostgreSQL, SQLite) without major code changes, making it easier to adapt to evolving project requirements.
Code Reusability: ORMs encourage code reusability by providing a consistent API for database interactions. Developers can create generic database access codes that can be reused across different application parts, reducing duplication and minimizing the chances of errors.
Security: ORMs help mitigate common security vulnerabilities, such as SQL injection attacks, by automatically sanitizing and parameterizing SQL queries. This helps in building more secure applications by default.
Rapid Development: ORMs accelerate development by simplifying database setup and management. Developers can focus on application logic rather than excessive time on database-related tasks.

Let's explore the top six ORM tools for modern Node.js app development.

Top 6 ORM tools for modern Node.js app development

1. Sequelize

Sequelize is an extensively employed ORM for Node.js. It supports relational databases, such as MySQL, PostgreSQL, SQLite, and MSSQL. Sequelize boasts a comprehensive array of features for database modeling and querying. It caters to various coding styles by accommodating both Promise and Callback-based APIs. Moreover, it encompasses advanced functionalities such as transactions, migrations, and associations, making it well-suited for intricate database operations.

Pros

Excellent documentation and a large community.
Support for multiple database systems.
Strong support for migrations and schema changes.
Comprehensive query builder.

Cons

It can have a steep learning curve for beginners.
Some users find the API complex and lengthy.

Best for: Sequelize is a good choice when working with projects that require support for multiple database systems and complex relationships between data models.

2. TypeORM

TypeORM places its focus on TypeScript and JavaScript (ES7+) development. It offers compatibility with various database systems, including MySQL, PostgreSQL, SQLite, and MongoDB. What sets TypeORM apart is its robust integration with TypeScript. It provides a user-friendly experience with a convenient decorator-based syntax for defining entities and relationships. Additionally, TypeORM supports the repository pattern and enables eager loading, enhancing its versatility for developers.

Pros:

Strong TypeScript support with type checking.
Intuitive decorator-based syntax.
Support for migrations and schema generation.
Active development with frequent updates.

Cons

Limited support for NoSQL databases.
It may not be as performant as some other ORMs.
Support and maintenance of the project are not always as expected.

Best for: TypeORM is an excellent choice for projects prioritizing TypeScript and prefers a developer-friendly, decorator-based syntax for defining data models.

3. Prisma

Prisma is a contemporary database toolkit and ORM, seamlessly compatible with TypeScript, JavaScript, and multiple databases, such as PostgreSQL, MySQL, SQLite, MongoDB, and SQL Server. Prisma's primary focus is ensuring type-safe database access, featuring an auto-generated, robust query builder. Prisma excels in prioritizing type safety and modern tooling, producing a strongly typed database client that effectively minimizes runtime errors associated with database queries.

Pros

Excellent TypeScript integration with generated types.
Powerful query builder with auto-completion.
Efficient database migrations.
Schema-first design approach.
Strong support, community, and maintenance and a growing ecosystem.

Cons

Limited support for NoSQL databases.
Relatively newer in the ORM ecosystem.

Best for: Prisma is an ideal choice for projects that prioritize type safety, modern tooling, and efficient database queries, especially when working with TypeScript.

4. Objection.js

Objection.js is a SQL-friendly ORM for Node.js that supports various relational databases, including PostgreSQL, MySQL, and SQLite. It provides a flexible and expressive query builder. Objection.js is known for its expressive syntax, allowing developers to build complex queries easily. It supports eager loading, transactions, and migrations.

Pros

Expressive query builder.
Support for complex data relationships.
Excellent documentation.
Active development and community support.

Cons

Limited support for NoSQL databases.
It may require a steep learning curve for beginners.

Best for: Objection.js is a good choice for developers who prefer an expressive query builder and need to work with SQL databases in their Node.js projects.

5. Bookshelf.js

Bookshelf.js is an uncomplicated and lightweight ORM designed for Node.js, constructed atop the Knex.js query builder. Its primary aim is to support SQL databases, such as PostgreSQL, MySQL, and SQLite. Bookshelf.js focuses on simplicity and user-friendliness, offering a direct method for defining models and relationships through JavaScript classes and prototypal inheritance.

Pros

It is lightweight and easy to get started with.
Suitable for smaller projects with basic database needs.

Cons

Limited advanced features compared to other ORMs.
It may not be ideal for large and complex applications.

Best for: Bookshelf.js is a good choice for small to medium-sized projects with simple database requirements and developers who prefer a minimalistic approach.

6. Mikro-ORM

Mikro-ORM is a TypeScript ORM that focuses on simplicity and efficiency. It supports various SQL databases and MongoDB. Mikro-ORM is known for its simplicity and developer-friendly APIs. It provides a concise syntax for defining data models and relationships, making it easy to use.

Pros

TypeScript support with solid typing.
Supports SQL and NoSQL databases.
Automatic migrations and schema updates.
Focus on performance and efficiency.

Cons

Smaller community compared to some other ORMs.
It may not have all the advanced features of larger ORMs.

Best for: Mikro-ORM is an excellent choice for developers who value simplicity and efficiency, especially when working with TypeScript and multiple database types.

What's the best ORM for Node.js microservices?

My short (subjective) answer, is Prisma.

Prisma presents a type-safe and user-friendly approach to database interaction, simplifying intricate database tasks and diminishing the likelihood of runtime errors. It is compatible with various databases, including PostgreSQL, MySQL, MongoDB, and MS SQL Server, making it adaptable to diverse project requirements. The maintenance and support of the project are top-notch, assuring that bugs are quickly addressed and new features roll out on a competitive cadence.

In addition, Prisma is supported by microservice code generation tools like Amplication. Prisma plugs directly into the code generated by Amplication. By doing so, you can utilize Prisma as an ORM layer for your databases and generate microservice code with ease in just a few clicks.

Conclusion

Selecting the right ORM for your Node.js project is an important decision.

The ORMs discussed in this article each bring unique strengths and weaknesses tailored for diverse scenarios. When making your choice, consider critical factors such as type safety, database compatibility, developer-friendliness, community and support, level of maintenance, and the specific demands of your project.

In a nutshell, ORMs offer many invaluable advantages in modern Node.js app development, including the abstraction of database operations, database agnosticism, code reusability, heightened security, and accelerated growth.

By assessing and opting for the ORM that aligns with your requirements, you can streamline database interactions and craft efficient, sustainable applications poised for success. Your choice of ORM will likely stay with your project for a long time and will impact your project's success, so choose wisely and embark on your journey to a brighter development future.

Celebrating Hacktoberfest 2023 with Amplication

Saurav Jain — Wed, 04 Oct 2023 07:18:50 +0000

A quick look back

Hello everyone! I'm Saurav Jain, your Community Manager at Amplication. In 2018, took my first step into the dynamic world of Hacktoberfest, and since then, I haven't looked back. As the Community Manager at Amplication, my involvement with Hacktoberfest reached a crescendo last year when I was given the incredible opportunity to organize a major campaign for our organization. The response was overwhelming. We received a lot of contributions from every corner of the globe. The diversity and volume of input were amazing, from code adjustments to non-code contributions, bug fixes, feature requests, and even documentation and tutorials. Reflecting on last year, the passion and dedication displayed by developers worldwide is what fuels my enthusiasm for Hacktoberfest. It's heartwarming to see so many individuals dedicate their time and skills to the betterment of the open-source community.

Amplication: A proud sponsor of Hacktoberfest 2023

Guess what's even more exciting? This year, we're not only participating, we're sponsoring Hacktoberfest 2023 on its 10th anniversary! With bigger responsibilities come even bigger plans; trust me, we've got some fascinating stuff in store.

What's on the agenda?

We've prepped dozens of issues spanning various domains like bug fixes, UI/UX improvements, documentation enhancements, and more.

Regardless of whether you're a beginner or a seasoned developer, there's something for you. Here are the repositories we're mainly focusing on:

You can even suggest new issues. Just make sure to get them verified by our team before diving in.

Beyond code: Diverse contributions

Coding isn't the only way to contribute. We believe that open source is for everyone. That's why we're introducing a wide array of non-code contributions. These include crafting product use cases, creating Amplication tutorials, making instructional videos like 'How to do XYZ using Amplication,' and conducting user interviews.

The icing on the cake: Rewards!

Who doesn't love rewards, right? Contribute to one issue and grab some exclusive Amplication stickers. Solve three, and you'll be the proud owner of an Amplication T-shirt. And for those who are up for a real challenge, we have 10+ Premium Issues lined up, each coming along with special prizes ranging up to $500 worth of gift cards.

Premium Issues:

We invite experienced developers who are willing to take a challenge and build something that can help thousands of developers.

We put together 10+ premium issues, including new development for our robust plugin system. Each issue in the category is associated with a gift card worth up to $500 that you can claim, or you can choose to donate the similar amount to an open-source project of your choice.

If you are qualified and have knowledge for the task, please select the plugin you want to work on and feel free to share any background information associated with the skillset.
Once the issue is assigned to you, we will invite you to a private discord channel where you can talk with our team members, ask for help, and share your progress on the task.

To ensure continuous work on the issue and prevent delays for other community members (so you guys won’t have to wait for issues), if there's no activity for three days, the issue may be reassigned to another community member.

How to get started?

So, how do you dive in? It's simple:

Visit our GitHub repo and look for an issue that interests you.
Drop a comment asking us to assign it to you.
Once assigned, get cracking!

Read the guidelines here: https://github.com/amplication/amplication/issues/7026

Don’t wait- join the parade!

Getting involved is simple. Our Discord server is the place to be. Oh, and don't forget, our Hacktoberfest kickoff event is on October 5th, live on our YouTube channel.

Date: Oct 5th, 2023
Time: 5 PM CEST

I'm buzzing with excitement, and I hope you are, too. Let's make Hacktoberfest 2023 legendary!

Distributed Tracing and OpenTelemetry Guide

Daniele Iasella — Fri, 29 Sep 2023 06:26:07 +0000

Microservices have become popular for modern web applications since they provide many benefits over traditional monolithic architectures. However, microservices are not a silver bullet; they also have a fair share of challenges. For example, debugging and troubleshooting errors in microservices can be challenging since tracking the request flow across multiple services is difficult.

That's where distributed tracing and OpenTelemetry come in. OpenTelemetry is an Observability framework designed to create and manage telemetry data like traces, metrics, and logs from distributed systems. So, in this article, I will take you through the steps of using OpenTelemetry within a Node.js ecosystem to trace your microservices applications effectively.

What is distributed tracing

The complexity of microservices makes it difficult to track the request path through multiple microservices. Distributed tracing is an observability technique used to track these requests across microservices. In other words, we can define it as a flashlight that helps you understand the request flow across your system.

Distributed tracing is beneficial for developers in many scenarios. For example, there can be a single microservice with a slow response time, slowing down the whole application. Tracing data lets you pinpoint the exact origin and easily troubleshoot the issue.

Benefits of using distributed tracing:

Identify performance bottlenecks.
Provides a comprehensive view of the system.
Provides insights into the dependencies between different services.
Identify potential security vulnerabilities.
Support both synchronous (gRPC, REST, GraphQL) and asynchronous (event sourcing, pub-sub) application architectures.

Components of distributed tracing?

A typical distributed tracing system is built up with the below components:

Trace: End-to-end path of a single user request as it moves through various services.
Span: A single operation or unit of work within a distributed system. It captures information like start time, end time, metadata, or annotation that might be useful to understand what is happening.
Context Propagation: Passing contextual information between different services within a distributed system. It is essential for connecting spans to construct a complete trace of a request.

Since you now have a brief idea of what distributed tracing is, let's see how to implement distributed tracing with Node.js.

Instrumenting Node.js app with OpenTelemetry

In this example, I will create 3 Node.js services (shipping, notification, and courier) using Amplication, add traces to all services, and show how to analyze trace data using Jaeger.

Step 1: Generating services using Amplication

As the first step, you must create the Node.js services with Amplication. In this example, I will be using three already created Prisma schemas. You can find those schemas in this GitHub repository.

Once you are ready with schemas, go to the Amplication dashboard and create a new Project.

Then, select the project from the dashboard and connect the GitHub repository with Prisma schemas to that project.

Now, you can start creating services. For that, return to the Amplication dashboard and click the Add Resources button.

Then, enter the necessary information to make the service. In this case, I have named the services as "courier gateway service" with the below settings:

Git Repository: I've used the GitHub repo, which I connected earlier.

REST or GraphQL: I've enabled both options to show the file structure generated by Amplication.

Repo type: Monorepo.

Database: PostgreSQL

Authentication: Included

It will take a few seconds to generate the service.

After that, you need to modify a few database settings to avoid collision between databases when sharing the same Docker service. For that, navigate to the Plugins tab, select the PostgreSQL DB plugin, and click the Settings button.

There, you will see a JSON file like below, and you need to update the dbName property. Here, I have renamed it to courier.

Then, go back to the Entities tab and import the courier Prisma schema to generate the entities related to the courier service.

Once the schema is imported, you will see 2 new entities named Parcel and Quote in the Entities tab.

Now, perform the same steps again for the other two services.

Step 2: Adding a Kafka integration

In this example, I will use a Message Broker to communicate between these services. You can easily generate a Message Broker through Amplication by clicking the Add Resource button and selecting the Message Broker option.

Then, go back to the shipping service and install the Kafka plugin to allow the shipping service to use the Message Broker.

Then, go to the Connections tab and select the Message pattern as Send to allow the shipping service to send messages.

Similarly, go to the notification service and select Message pattern as Receive to subscribe to the Message Broker.

Step 3: Building the application

Click the Commit change & build button to finalize the changes. It will start the build process, generate the new files in the Git repo, and create a pull request.

Note: Make sure to merge the pull request to the main branch to get the latest updates.

Step 4: Configuring Docker compose

Each service generated by Amplication contains a separate Docker compose file. But, in this example, I want to share the same database with all services. Hence, I created a new Docker compose file by coping the content of the docker-compose files generated by amplication.



version: "3"
name: otel-workshop
services:
  # Shared DB for all services
  db:
    image: postgres:12
    ports:
      - 5432:5432
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: admin
    volumes:
      - postgres:/var/lib/postgresql/data

  # Jaeger
  jaeger-all-in-one:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686"
      - "14268"
      - "14250"
  # Collector
  collector-gateway:
    image: otel/opentelemetry-collector:latest
    volumes:
      - ./collector-gateway.yml:/etc/collector-gateway.yaml
    command: ["--config=/etc/collector-gateway.yaml"]
    ports:
      - "1888:1888" # pprof extension
      - "13133:13133" # health_check extension
      - "4317:4317" # OTLP gRPC receiver
      - "4318:4318" # OTLP HTTP receiver
      - "55670:55679" # zpages extension
    depends_on:
      - jaeger-all-in-one

  kafka-ui:
    container_name: kafka-ui
    image: provectuslabs/kafka-ui:latest
    ports:
      - "8080:8080"
    depends_on:
      - zookeeper
      - kafka
    environment:
      KAFKA_CLUSTERS_0_NAME: local
      KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka:29092
      KAFKA_CLUSTERS_0_ZOOKEEPER: zookeeper:2181
      KAFKA_CLUSTERS_0_JMXPORT: 9997

  zookeeper:
    image: confluentinc/cp-zookeeper:7.3.1
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - "2181:2181"

  kafka:
    image: confluentinc/cp-kafka:7.3.1
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
      - "9997:9997"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:29092,PLAINTEXT_HOST://localhost:9092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_MESSAGE_MAX_BYTES: 10485760
      JMX_PORT: 9997
      KAFKA_JMX_OPTS: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=kafka -Dcom.sun.management.jmxremote.rmi.port=9997
    healthcheck:
      test: nc -z localhost 9092 || exit -1
      start_period: 15s
      interval: 30s
      timeout: 10s
      retries: 10

volumes:
  postgres: ~

I don't need to specify a collector getaway in the above configuration since I'm using jaeger-all-in-one. However, I have specified a collector getaway to highlight the receiver's components and ports.

Run docker-compose up --detach command to start Docker.

Step 5: Configuring services for local development

Now, you need to set up all 3 services for local development. For that, you just need to follow the instructions given in the README.md file.

Note:: You don't need to run `_npm run docker:dev` command since Docker is already running_

Once all the databases are initialized and dependencies are installed, start each service using npm run start:watch command and the courier-gateway-service-admin using npm run start command.

Note: You need to update the ports of each service from the _.env_ files to avoid clashes between the services.

Step 6: Creating a Parcel through admin view

You can easily create a new Parcel by logging into the admin view.

Step 7: Connecting the services

First, navigate to the shipping service and install axios using npm install axios command. Then, add the below code to the shipping-service/src/shipment/shipment.service.ts file to get parcel details.



import { Injectable } from "@nestjs/common";
import { PrismaService } from "../prisma/prisma.service";
import { ShipmentServiceBase } from "./base/shipment.service.base";
import { Prisma, Shipment } from "@prisma/client";
import axios from "axios";
import { KafkaProducerService } from "../kafka/kafka.producer.service";
import { ShippingEvent } from "./shipping.event";
import { MyMessageBrokerTopics } from "../kafka/topics";

@Injectable()
export class ShipmentService extends ShipmentServiceBase {
  constructor(
    protected readonly prisma: PrismaService,
    private readonly kafkaProducerService: KafkaProducerService
  ) {
    super(prisma);
  }

  async create<T extends Prisma.ShipmentCreateArgs>(
    args: Prisma.SelectSubset<T, Prisma.ShipmentCreateArgs>
  ): Promise<Shipment> {
    const {
      data: { accessToken },
    } = await axios.post(http://localhost:3002/api/login , {
      username: "admin",
      password: "admin",
    });

    const { data: parcels } = await axios.get(
      http://localhost:3002/api/parcels ,
      {
        params: {},
        headers: {
          Authorization: Bearer ${accessToken} ,
        },
      }
    );

    const randomParcel = Math.floor(Math.random() * parcels.length);

    const shipment = await super.create<T>({
      ...args,
      data: {
        ...args.data,
        price: parcels[randomParcel].price,
      },
    });

    const event: ShippingEvent = {
      Message: Shipment id: ${shipment.id} ,
      CustomerId: "1b2c",
    };

    await this.kafkaProducerService.emitMessage(
      MyMessageBrokerTopics.ShipmentCreateV1,
      {
        key: shipment.id,
        value: event,
      }
    );

    return shipment;
  }
}

Step 8: Creating a client app

Before starting instrumenting, let's create a client application to get shipment data. This can be a simple Node.js project with a main.js file containing the code to fetch shipment data.



// main.js

"use strict";
const axios = require("axios");

const url = "http://localhost:3004/api/shipments";
const numberOfRequests = 5;

const makeRequest = async (requestId) => {
  const result = await axios.post(url);
  return result;
};

const main = async () => {
  for (let i = 0; i < numberOfRequests; i++) {
    const res = await makeRequest(i);
    console.log("Response", res.data);
  }
};

main();

Step 9: Adding tracing

Create a new file named tracing.js in the same directory where you created the main.js file to fetch shipment data. Then, install all the OpenTelemetry dependencies using the below command:



ls
npm install @opentelemetry/sdk-node \
  @opentelemetry/api \
  @opentelemetry/resources\
  @opentelemetry/semantic-conventions \
  @opentelemetry/instrumentation-http

Add the below code to the tracing.js file.



const {
  BasicTracerProvider,
  SimpleSpanProcessor,
} = require("@opentelemetry/sdk-trace-base");
const { Resource } = require("@opentelemetry/resources");
const {
  SemanticResourceAttributes,
} = require("@opentelemetry/semantic-conventions");
const { trace } = require("@opentelemetry/api");
const {
  OTLPTraceExporter,
} = require("@opentelemetry/exporter-trace-otlp-http");
const { NodeSDK } = require("@opentelemetry/sdk-node");
const { HttpInstrumentation } = require("@opentelemetry/instrumentation-http");
const { B3Propagator } = require("@opentelemetry/propagator-b3");

const exporter = new OTLPTraceExporter({});

const getTracer = () => {
  return trace.getTracer("default");
};

const sdk = new NodeSDK({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: "fake-client-app",
    [SemanticResourceAttributes.SERVICE_VERSION]: "0.1.0",
  }),
  spanProcessor: new SimpleSpanProcessor(exporter),
  traceExporter: exporter,
  instrumentations: [new HttpInstrumentation()],
  textMapPropagator: new B3Propagator(),
});

sdk.start();

module.exports = { getTracer };

To start tracing, you need to import the above file to the main.js file and do some modifications. The updated main.js file will look like below:



js
"use strict";
const { getTracer } = require("./tracing");
const axios = require("axios");
const { trace } = require("@opentelemetry/api");

const tracer = getTracer("fake-client");

const url = "http://localhost:3004/api/shipments";
const numberOfRequests = 1;

const makeRequest = async (requestId) => {
  return tracer.startActiveSpan("makeRequests", async (span) => {
    span.updateName(makeRequests-${requestId} );
    const result = await axios.post(url);
    span.end();
    return result;
  });
};

tracer.startActiveSpan("main", async (span) => {
  for (let i = 0; i < numberOfRequests; i++) {
    const res = await makeRequest(i);
    console.log("Response", res.data);
  }
  span.end();
});

Now, you can run the client application with the node main.js command and monitor the trace data with Jeager.

That's it. You successfully created a Node. js-based microservices application using Amplication, configuring tracing, and monitoring trace data through Jeager. You can find the complete code example in GitHub and watch the video below to understand the code used for tracing.

Step 10: Adding tracing to the generated services

As Amplication now supports OpenTelemetry through a plugin, we will leverage the plugin to integrate all the services without much effort.

Go to each service starting from the shipping service and install the OpenTelemetry plugin.

Click the Commit change & build button to finalize the changes. It will start the build process again, generate the new files and update existing ones in the Git repo, and create/update a pull request.

Now try to perform new requests as before and observe the tracing data in Jaeger!

Watch Webinar

I took a live workshop few weeks ago on Distributed Tracing and Open Telemetry. You can watch it here: https://www.youtube.com/watch?v=Pu-HiD2QksI

Best practices to follow

Prioritize critical paths and high-impact services.
Use consistent and meaningful naming conventions for spans, and services.
Ensure that trace context is propagated across service boundaries. This typically involves adding trace headers to HTTP requests or message headers.
Use tags and annotations to add additional metadata to spans.
Implement adaptive sampling strategies that adjust the sampling rate based on the service's load, and error rates.
Automatically capture and log errors.
Retain trace data for an appropriate period.

Conclusion

This guide provided an overview of implementing tracing for Node.js-based microservices applications. As you can see, enabling tracing for your application requires little effort. But it can save you a whole lot of troubleshooting and debugging time. Thank you for reading.

The Complete Microservices Guide

Muly Gottlieb — Thu, 21 Sep 2023 08:53:59 +0000

Introduction to Microservices

Why Microservices?

Microservices have emerged as a popular architectural approach for designing and building software systems for several compelling reasons and advantages. It is a design approach that involves dividing applications into multiple distinct and independent services called "microservices," which offers several benefits, including the autonomy of each service, making it easier to maintain and test in isolation over monolithic architecture.

Figure 1: A sample microservice-based architecture

Figure 1 depicts a simple microservice-based architecture showcasing the services' independent, isolated nature. Each particular entity belonging to the application is isolated into its service. For example, the UserService, OrderService, and NotificationService focus on dealing with different parts of the business.

The overall system is split into services that are driven by independent teams that use their own tech stacks and are even scaled independently.

In a nutshell, each service handles its specific business domain. Therefore, the question arises - "How do you split an application into microservices?". Well, this is where microservices meet Domain Driven Design (DDD).

What is Domain-Driven Design?

Domain-Driven Design (DDD) is an approach to software development that emphasizes modeling software based on the domain it serves.

It involves understanding and modeling the domain or problem space of the application, fostering close collaboration between domain experts and software developers. This collaboration creates a shared understanding of the domain and ensures the developed software aligns closely with its intricacies.

This means microservices are not only about picking a tech stack for your app. Before you build your app, you'll have to understand the domain you are working with. This will let you know the unique business processes being executed in your organization, thus making it easy to split up the application into tiny microservices.

Doing so creates a distributed architecture where your services no longer have to be deployed together to a single target but instead are deployed separately and can be deployed to multiple targets.

What are Distributed Services?

Distributed services refer to a software architecture and design approach where various application components, modules, or functions are distributed across multiple machines or nodes within a network.

Modern computing commonly uses this approach to improve scalability, availability, and fault tolerance. As shown in Figure 1, microservices are naturally distributed services as each service is isolated from the others and runs in its own instance.

What is a Microservices Architecture?

Microservices and Infrastructure

Microservices architecture places a significant focus on infrastructure, as the way microservices are deployed and managed directly impacts the effectiveness and scalability of the system.

There are several ways in which microservices architecture addresses infrastructure considerations.

Containerization: Microservices are often packaged as containers, like Docker, that encapsulate an application and its dependencies, ensuring consistency between development, testing, and production environments. Containerization simplifies deployment and makes it easier to manage infrastructure resources.
Orchestration: Microservices are typically deployed and managed using container orchestration platforms like Kubernetes. Kubernetes automates the deployment, scaling, and management of containerized applications. It ensures that microservices are distributed across infrastructure nodes efficiently and can recover from failures.
Service Discovery: Microservices need to discover and communicate with each other dynamically. Service discovery tools like etcd, Consul, or Kubernetes built-in service discovery mechanisms help locate and connect to microservices running on different nodes within the infrastructure.
Scalability: Microservices architecture emphasizes horizontal scaling, where additional microservice instances can be added as needed to handle increased workloads. Infrastructure must support the dynamic allocation and scaling of resources based on demand.

How to build a microservice?

The first step in building a microservice is breaking down an application into a set of services. Breaking a monolithic application into microservices involves a process of decomposition where you identify discrete functionalities within the monolith and refactor them into separate, independent microservices.

This process requires careful planning and consideration of various factors, as discussed below.

Analyze the Monolith: Understand the existing monolithic application thoroughly, including its architecture, dependencies, and functionality.
Identify Business Capabilities: Determine the monolith's distinct business capabilities or functionalities. These could be features, modules, or services that can be separated logically.
Define Service Boundaries: Establish clear boundaries for each microservice. Identify what each microservice will be responsible for and ensure that these responsibilities are cohesive and well-defined.
Data Decoupling: Examine data dependencies and decide how data will be shared between microservices. You may need to introduce data replication, data synchronization, and separate databases for each microservice.
Communication Protocols: Define communication protocols and APIs between microservices. RESTful APIs, gRPC, or message queues are commonly used for inter-service communication.
Separate Codebases: Create different codebases for each microservice. This may involve extracting relevant code and functionality from the monolith into individual repositories or as packages in a monorepo strategy.
Decompose the Database: If the monolithic application relies on a single database, you may need to split the database into smaller databases or schema within a database for each microservice.
Implement Service Logic: Develop the business logic for each microservice. Ensure that each microservice can function independently and handle its specific responsibilities.
Integration and Testing: Create thorough integration tests to ensure that the microservices can communicate and work together as expected. Use continuous integration (CI) and automated testing to maintain code quality.
Documentation: Maintain comprehensive documentation for each microservice, including API documentation and usage guidelines for developers who will interact with the services.

After you've broken down your services, it's important to establish correct standards for how your microservices will communicate.

How do microservices communicate with each other?

Communication across services is an important aspect to consider when building microservices. So, whichever approach you adopt, it's essential to ensure that such communication is made to be efficient and robust.

There are two main categories of microservices-based communication:

Inter-service communication
Intra-service communication

Inter-Service Communication

Inter-service communication in microservices refers to how individual microservices communicate and interact within a microservices architecture.

Microservices can employ two fundamental messaging approaches to interact with other microservices in inter-service communication.

Synchronous Communication

One approach to adopting inter-service communication is through synchronous communication. Synchronous communication is an approach where a service invokes another service through protocols like HTTP or gRPC and waits until the service responds with a response.

Source: https://www.theserverside.com/answer/Synchronous-vs-asynchronous-microservices-communication-patterns

Asynchronous Message Passing

The second approach is through asynchronous message passing. Over here, a service dispatches a message without waiting for an immediate response.

Subsequently, asynchronously, one or more services process the message at their own pace.

Source: https://www.theserverside.com/answer/Synchronous-vs-asynchronous-microservices-communication-patterns

Intra-Service Communication

Intra-service communication in microservices refers to the interactions and communication within a single microservice, encompassing the various components, modules, and layers that make up that microservice.

Simply put - unlike inter-service communication, which involves communication between different microservices, intra-service communication focuses on the internal workings of a single microservice.

But, with either approach you adopt, you have to make sure that you create the perfect balance of communication to ensure that you don't have excessive communication happening in your microservices. If so, this could lead to "chatty" microservices.

What is chattiness in microservices communication?

"Chattiness" refers to a situation where there is excessive or frequent communication between microservices.

It implies that microservices are making many network requests or API calls to each other, which can have several implications and challenges, such as performance overhead, increased complexity, scalability issues, and network traffic.

Figure: A chatty microservice

As shown above, the UserService has excessive communication with the OrderService and itself, which could lead to performance and scaling challenges as there are excessive network calls.

What is the usage of middleware in microservices?

Middleware plays a crucial role in microservices architecture by providing services, tools, and components that facilitate communication, integration, and management of microservices. Let's discuss a few of the usages.

Inter-Service Communication: Middleware provides communication channels and protocols that enable microservices to communicate with each other. This can include message brokers like RabbitMQ, Apache Kafka, RPC frameworks like gRPC, or RESTful APIs.
Service Discovery: Service discovery middleware helps microservices locate and connect to other microservices dynamically, especially in dynamic or containerized environments. Tools like Consul, etcd, or Kubernetes service discovery features aid in this process.
API Gateway: An API gateway is a middleware component that serves as an entry point for external clients to access microservices. It can handle authentication, authorization, request routing, and aggregation of responses from multiple microservices.
Security and Authentication: Middleware components often provide security features like authentication, authorization, and encryption to ensure secure communication between microservices. Tools like OAuth2, JWT, and API security gateways are used to enhance security.
Distributed Tracing: Middleware for distributed tracing like Jaeger and Zipkin helps monitor and trace requests as they flow through multiple microservices, aiding in debugging, performance optimization, and understanding the system's behavior.
Monitoring and Logging: Middleware often includes monitoring and logging components like ELK Stack, Prometheus, and Grafana to track the health, performance, and behavior of microservices. This aids in troubleshooting and performance optimization.

Building Microservices with Node.js

Building microservices with Node.js has become a popular choice due to Node.js's non-blocking, event-driven architecture and extensive ecosystem of libraries and frameworks.

If you want to build Microservices with Node.js, there is a way to significantly accelerate this process by using Amplication.

Amplication is a free and open-source tool designed for backend development. It expedites the creation of Node.js applications by automatically generating fully functional apps with all the boilerplate code - just add in your own business logic. It simplifies your development workflow and enhances productivity, allowing you to concentrate on your primary goal: crafting outstanding applications. Learn More here.

Understanding the basics of REST API

REST (Representational State Transfer) is an architectural style for designing networked applications. REST APIs (Application Programming Interfaces) are a way to expose the functionality of a system or service to other applications through HTTP requests.

How to create a REST API endpoint?

There are many ways we can develop REST APIs. Here, we are using Amplication. It can be done with just a few clicks.

The screenshots below can be used to walk through the flow of creating REST APIs.

Click on "Add New Project"

Give your new project a descriptive name

Click "Add Resource" and select "Service"

Name your service

5. Connect to a git repository where Amplication will create a PR with your generated code

6. Select the options you want to generate for your service. In particular, which endpoints to generate - REST and/or GraphQL

7. Choose your microservices repository pattern - monorepo or polyrepo.

8. Select which database you want for your service

9. Choose if you want to manually create a data model or start from a template (you can also import your existing DB Schema later on)

10. You can select or skip adding authentication for your service.

11. Yay! We are done with our service creation using REST APIs.

12. Next, you will be redirected to the following screen showing you the details and controls for your new service

13. After you click "Commit Changes & Build", a Pull-Request is created in your repository, and you can now see the code that Amplication generated for you:

How can you connect a frontend with a microservice?

Connecting the frontend with the service layer involves making HTTP requests to the API endpoints exposed by the service layer. Those API endpoints will usually be RESTful or GraphQL endpoints.

This allows the frontend to interact with and retrieve data from the backend service.

The BFF (Backend For Frontend) pattern is an architectural design pattern used to develop microservices-based applications, particularly those with diverse client interfaces such as web, mobile, and other devices. The BFF pattern involves creating a separate backend service for each frontend application or client type.

Consider the user-facing application as consisting of two components: a client-side application located outside your system's boundaries and a server-side component known as the BFF (Backend For Frontend) within your system's boundaries. The BFF is a variation of the API Gateway pattern but adds an extra layer between microservices and each client type. Instead of a single entry point, it introduces multiple gateways.

This approach enables you to create custom APIs tailored to the specific requirements of each client type, like mobile, web, desktop, voice assistant, etc. It eliminates the need to consolidate everything in a single location. Moreover, it keeps your backend services "clean" from specific API concerns that are client-type-specific: Your backend services can serve "pure" domain-driven APIs, and all the client-specific translations are located in the BFF(s). The diagram below illustrates this concept.

Source: https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0

Microservices + Security

Security is a crucial aspect when building microservices. Only authorized users must have access to your APIs. So, how can you secure your microservices?

Choose an Authentication Mechanism

Secure your microservices through token-based authentication (JWT or OAuth 2.0), API keys, or session-based authentication, depending on your application's requirements.

Centralized Authentication Service

Consider using a centralized authentication service if you have multiple microservices. This allows users to authenticate once and obtain tokens for subsequent requests. If you are using an API Gateway, Authentication and Authorization will usually be centralized there.

Secure Communication

Ensure that communication between microservices and clients is encrypted using TLS (usually HTTPS) or other secure protocols to prevent eavesdropping and data interception.

Implement Authentication Middleware

Each microservice should include authentication middleware to validate incoming requests. Verify tokens or credentials and extract user identity.

Token Validation

For token-based authentication, validate JWT tokens or OAuth 2.0 tokens using libraries or frameworks that support token validation. Ensure token expiration checks.

User and Role Management

Implement user and role management within each microservice or use an external identity provider to manage user identities and permissions.

Role-Based Access Control (RBAC)

Implement RBAC to define roles and permissions. Assign roles to users and use them to control access to specific microservice endpoints or resources.

Authorization Middleware

Include authorization middleware in each microservice to enforce access control based on user roles and permissions. This middleware should check whether the authenticated user has the necessary permissions to perform the requested action.

Fine-Grained Access Control

Consider implementing fine-grained access control to control access to individual resources or data records within a microservice based on user attributes, roles, or ownership.

In general, it's essential to consider the Top 10 OWASP API Security Risks and implement preventive strategies that help overcome these API Security risks.

💡Pro Tip: When you build your microservices with Amplication, many of the above concerns are already taken care of automatically - each generated service comes with built-in authentication and authorization middleware. You can manage roles and permissions for your APIs easily from within the Amplication interface, and the generated code will already include the relevant middleware decorators (Guards) to enforce the authorization based on what you defined in Amplication.

Testing Microservices

Unit testing

Unit testing microservices involves testing individual components or units of a microservice in isolation to ensure they function correctly.

These tests are designed to verify the behavior of your microservices' most minor testable parts, such as functions, methods, or classes, without external dependencies.

For example, in our microservice we built earlier, we can unit test the OrderService by mocking its database and external API calls and ensuring that the OrderService is error-free on its own.

Integration testing

Integration testing involves verifying that different microservices work together correctly when interacting as part of a larger system.

These tests ensure that the integrated microservices can exchange data and collaborate effectively.

Deploying Microservices to a Production Environment

Deploying microservices to a production environment requires careful planning and execution to ensure your application's stability, reliability, and scalability. Let's discuss some of the key steps and considerations attached to that.

Containerization and Orchestration: We need first to containerize the microservices using technologies like Docker. Containers provide consistency across development, testing, and production environments. Use container orchestration platforms like Kubernetes to manage and deploy containers at scale.
💡 Did you know? Amplication provides a Dockerfile for containerizing your services out of the box and has a plugin to create a Helm Chart for your services to ease container orchestration.
Infrastructure as Code (IaC): Define your infrastructure using code (IaC) to automate the provisioning of resources such as virtual machines, load balancers, and databases. Tools like Terraform, Pulumi, and AWS CloudFormation can help.
Continuous Integration and Continuous Deployment (CI/CD): Implement a CI/CD pipeline to automate microservices' build, testing, and deployment. This pipeline should include unit tests, integration tests, and automated deployment steps.
💡Did you know? Amplication has a plugin for GitHub Actions that creates an initial CI pipeline for your service!
Environment Configuration: Maintain separate environment configurations like development, staging, and production to ensure consistency and minimize human error during deployments.
Secret Management: Securely stores sensitive configuration data and secrets using tools like AWS Secrets Manager or HashiCorp Vault. Avoid hardcoding secrets in code or configuration files.
Monitoring and Logging: Implement monitoring and logging solutions to track the health and performance of your microservices in real time. Tools like Prometheus, Grafana, and ELK Stack (Elasticsearch, Logstash, Kibana) can help.
💡You guessed it! Amplication has a plugin for OpenTelemetry that instruments your generated services with tracing and sends tracing to Jaeger!

Scaling microservices

Scaling microservices involves adjusting the capacity of your microservice-based application to handle increased loads, traffic, or data volume while maintaining performance, reliability, and responsiveness. Scaling can be done vertically (scaling up) and horizontally (scaling out). A key benefit of a microservices architecture, compared to a monolithic one, is the ability to individually scale each microservice - allowing a cost-efficient operation (usually, high-load only affects specific microservices and not the entire application).

Vertical Scaling

Vertical scaling refers to upgrading the resources of an individual microservice instance, such as CPU and memory, to manage higher workloads effectively.

The main upside of this approach - there is no need to worry about the architecture of having multiple instances of the same microservice and how to coordinate and synchronize them. It is a simple approach and does not involve changing your architecture or code. The downsides of this approach are: a) Vertical scaling is eventually limited (There is only so much RAM and CPU you can provision in a single instance) and gets expensive very quickly; b) It might involve some downtime as in many cases, vertical scaling of an instance involves provisioning a new, bigger instance, and then migrating your microservice to run on the new instance.

Source: https://data-flair.training/blogs/scaling-in-microsoft-azure/

Horizontal Scaling

Horizontal scaling involves adding more microservice instances to distribute the workload and handle increased traffic. This is usually the recommended scaling approach in many cases since it's cheaper (in most cases) and allows "infinite scale". In addition, scaling back down is very easy in this method - just remove some of the instances. It does require however some architectural planning to ensure that multiple instances of the same microservice "play nicely" together in terms of data consistency, coordination and synchronization, session stickiness concerns, and not locking mutual resources.

Source: https://data-flair.training/blogs/scaling-in-microsoft-azure/

Common Challenges and Best Practices

Microservices architecture offers numerous benefits but comes with its own challenges.

Scalability

Challenge: Scaling individual microservices while maintaining overall system performance can be challenging.
Best Practices: Implement auto-scaling based on real-time metrics. Use container orchestration platforms like Kubernetes for efficient scaling. Conduct performance testing to identify bottlenecks.

Security

Challenge: Ensuring security across multiple microservices and managing authentication and authorization can be complex.
Best Practices: Implement a zero-trust security model with proper authentication like OAuth 2.0 and authorization like RBAC. Use API gateways for security enforcement. Regularly update and patch dependencies to address security vulnerabilities.

Deployment and DevOps

Challenge: Coordinating deployments and managing the CI/CD pipeline for a large number of microservices can be challenging.
Best Practices: Implement a robust CI/CD pipeline with automated testing and deployment processes. Use containerization like Docker and container orchestration like Kubernetes for consistency and scalability. Make sure that each microservice is completely independent in terms of deployment.

Versioning and API Management

Challenge: Managing API versions and ensuring backward compatibility is crucial when multiple services depend on APIs.
Best Practices: Use versioned APIs and introduce backward-compatible changes whenever possible. Implement API gateways for version management and transformation.

Monitoring and Debugging

Challenge: Debugging and monitoring microservices across a distributed system is difficult. It's much easier to follow the flow of a request in a monolith compared to tracking a request that is handled in a distributed manner.
Best Practices: Implement centralized logging and use distributed tracing tools like Zipkin and Jaeger for visibility into requests across services. Implement health checks and metrics for monitoring.

Handling Database Transactions

Handling database transactions in a microservices architecture can be complex due to the distributed nature of the system.

Microservices often have their own databases, and ensuring data consistency and maintaining transactional integrity across services requires careful planning and the use of appropriate strategies.

Figure: Database per Microservice

As shown above, having a single database per microservice helps adopt better data modeling requirements and even lets you scale the database in and out independently. This way, you have more flexibility in handling DB-level bottlenecks.

Therefore, when you're building microservices, having a separate database per service is often recommended. But, there are certain areas that you should consider when doing so:

1. Microservices and Data Isolation: Each microservice should have its database. This isolation allows services to manage data independently without interfering with other services.

2. Distributed Transactions: Avoid distributed transactions whenever possible. They can be complex to implement and negatively impact system performance. Use them as a last resort when no other option is viable.

3. Eventual Consistency: Embrace the eventual consistency model. In a microservices architecture, it's often acceptable for data to be temporarily inconsistent across services but eventually converge to a consistent state.

4. Adopt The Saga Pattern: Implement the Saga pattern to manage long-running and multi-step transactions across multiple microservices. Sagas consist of local transactions and compensating actions to maintain consistency.

DevOps with Microservices

DevOps practices are essential when working with microservices to ensure seamless collaboration between development and operations teams, automate processes, and maintain the agility and reliability required in a microservices architecture.

Here are some critical considerations for DevOps with microservices:

Automation

Continuous Integration (CI)

Implement CI pipelines that automatically build, test, and package microservices whenever code changes are pushed to version control repositories.

Continuous Delivery/Deployment (CD)

Automate the deployment process of new microservice versions to different environments like preview, staging, and production.

Infrastructure as Code (IaC)

Use IaC tools like Terraform, Pulumi, or AWS CloudFormation to automate the provisioning and configuration of infrastructure resources, including containers, VMs, Network resources, Storage resources, etc.

Containerization

Use containerization technologies like Docker to package microservices and their dependencies consistently. This ensures that microservices can run consistently across different environments. Implement container orchestration platforms like Kubernetes or Docker Swarm to automate containerized microservices' deployment, scaling, and management.

Microservices Monitoring

Implement monitoring and observability tools to track the health and performance of microservices in real time. Collect metrics, logs, and traces to diagnose issues quickly. Use tools like Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), and distributed tracing like Zipkin or Jaeger for comprehensive monitoring.

Deployment Strategies

Implement deployment strategies like blue-green deployments and canary releases to minimize downtime and risks when rolling out new versions of microservices. Automate rollbacks if issues are detected after a deployment, ensuring a fast recovery process.

Wrapping Up

In this comprehensive guide, we've delved into the world of microservices, exploring the concepts, architecture, benefits, and challenges of this transformative software development approach. Microservices promise agility, scalability, and improved maintainability, but they also require careful planning, design, and governance to realize their full potential. By breaking down monolithic applications into smaller, independently deployable services, organizations can respond to changing business needs faster and more flexibly.

We've discussed topics such as building microservices with Node.js, Handling security in microservices, testing microservices, and the importance of well-defined APIs. DevOps practices are crucial in successfully implementing microservices, facilitating automation, continuous integration, and continuous delivery. Monitoring and observability tools help maintain system health, while security practices protect sensitive data.

As you embark on your microservices journey, remember there is no one-size-fits-all solution. Microservices should be tailored to your organization's specific needs and constraints. When adopting this architecture, consider factors like team culture, skill sets, and existing infrastructure.

Good luck with building your perfect microservices architecture, and I really hope you will find this blog post useful in doing so.

Understanding and Preventing Memory Leaks in Node.js

Muly Gottlieb — Fri, 15 Sep 2023 14:48:29 +0000

Memory leaks in Node.js???

In my early career, I spent a lot of years writing code in C and C++. Memory management in those languages was a real art, and disasters like memory leaks, dangling pointers, and segmentation faults were no strangers to my life. Then, at some point, the world, along with my career, all moved to memory-managed languages like Java, .NET, Python, and of course - the inevitable JavaScript. At first, coming from C/C++, the concept of automatic memory management and garbage collection seemed too good to be true - can I really stop worrying about memory leaks?? I'll take two of those, please.

But as is often the case in life, if something is too good to be true - it might indeed not be (completely) true. Automatic memory management is great, but it's not a foolproof silver bullet, and memory leaks are still lurking out there even when you write code in languages that possess this trait - like JavaScript. This means that for us, the Node.js developers, there are still concerns to be aware of regarding memory leaks.

Let's dive into memory leaks in Node.js and see how they can occur, how to identify them, and, of course, some tips on how to avoid them.

How do memory leaks occur?

Memory leaks are caused when the Garbage Collector on Node.js does not release blocks of memory that aren't being utilized. Ultimately, this causes the application's overall memory utilization to increase monotonically, even without any demanding workload, which can significantly degrade the application's performance in the long run.

And, to make things worse, these memory blocks can grow in size, causing your app to run out of memory, which eventually causes your application to crash.

Therefore, it's essential to understand what memory leaks are and how they can occur in Node.js apps so that you can troubleshoot such issues quickly and fix them before a user experiences a problem in your app.

How does Garbage Collection happen in Node.js?

Before diving in any further, it's essential to understand the process of Garbage Collection in Node.js. This is crucial when troubleshooting memory leaks in Node.js.

Node.js uses Chrome's V8 runtime to run its JavaScript code. All JavaScript code processed in the V8 runtime is processed in the memory in two main places:

Stack: The stack holds static data, method and function frames, primitive values, and pointers to stored objects. As usual with Stacks (and in particular call stacks), they get pushed and popped in a LIFO order, and popping from the stack automatically frees the relevant stack memory. Nothing for us to worry about :)
Heap: The heap keeps the objects referenced in the stack's pointers. Since everything in JavaScript is an object, all dynamic data, like arrays, closures, sets, and all of your class instances, are stored in the heap. As a result, the heap becomes the biggest block of memory used in your Node.js app, and it’s where Garbage Collection (GC) will ultimately happen.

Why is Garbage Collection Expensive in Node.js?

Node.js needs to periodically run its garbage collector process, which is basically code that needs to run and map the heap objects to identify unreachable objects (unreferenced). As the heap (and the reference tree) grows, this becomes an expensive computational task.

Since JavaScript is single-threaded, this will interrupt the application flow until garbage collection is completed. That is the main reason why the GC process runs infrequently.

What causes a memory leak in Node.js?

With this information, it's safe to assume that most memory leaks in Node.js will happen when expensive objects are stored in the heap but aren't used. So, ultimately, memory leaks are caused by the coding habits that you adopt and the overall understanding that you have of the workings of Node.js

Let's look at four common cases of memory leaks in Node.js so we know what patterns we want to avoid (or minimize).

Memory Leak 01 - Use of Global Variables

Global variables are a red flag in Node.js. It heavily contributes to memory leaks in your app if it's not handled correctly. For those of you who don't know what it is, a global variable is a variable that's referenced by the root node. It’s the equivalent of the Window Object for JavaScript running in the browser.

So, these global variables never cease to be referenced. Therefore, the garbage collector will never clean them up throughout your app lifecycle. Your global variables will continue allocating memory in the app during its execution. Therefore, if you're managing highly complex data structures or nested object hierarchies in the root of your app, your app is at a high chance of being impacted by memory leaks.

For example, if you're working with dynamic data structures, as shown below, your app will likely have memory leaks:

// Global variable holding a large array
global.myArray = [];

function addDataToGlobalArray(data) {
  // Push data into the global array
  global.myArray.push(data);
}

// Function to remove data from the global array
function removeDataFromGlobalArray() {
  // Pop data from the global array
  global.myArray.pop();
}

// Function to do some processing with the global array
function processData() {
  // Use the global array for some computation
  console.log(`Processing data with ${global.myArray.length} elements.`);
}

// Call functions to add and process data
addDataToGlobalArray("Item 1");
processData();

// Call functions to add and remove data
addDataToGlobalArray("Item 2");
removeDataFromGlobalArray();

// Call processData again
processData();

// The global.myArray variable is still in memory, even though it's no longer needed.

Memory Leak 02 - Use of Multiple References

The next issue is something that we have all done at some point. It's when you use multiple references that point to one object in the heap. Such issues are often developer faults where they reference various variables to the same object.

Therefore, if you deallocate one variable, the heap won't clear it as more variables point to the same reference. For example, the code shown below is a classic scenario in which you're bound to run into memory leaks:

// Define two objects with circular references
const obj1 = { name: "Object 1" };
const obj2 = { name: "Object 2" };

// Create circular references between obj1 and obj2
obj1.reference = obj2;
obj2.reference = obj1;

By doing so, both obj1 and obj2 will never be cleaned up by the garbage collector as each object is pointing to the other.

Memory Leak 03 - Use of Closures

Closures memorize their surrounding context. When a closure holds a reference to a large object in the heap, it keeps the object in memory as long as the closure is in use. For example, consider the snippet below:

function createClosure() {
  const data = "I'm a variable captured in a closure";

  // Return a function that captures the 'data' variable
  return function() {
    console.log (data);
  };
}

// Create a closure by calling createClosure
const closure = createClosure();

// The closure still references 'data' from its outer scope
// Even though 'createClosure' has finished executing
closure();

// The 'data' variable is not eligible for garbage collection

As shown above, all the variables defined inside createClosure() are being used by the function that is returned from createClosure(). And since JavaScript refers to the lexical scope when getting references to the variables it has used, data will never be collected by the garbage collector. If you manage more complex or dynamic data inside a closure, this pattern is prone to memory leaks.

Memory Leak 04 - Unmanaged use of Timers and Intervals

If you're using setTimeout or setInterval with Node.js, you should know they are a very common source of memory leaks. Node.js will keep referencing the function Object passed to setTimer or setInterval as long as they are not stopped. If you do not store the returned id from setTimer and setInterval in order to call clearTimeout / clearInterval, those function Objects will stay referenced and won't get garbage collected. If, on top of that, you don't wisely manage the variables you create inside your function Object, you are prone to memory leaks.

Consider this snippet:

function thisWillLeak() {
  let numbers = [];
  return function() {
    numbers.push(Math.random());
  }
}

setInterval(thisWillLeak(), 2000);

In this example, the numbers array will keep growing in memory forever and will not get garbage collected since the Interval is never cleared. You should make sure to store the returned timeoutId/intervalId in a variable and to make sure to clear them as soon as they are no longer used:

thisWillNoLongerLeak = setInterval(thisWillLeak(), 2000);
// .... do some things with this Interval
clearInterval(thisWillNoLongerLeak);

How can I identify a memory leak in Node.js?

The snippets I provided in this article might make it seem like memory leaks are pretty easy to diagnose. But your codebase is not as simple as these examples and will have a much higher count of lines of code. Therefore, if you wish to find memory leaks by reviewing your codebase, you'll have to go through an irrational number of lines of code in your app to find issues related to global scopes, closures, or any of the other points I've covered.

Therefore, relying on tools specializing in debugging memory leaks in Node.js apps is best. Here are a few tools to help you detect memory leaks.

Tool 01 - node-inspector

Figure: Node Inspector

node-inspector (GitHub | NPM) lets you connect to a running app by running the node-debug command. This command will load Node Inspector in your default browser. Node Inspector supports Heap Profiling and can be useful for debugging memory leak issues.

Tool 02 - Chrome DevTools

Figure: Chrome DevTools

The next option is to use a tool already built into your browse - Chrome DevTools.

Chrome DevTools lets you analyze the application memory in real-time and troubleshoot potential memory leaks.

Figure: A sample DevTool inspection

Wrapping up

In order to make sure your services are robust and won't crash, it's essential to look closely into your codebase and identify potential patterns that might cause memory leaks. If they remain untreated, your app's memory footprint will monotonically increase as the app grows, which could drastically impact app performance for your end users.

So, do take note of the areas I mentioned above - Closures, Global Variables, Multiple/Circular References, Timeouts, and Intervals as these are the key areas that can cause memory leaks in your app.

I hope that you will find this article helpful on your journey to make your services robust.

If you are indeed all about making your Node.js microservices robust and coded to the highest standards, there is one more tool that can help you with that... 😉:

How can Amplication Help?

Amplication lets you auto-generate Node.js code for your microservices, enabling you to build high-quality apps with high-quality code that take extra precautions for the issues discussed above to ensure that your app will not cause any memory leaks (well, at least not in the boilerplate code we generate. The rest... is up to you 😊).

How to Effectively Use Caching to Improve Microservices Performance

Muly Gottlieb — Tue, 12 Sep 2023 15:21:12 +0000

Introduction

In the dynamic landscape of modern software development, microservices have emerged as a powerful architectural paradigm, offering scalability, flexibility, and agility. However, maintaining optimal performance becomes a crucial challenge as microservices systems grow in complexity and scale. This is where caching becomes a key strategy to enhance microservices' efficiency.

This article will dive into the art of leveraging caching techniques to their fullest potential and ultimately boosting the performance of microservices.

What are Microservices?

Microservices are a distinctive architectural strategy that partitions applications into compact, self-contained services, each tasked with a distinct business function.

These services are crafted to operate autonomously, enabling simpler development, deployment, and scalability.

This approach promotes agility, scalability, and effectiveness within software development.

What is Caching?

Caching is a technique used in computer systems to store frequently accessed data or computation results in a temporary storage area called a "cache."

The primary purpose of caching is to speed up data retrieval and improve system performance by reducing the need to repeat time-consuming operations, such as database queries or complex computations.

Caching is widely used in various computing systems, including web browsers, databases, content delivery networks (CDNs), microservices, and many other applications.

What are the Different Types of Caching Strategies?

There are different types of caching strategies. We will explore database caching, edge caching, API caching, and local caching.

Database caching

Database caching involves storing frequently accessed or computationally expensive data from a database in a cache to improve the performance and efficiency of data retrieval operations. Caching reduces the need to repeatedly query the database for the same data, which can be slow and resource-intensive. Instead, cached data is readily available in memory, leading to faster response times and lower load on the database. There are a few different database caching strategies. Let's discuss them.

Cache aside:

In a cache-aside setup, the database cache is positioned adjacent to the database itself. When the application needs specific data, it initially examines the cache. The data is promptly delivered if the cache contains the required data (referred to as a cache hit).

Alternatively, if the cache lacks the necessary data (a cache miss), the application will proceed to query the database. The application then stores the retrieved data in the cache, making it accessible for future queries. This strategy proves particularly advantageous for applications that heavily prioritize reading tasks. The below image depicts the steps in the cache-aside approach.

(image source: prisma.io)

Read through:

In a read-through cache configuration, the cache is positioned between the application and the database, forming a linear connection. This approach ensures that the application exclusively communicates with the cache when performing read operations. The data is promptly provided if the cache contains the requested data (cache hit). In instances of cache misses, the cache will retrieve the missing data from the database and then return it to the application. However, the application continues to interact directly with the database for data write operations. The below image depicts the steps in the read-through approach.

(image source: prisma.io)

Write through:

Unlike the previous strategies we discussed, this strategy involves initially writing data to the cache instead of the database, and the cache promptly mirrors this write to the database. The setup can still be conceptualized similarly to the read-through strategy, forming a linear connection with the cache at the center. The below image depicts the steps in the write-through approach.

(image source: prisma.io)

Write back:

The write-back approach functions nearly identical to the write-through strategy, with a single crucial distinction. In the write-back strategy, the application initiates the writing process directly to the cache as in the write-through case. However, in this case, the cache doesn't promptly mirror the write to the database; instead, it performs the database write after a certain delay. The below image depicts the steps in the write-back approach.

(image source: prisma.io)

Write around:

A write-around caching approach can be integrated with either a cache-aside or a read-through strategy. In this setup, data is consistently written to the database, and retrieved data is directed to the cache. When a cache miss occurs, the application proceeds to access the database for reading and subsequently updates the cache to enhance future access. The below image depicts the steps in the write-around approach.

(image source: prisma.io)

Edge caching

Edge caching, also known as content delivery caching, involves the storage of content and data at geographically distributed edge server locations closer to end users. This technique is used to improve the delivery speed and efficiency of web applications, APIs, and other online content. Edge caching reduces latency by serving content from servers located near the user, minimizing the distance data needs to travel across the internet backbone. This is mostly useful for static content like media, HTML, CSS, etc.

API Caching

API caching involves the temporary storage of API responses to improve the performance and efficiency of interactions between clients and APIs. Caching API responses can significantly reduce the need for repeated requests to the API server, thereby reducing latency and decreasing the load on both the client and the server. This technique is particularly useful for improving the responsiveness of applications that rely heavily on external data sources through APIs.

Local caching

Local caching, also known as client-side caching or browser caching, refers to the practice of storing data, files, or resources on the client's side (such as a user's device or web browser) to enhance the performance of web applications and reduce the need for repeated requests to remote servers. By storing frequently used data locally, local caching minimizes the latency associated with retrieving data from remote servers and contributes to faster page loads and improved user experiences.

What are the Benefits of using Caching in Microservices?

Utilizing caching in a microservices architecture can offer a multitude of benefits that contribute to improved performance, scalability, and efficiency. Here are some key advantages of incorporating caching into microservices:

Enhanced Performance & Lower Latency: Caching reduces the need to repeatedly fetch data from slower data sources, such as databases or external APIs. Cached data can be quickly retrieved from the faster cache memory, leading to reduced latency and faster response times for microservices.
Reduced Load on Data Sources: By serving frequently requested data from the cache, microservices can alleviate the load on backend data sources. This ensures that databases and other resources are not overwhelmed with redundant requests, freeing up resources for other critical tasks.
Improved Scalability: Caching allows microservices to handle increased traffic and load more effectively. With cached data, microservices can serve a larger number of requests without overloading backend systems, leading to better overall scalability.
Optimized Data Processing: Microservices can preprocess and store frequently used data in the cache, allowing for more complex computations or transformations to be performed on cached data. This can result in more efficient data processing pipelines.
Offline Access and Resilience: In scenarios where microservices need to operate in offline or disconnected environments, caching can provide access to previously fetched data, ensuring continued functionality.

Key Considerations When Implementing Caching in Microservices

Implementing caching in a microservices architecture requires careful consideration to ensure that the caching strategy aligns with the specific needs and characteristics of the architecture. Here are some key considerations to keep in mind when implementing caching in microservices:

Data Volatility and Freshness: Evaluate the volatility of your data. Caching might not be suitable for data that changes frequently, as it could lead to serving stale information. Determine whether data can be cached for a certain period or whether it requires real-time updates.
Data Granularity: Identify the appropriate level of granularity for caching. Determine whether to cache individual items, aggregated data, or entire responses. Fine-tuning granularity can impact cache hit rates and efficiency.
Cache Invalidation: Plan how to invalidate cached data when it becomes outdated. Consider strategies such as time-based expiration, manual invalidation, or event-based invalidation triggered by data changes. This is arguably the most challenging part of implementing caching successfully. I recommend giving this careful thought during system design, particularly if you're not very experienced with caching.
Cache Eviction Policies: Choose appropriate eviction policies to handle cache capacity limitations. Common strategies include Least Recently Used (LRU), Least Frequently Used (LFU), and Time-To-Live (TTL) based eviction.
Cache Consistency: Assess whether data consistency across microservices is critical. Depending on the use case, you might need to implement cache synchronization mechanisms to ensure data integrity.
Cold Start: Consider how to handle cache "cold starts" when a cache is empty or invalidated, and a high volume of requests is received simultaneously. Implement fallback mechanisms to gracefully handle such situations. Consider implementing an artificial cache warm-up when starting the service from a "cold" state.
Cache Placement: Decide where to place the cache – whether it's inside the microservices themselves, at the API gateway, or in a separate caching layer. Each option has its benefits and trade-offs in terms of ease of management and efficiency.
Cache Segmentation: Segment your cache based on data access patterns. Different microservices might have distinct data access requirements, and segmenting the cache can lead to better cache utilization and hit rates.
Cache Key Design: Design cache keys thoughtfully to ensure uniqueness and avoid conflicts. Include relevant identifiers that accurately represent the data being cached. Choose keys that are native to the consuming microservices.
Cloud-Based Caching Services: Evaluate the use of cloud-based caching services, such as Amazon ElastiCache or Redis Cloud, for managed caching solutions that offer scalability, resilience, and reduced maintenance overhead.

Overview of Popular Caching Tools

Redis

Redis is an open-source data structure store that functions as a database, cache, messaging system, and stream processor. It supports various data structures like strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes, and streams. Redis offers built-in features such as replication, scripting in Lua, LRU (Least Recently Used) eviction, transactions, and multiple levels of data persistence. Additionally, it ensures high availability through Redis Sentinel and automatic partitioning via Redis Cluster. The below image depicts how Redis is traditionally used.

Redis prioritizes speed by utilizing an in-memory dataset. Depending on your needs, Redis can make your data persistent by periodically saving the dataset to disk or logging each command to disk. You also have the option to disable persistence if your requirement is solely a feature-rich, networked, in-memory cache. Redis can be a valuable tool for improving the performance of microservices architectures. It offers fast data retrieval, caching capabilities, and support for various data structures.

It's important to note that while Redis can significantly enhance microservices performance, it also introduces some considerations, such as cache invalidation strategies, data persistence, and memory management. Proper design and careful consideration of your microservices' data access patterns and requirements are crucial for effectively leveraging Redis to improve performance.

💡Pro Tip: Amplication now offers a Redis Plugin that can help you integrate Redis into your microservices more easily than ever before.

Memcached

Memcached is another popular in-memory caching system that can be used to improve the performance of microservices. Similar to Redis, Memcached is designed to store and retrieve data quickly from memory, making it well-suited for scenarios where fast data access is crucial. It is a fast and distributed system for caching memory objects. While it's versatile, its initial purpose was to enhance the speed of dynamic web applications by reducing the workload on databases. It's like a brief memory boost for your applications.

Memcached can redistribute memory surplus from certain parts of your system to address shortages in other areas. This optimization aims to enhance memory utilization and efficiency.

Consider the two deployment scenarios depicted in the diagram:

In the first scenario (top), each node operates independently. However, this approach is inefficient, with the cache size being a fraction of the web farm's actual capacity. It's also labor-intensive to maintain cache consistency across nodes.
With Memcached, all servers share a common memory pool (bottom). This ensures that a specific item is consistently stored and retrieved from the same location across the entire web cluster. As demand and data access requirements increase with your application's expansion, this strategy aligns scalability for both server count and data volume.

Though the illustration shows only two web servers for simplicity, this concept holds as the server count grows. For instance, while the first scenario provides a cache size of 64MB with fifty servers, the second scenario yields a substantial 3.2GB cache size. It's essential to note that you can opt not to use your web server's memory for caching. Many users of Memcached choose dedicated machines specifically designed as Memcached servers.

Amplication for building Microservices

If you're eager to explore microservices architecture and seeking an excellent entry point, consider Amplication. Amplication is an open-source, user-friendly backend generation platform that simplifies the process of crafting resilient and scalable microservices applications 20x faster. With a large and growing library of plugins, you have the freedom to use exactly the tools and technologies you need for each of your microservices.

Conclusion

By incorporating caching intelligently, microservices can transcend limitations, reducing latency, relieving database pressure, and scaling with newfound ease. The journey through the nuances of caching strategies unveils its potential to elevate not only response times but also the overall user experience.

In conclusion, the marriage of microservices and caching isn't just a technological union – it's a gateway to unlocking huge performance gains. As technology continues to evolve, this synergy will undoubtedly remain a cornerstone in the perpetual quest for optimal microservices performance.

Picking the Perfect Database for Your Microservices

Muly Gottlieb — Thu, 07 Sep 2023 08:49:36 +0000

Microservices have been the go-to application architecture that many software projects have adopted due to the numerous benefits they offer, ranging from:

Service decoupling
Faster development times
Faster release times
Tailored datastores

Hence, developers can select the right tools and platforms that help deliver the best performance in each specific microservice. One aspect to consider when doing so is eliminating the use of a monolithic data-store architecture in the application. Microservices favour independent service components where each service can run on its own runtime and connect to its own database.

This means you're encouraged to share data between microservices rather than using an extensive single database for all your microservices, as shown below.

Figure: A microservices architecture

However, this raises the question, How should you pick the correct (distributed) database for each microservice?

How do you choose the best database for a microservice?

To answer this question, you need to understand that different types of databases are made to cater to different purposes and requirements.

Therefore, you must consider factors such as performance, reliability, and data modelling requirements in your decision-making process to ensure that you select the correct database.

The CAP Theorem for Distributed Databases

It's important to understand that when selecting a database, you must consider its Consistency, Availability, and (network) Partition tolerance capability.

This is also known as the CAP Theorem, and it's vital to be aware that there are tradeoffs in database design where one of these factors will always be impacted by the other two. In a nutshell, the CAP theorem proposed that any database in a distributed system can have some combination of the following properties:

(Sequential) Consistency: Distributed Databases that satisfy this property will always return the same data (latest committed data) from all DB nodes/shards, which means that all your DB clients will get the latest data regardless of the node they query.
Availability: Distributed Databases that satisfy this property guarantee to always respond to read and write requests in a timely manner from every reachable node.
(Network) Partition Tolerance: Distributed Databases that satisfy this property guarantee to function even if there is a network disconnection between the DB nodes (which partitions the DB nodes into two or more network partitions).

These three factors make up modern distributed databases, but the CAP Throrem states that no database can satisfy all three characteristics. Any database implementation can choose two of those characteristics at the expense of the third.

Distributed Databases therefore fall into one of the following combinations:

CA (Consistency + Availability): Your database can serve the most recent data from all the nodes while remaining highly available.
CP (Consistency + Partition Tolerance): Your database can serve the most recent data from all the nodes with a high resilience to network errors.
AP (Availability + Partition Tolerance): Your database nodes always respond timely and can respond well even in the face of network failures. But it doesn't guarantee returning the last updated data from every node. These databases adopt a principle known as "Eventual Consistency," where the data is replicated eventually and not instantly (eventual consistency is a weaker form of consistency compared to sequential consistency, which is the "C" in CAP Theorem).

So, it's essential to understand the CAP theorem before selecting a database. The table below showcases some popular distributed databases according to their "CAP Theorem preference".

By evaluating your non-functional requirements, you can use this as a guide to understanding the direction you need to look at.

Figure: CAP Theorem preferences in popular databases

Database vs. Service Requirements

I've covered this topic above, but apart from the CAP Theorem, it's essential to understand that selecting the correct database for your microservice ultimately depends on your service requirements. This is also known as polyglot persistence. It's where you utilize different databases for different services depending on the requirement of each service.

For example, your microservice might be read or write-intensive, need rapid scaling, or simply high durability. Therefore, it's essential to understand your requirements clearly before deciding on a database.

Performance (Read/Write) Requirements

The first aspect you may need to look at is performance.

If you're building a microservice that needs to be high-performing, you'll likely need a database that can meet that exact demand.

For example, suppose you're building your microservice using an API Gateway and AWS Lambda. In that case, your service can scale infinitely, so you'll need a database that can scale as your Lambda functions scale. If you fail to do so, you'll create a bottleneck in your database-level service, which could lead to inter-service latencies and timeout errors as your system cannot scale.

So, in such cases, it's essential to consider the number of IOPS (Input/Output Operations Per Second) your service will process. Here are some typical numbers for operations per second:

Very high — Greater than one million IOPS
High — Between 500,000 and one million IOPS
Moderate — Between 10,000 and 500,000 IOPS
Low — Less than 10,000 IOPS

So, it's essential to consider the IOPS you'll be processing in your service before picking a database.

Latency Requirements

The next requirement to look at is latency. Latency refers to the delay that has occurred when serving a read/write request.

For latency, the typical numbers are:

Low — Less than one millisecond
Moderate — one to 10 milliseconds
High — Greater than 10 milliseconds

If you're building microservices that need instant communication, you'll likely need to adopt a low-latency database.

For example, let's say you're modelling a Search Service:

Figure: A Product Searching Service

Ideally, a search operation cannot take more than a few seconds, regardless of the payload. Therefore, in such cases, you'll need to pick a database that supports delivering responses in the defined period.

Data Modelling Requirements

One of the most significant advantages of choosing microservices over monolith is that developers get to define different data models for different services. A typical microservices architecture may consist of data models comprising key-value, graph, time-series, JSON, streams, search engines, and more.

For example, if you were modelling an e-commerce app with microservices, you could have a data requirement as follows:

Figure: Metric requirement for services

Some of your services would need very high read performance with low latency, while others can tolerate a moderate level of latency.

Each of these services could have a data model as follows:

Figure: Modelling microservice data structures

For example, DynamoDB is a strong candidate for the Cache Server as it requires very high read performance (less than 1 ms) and high write performance with low latency.

You should formalize the performance requirements for your microservices in terms of acceptable latency and IOPS to ensure you're selecting the correct database for your microservice.

What are the tips for choosing the correct database for a microservice?##

Tip #1 - Consider the CAP Theorem

When you pick a database, look into its workings and identify its location in the CAP theorem. Proceed with the database only if it meets your expectations in the CAP Theorem, as there will always be tradeoffs.

Tip #2 - Gather all requirements upfront

It's essential to understand the requirements of your microservice before you pick a database for it. If your microservice is write-heavy but not read-heavy, you could consider utilizing two databases (one for reading, one for writing) and communicating with them using Eventual Consistency and the CQRS (Command Query Responsibility Segregation) pattern.

Apart from that, gain an insight into the acceptable latency and IOPS your database will need.

Tip #3 - Use Amplication 😁 💜

Consider using tools like Amplication to build your microservices. Amplication lets you bootstrap and build microservices in just a few clicks while allowing you to select specific databases such as PostgreSQL, MySQL, and MongoDB for each particular service, depending on your requirements. Swapping a database in favour of another is just four clicks. This allows you to experiment and test with different databases very quickly, which can be a game changer for testing multiple databases per service until you find the most suitable one.

Pro Tip 💡 - Database implementations in Amplication come in the form of a plugin, and you can easily write your own plugins for other databases if you wish to experiment even more.

Wrapping up

Microservices have gained a significant advantage over monoliths due to their capability to support loosely coupled services, where each service can be developed, tested, and maintained in isolation while using a separate datastore that is most suitable for that microservice.

Hence, it's essential to understand how to pick the most suitable database for each microservice. You need to dive into aspects like IOPS, Latency, and Data Modeling and gain a strong understanding of the CAP Theorem to ensure that you pick the correct database. You should strive to build your services using architectures and platforms that will allow you to easily swap databases in the future.

By doing so, you're on the right path to building highly scalable and high-performing microservices that can serve requests at optimal capacity.

FAQ

Can microservices use multiple databases?

Yes, you are highly encouraged to use separate databases for your microservices as this helps break down the monolith data store and lets you independently scale your database services up and down based on your requirements.

Can microservices use SQL databases?

You can choose between SQL, Key-Value, and Graph databases for your microservice. It depends on your requirements.

Should I use a relational or a NoSQL database for my microservice?

There is no "one size fits all" and no silver bullet. It depends on the requirements that you wish to satisfy. Consider using a normalized relational database if consistency is more important than performance. If performance is important, consider using a NoSQL database.

What are the trade-offs between using a single database for all microservices and multiple databases?

With a single database for all of your microservices, it's challenging to scale parts of your database. And, sometimes, different services might have different access patterns and need other data models that cannot be implemented if you use a single database for all your microservices.

Serving Frontends in Microservices Architecture

Muly Gottlieb — Wed, 30 Aug 2023 08:20:14 +0000

The microservices architecture has emerged as a dominant paradigm in the software development landscape. While much attention has been given to the backend components, the frontend - which serves as the user's gateway to the application - is equally crucial. This article aims to explore the challenges and solutions associated with serving frontends in a microservices environment.

Storing and Serving Frontend Assets

In traditional monolithic applications, frontend assets such as HTML, JavaScript, and CSS were bundled and served from a single server. However, the distributed nature of microservices necessitates a different approach.

Cloud Storage: Solutions like AWS S3, Google Cloud Storage, and Azure Blob Storage have become the backbone for storing frontend assets in a microservices architecture. These platforms offer high availability, redundancy, and scalability. For instance, consider a global e-commerce platform with distinct microservices for product listings, user profiles, and checkout processes. Each of these could have its frontend assets stored in separate cloud storage buckets, ensuring modularity and ease of management.

CDN Integration: A Content Delivery Network (CDN) is essential for global applications. CDNs ensure that users worldwide receive data from the nearest point by caching assets in multiple geographical locations, reducing latency. Platforms like Cloudflare, Akamai, and AWS CloudFront have become industry standards. For instance, a user in London accessing a US-based service will retrieve assets from a European server, ensuring faster load times and a smoother user experience. See below for further elaboration regarding CDNs.

Security Considerations

The public nature of frontend assets brings forth unique security challenges.

Security Headers: Implementing security headers, such as Content Security Policy (CSP), can significantly reduce risks associated with cross-site scripting (XSS) attacks. A well-configured CSP ensures that only whitelisted sources can run scripts, thereby preventing potential malicious injections.

Sensitive Information: It's not uncommon for developers to inadvertently leave sensitive information, such as API keys or debug logs, within frontend code. Regular audits, both manual and automated, are essential to ensure that such data is stripped out before deployment. To automate this process, tools like SonarQube or ESLint can be integrated into CI/CD pipelines.

Leveraging CDNs for Faster Content Delivery

The role of CDNs in a microservices setup extends beyond just caching.

Global Reach: CDNs play a pivotal role in ensuring consistent user experience for applications with a global user base. They achieve this by replicating your frontend assets across global edge locations and directing user requests to the nearest edge location, reducing the round-trip data retrieval time.

Cache-Control: Modern platforms like Netlify and Vercel offer developers granular control over caching policies. This ensures that users always access the most recent version of assets while also benefiting from caching's speed advantages.

Handling CORS and Preflight Requests

Cross-Origin Resource Sharing (CORS) is a security feature implemented by web browsers, ensuring that web pages make requests only to their own domain. However, CORS can pose challenges in a microservices setup where services might reside on different domains or subdomains.

Gateway Implementation: Employing a gateway, such as AWS API Gateway or Kong, can centralize and manage CORS policies. This ensures that all microservices adhere to a consistent set of CORS rules, simplifying maintenance and troubleshooting.

CDN as a Gateway: Some CDNs offer advanced features that allow them to function as gateways. This means they can handle CORS headers and also pass through API requests, offering a unified solution.

Architectural Alternatives

The microservices architecture offers flexibility in how frontends are served:

Single Service for Frontend: All frontend assets are served from a single service. This approach simplifies deployment and management but can become a bottleneck in large-scale applications.

Micro-frontends: This approach aligns the frontend architecture with microservices. Each microservice has its corresponding frontend, allowing for modular development and deployment. For instance, in a modular e-commerce platform, the product listing page, shopping cart, and user profile could each be a separate micro-frontend, developed and deployed independently.

BFF (Backend For Frontend): This pattern introduces an intermediary service layer that sits between the frontend and multiple backend services. The BFF aggregates and transforms data from various backend services, optimizing it for frontend consumption.

Release Pipelines

The deployment of frontend assets often differs from backend services, especially in a microservices setup.

CI/CD Integration: Continuous Integration and Continuous Deployment (CI/CD) tools like GitHub Actions, Jenkins, Travis CI, and GitLab CI can automate the build, test, and deployment processes. For instance, a new feature developed for a micro-frontend can be automatically tested and, if tests pass, deployed to the production environment (e.g. the CDN) without manual intervention.

Unified Deployments: In scenarios where the frontend and backend are tightly coupled, deploying them simultaneously ensures consistency across the application. This is especially crucial when a new feature or change spans both the frontend and backend.

Tools and Platforms for Frontend Hosting

Several platforms cater specifically to frontend hosting in a microservices environment:

Netlify: Renowned for its simplicity, Netlify offers atomic deploys, instant cache invalidation, and integrated CI/CD, making it a favorite among developers.

Vercel: With a focus on frontend frameworks like React and Next.js, Vercel provides out-of-the-box optimizations, ensuring blazing-fast load times.

AWS CloudFront/S3: This combination is a powerhouse for hosting static assets. With S3 providing reliable storage and CloudFront ensuring global content delivery, it's a robust solution for large-scale applications.

Conclusion

One promising platform that you should check out is Amplication. Amplication focuses on automating the development of business applications and supports various layers, including the backend services and the API layer. By integrating Amplication into the development pipeline, organizations can generate robust, well-designed backend services that effortlessly connect with their modular frontends.

Serving frontends in a microservices architecture is a complex yet rewarding endeavor. Developers can create scalable, resilient, and user-friendly applications by understanding the challenges and leveraging the right strategies and tools. As the world of software development continues to evolve, staying up-to-date with these practices will be paramount for professionals aiming to deliver excellence in the realm of microservices.