DEV Community: Chuiko Liliia

How to Run a Python script from Node.js

Chuiko Liliia — Tue, 14 Mar 2023 11:14:00 +0000

Quite often we hear disputes about what is better to use Node.js or Python.
But what if one day, you come up with a great idea to combine those, for instance to use some Python libraries in your application, but you just do not have any idea how to integrate it with your Node.js application. Of course you can always build API on top of Python backend(Flack, etc), but in that case you need to build, host and manage one more application, when you just need to run a single Python script. That's why I want to give you step by step instructions on how to achieve this.

To begin with, let's briefly define what are both languages.

Node.js is a server-side platform developed on Google Chrome’s Javascript Engine. Node Js allows to develop data-intensive real-time web applications. It is written on JavaScript and allows to run applications on various operating systems such as Windows, Linux, and Mac OS.

Python is an object-oriented programming language used to create dynamic web applications. The syntax of Python and dynamic typing make it an ideal programming language for scripting.

Why you might need to run Python scripts from Node.js

Node js can't run heavy multitask as it works on a single thread basis, making it difficult for Node Js to execute CPU-bound tasks. Whenever any request is received, the system will complete the request once and only accept the other request. This process slows down the system and ends up in a massive delay.
Python is much more suitable for that back-end applications, that use numerical computations, big data solutions, and machine learning.
Python has one of the largest ecosystems out of any programming community and a lot of open-source libraries. For instance some of built-in AI libraries (Pylearn2, Tensorflow for neural networks, and Scikit-learn for data analysis)

Сall your Python script from Node.js using Child Process module

You will find several libraries that can help you with this issue. As for me, I prefer to use built in child_process. The node:child_process module provides the ability to spawn subprocesses. This capability is primarily provided by the child_process.spawn() function.

First, we need to create a server.js file as the server for our app. Where we suppose that X and y are large arrays.


const express = require('express');
const { spawnSync } = require('child_process');
const { readFile } = require('fs/promises');
const { appendFile } = require('fs/promises');
const { join } = require('path');
const app = express();

app.get("/", async (req, res, next)=>{
   const X = [1,2, 5] // large array
   const y = [[1,2], [2,3], [1,2]] // large array

   await appendFile(
            join(`scripts/args.json`),
            JSON.stringify({ X, y }),
            {
                encoding: 'utf-8',
                flag: 'w',
            },
        );
   const pythonProcess = await spawnSync('python3', [
     '/usr/src/app/scripts/python-script.py',
     'first_function',
     '/usr/src/app/scripts/args.json',
     '/usr/src/app/scripts/results.json'
   ]);
  const result = pythonProcess.stdout?.toString()?.trim();
  const error = pythonProcess.stderr?.toString()?.trim();

   const status = result === 'OK';
  if (status) {
    const buffer = await readFile('/usr/src/app/scripts/results.json');
    const resultParsed = JSON.parse(buffer?.toString());
    res.send(resultParsed.toString())
  } else {
    console.log(error)
    res.send(JSON.stringify({ status: 500, message: 'Server error' }))
  }
});

//Creates the server on default port 8000 and can be accessed through localhost:8000
const port=8000;
app.listen(port, () => console.log(`Server is listening on PORT ${port}`));

The first parameter, that was passed to the spawnSync is command<string>(the command to run, in this case is python3 - the version of python that is required to run your libraries), the second is args <string[]>(list of string arguments). You can also pass the third parameter options, the more detailed information can be found by the link.
I propose to consider in more detail the list I am passing as the second argument

'/usr/src/app/scripts/python-script.py' - is the path of the script I need to execute
'first_function' - is the name of the function I want to run inside that file
'/usr/src/app/scripts/args.json' - is the path to the file with arguments to this function. Actually you can directly pass those arguments using JSON.stringify() function in Node.js, but as for me it's better to write those arguments down into the file and then read that from Python script. One of the reasons is that you might need to pass as arguments large arrays of data and this will cause errors.
'/usr/src/app/scripts/results.json' - is the path, where I want my Python script to write results, after it is finished, so I can read that from node.js.

Passed arguments can be found in sys.argv array in Python script. The sys.argv list is a list that contains command line arguments in a python program. Whenever we run a python program from a command line interface, we can pass different arguments to the program. The program stores all the arguments and the file name of the python file in the sys.argv list. This can be seen in more detail by writing a simple example script

import json
import sys

def first_function():
    json_obj = open(sys.argv[2])
    data = json.load(json_obj)
    calculatedResults = [1,2,4,3] # it is just example of data to return, in fact you will calculate it bellow
    X = data["X"]
    y = data["y"]
    # do some your calculations based on X and y and put the result to the calculatedResults
    # print(make_pipeline)
    json_object_result = json.dumps(calculatedResults, indent=4)

    with open(sys.argv[3], "w") as outfile:
        outfile.write(json_object_result)
    print("OK")


if sys.argv[1] == 'first_function':
    first_function()

sys.stdout.flush()

In two words, in Node.js script we write down to the file all required arguments, run spawnSync passing list of arguments and after Python script reads passed arguments from the file, makes all calculations and writes down to the file all results. At the moments all this results can be read in Node.js from file.

Run Python script, that uses specific Python libraries

One of the main goals is to have ability to use built-in AI or other libraries. It's always not a good idea to install dependencies and libraries globally in a system, it can lead to version conflicts, deployment difficulties, and problems with multiple developers working on a project at the same time, for example. That's why the perfect way is to use Docker. You can build the image yourself, but the easiest solution is to use an existing one.

FROM nikolaik/python-nodejs:latest as development
WORKDIR /usr/src/app
RUN pip install scikit-learn numpy pandas simplejson
COPY ./package.json ./yarn.lock ./
RUN yarn
RUN yarn install
COPY ./ ./
RUN yarn build
ENV PORT 4000
EXPOSE $PORT


# Production mode
FROM nikolaik/python-nodejs:latest as production
RUN pip install scikit-learn numpy pandas simplejson
ARG NODE_ENV=production
ENV NODE_ENV=${NODE_ENV}
WORKDIR /usr/src/app
COPY --from=development /usr/src/app ./
ENV PORT 4000
EXPOSE $PORT
CMD ["node", "dist/main"]

For now we can use scikit-learn, numpy, pandas and simplejson libraries on Python script, as they are available in the created docker container.

By following the steps above, you can create a new process and execute a Python script from your Node.js application. This can be useful in cases where you need to integrate Python code into your Node.js application or when you need to perform certain tasks that are better suited for Python. Described simple app can be downloaded from the Github, there you can also find instructions how to run it.

Happy coding and wish you to have a nice day!

Part 2. Quick guide to make your Azure applications work.

Chuiko Liliia — Wed, 05 Jan 2022 12:58:11 +0000

Introduction

In the previous article, we have already created an Azure App service instance. And now you are able to see the Microsoft Azure default page by the link. This time we are going to migrate Strapi app, Next.js app and Mongo DB to Azure.

Preparing Azure App Services for the Migration process

Your project probably has specific environment variables. They should be added to Azure.

Go to the Azure App service instance, find the Configuration in the Settings tab, select Application Settings section.
Here are two kinds of it. Application Settings and Connection Strings. There is only one case for using strings instead of settings, more detailed information can be found by the link. Use Application settings and click on +New application setting.
Put the name and value of the variable and select if it is a deployment slot setting. With this setting in place, database connection strings and other settings are not swapped when the slots are swapped. So the staging slot will always point to the staging database, and the production slot will always point to the production database.

Keep in mind that the values you set in App Service override the values in Web.config and others.

Later I will talk about different deployment methods. But no matter which one you choose, you need to know that deploying new code directly to the production application is a bad practice. For this purpose, every App service instance has staging slots. Deploying your application to a non-production slot has the following benefits:

You can validate app changes in a staging deployment slot before swapping it with the production slot.
Deploying an app to a slot first and swapping it into production guarantees that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped because of swap operations. You can automate this entire workflow by configuring autoswap when pre-swap validation isn't needed.
After a swap, the slot with the previously staged app now has the previous production app. If the changes swapped into the production slot aren't as you expect, you can perform the same swap immediately to get your "last known good site" back.

So the best idea is to create a preview slot that will not affect the production. Creating the slot for an app:

Go to Azure App service instance, find the deployment slots in the Deployment tab, click on Add slot
Put the slot name. It will take your main slot root domain name + name that you will write.
After that, you can select if you need to clone all settings from the main slot or not. If you clone settings, it will make the full copy of the existing slot with the same environment variables. So if you want to use another database or change other settings, you shouldn't clone settings or change them manually after the new slot is ready.

In a few minutes, the preview slot will be available by its own url and can be found in the Deployment Slots tab of the Azure App service instance. And we can proceed to deploy.

Choosing the deployment way

There are a few options to move your project to the instance. Most popular are:

You can deploy to Azure App Service as part of your continuous deployment (CD) workflows via GitHub, Azure Repos
Try Azure Repos with Azure App, make sure you have already created an Azure DevOps Organization to store your project files.
Or use the Azure App Service extension for VS Code to create quickly, manage, and deploy your websites. Just press the install button.

The simplest way for me is deploying via VScode. You will be able to create and deploy resources with it. But this method has a list of disadvantages for my purposes and for. Probably this deployment way will be described in my other article, and for now, deploying using workflows via GitHub was chosen for my project.

Steps to deploy my Strapi back-end application (or any other node.js app) to Azure via GitHub:

Certainly, to achieve this target, your app should be connected to the remote git repository.
Go to your project and create the .github folder at the root of it.
In the .github folder create workflows folder.
In workflows folder create the file with the following name scheme branch_name_app_name(slot_name).yml
For example: App-name: ‘production-app’ Branch from which you want deploy: master Slot: ‘preview’ Final name of the file: master_production-app(preview).yml
Now configure the created .yml file with the following settings. Here is an example that uses the above-declared names:

  push:
    branches:
      - master
  pull_request:
    branches:
      - master

env:
  AZURE_WEBAPP_NAME: production-app  # set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: "."      # set this to the path to your web app project, defaults to the repository root
  NODE_VERSION: '14.x'                # set this to the node version to use
  API_URL: "https://production-app.azurewebsites.net" # main slot url

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Set Node.js version
      uses: actions/setup-node@v1
      with:
        node-version: '14.x'

    # install dependencies, build, and test
    - name: npm install, build, and test  #describes which commands need to be run
      run: |
        npm install
        npm run build --if-present
        npm run test --if-present

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'production-app’'
        slot-name: 'preview'
        publish-profile: ${{ secrets.AzureAppService_PublishProfile_PRODUCTION }}
        package: .

In the file, all seems to be clear. The only exception is some odd variable used on the penultimate line of code. This setting is required to secure your deployments. Reproduce the following steps to get the value :

a. Go to your preview slot instance and select Get Publish Profile. The file will be downloaded. Open it with the notepad or use your imagination.

b. Copy all content of the opened file.
c. Go to your repository on GitHub -> Settings -> Secrets and press New Repository Secret button.
d. Add name AZUREAPPSERVICE_PUBLISHPROFILE_PRODUCTION in value input, paste the copied content from the file and save changes. In two words, this variable connects your repo with the application instance on Azure.

So, when this thousandth step is complete, you can finally push your code to GitHub by directly pushing or creating a pull request to master-branch. Now it is time to take a cup of tea and just follow the action with full deployment logs on GitHub in Actions tab. It may take some time…

What happens now? First of all, GitHub sets the node.js version, installs all dependencies from package.json, and runs the build command. If there are no errors during building, it zips all the files without the node-modules folder and passes them to Azure. Azure does the same steps: extracts files, installs node modules, creates the production build, then removes the previous project folder and instead puts the new one. After it starts the new Docker container and it is warmed up, it runs the npm start command and starts the app.

Don’t be nervous while waiting. The action can take up to 10 minutes or even more for the first time deploying. When the action is completed, you can visit the link of the preview slot. If you are lucky, you will see your app working. But don’t forget the main Microsoft concept: Microsoft — Just restart it. Check if everything works, and then proceed to swap the app to the production slot. To do this, go to the production Azure App service to Deployment slots, find and press the swap button. Select which slot to swap and to which, confirm the action and wait about 5 minutes. When the swap process is ready, you will get the message. And now all your changes are available on the production slot, and the preview slot link should lead you to the example Microsoft Page.

Steps to deploy my Next.js application to Azure via GitHub.

Actually, the steps to deploy next.js are almost the same as for Node.js application. There are some small distinctions. Next.js project doesn’t have the obvious server.js file that is required to deploy it to Azure App Service. There is also another way: deploy to Static Web App Azure service. But it also can’t be used in a simple way because Next.js has the server-side part, which leads to difficulties with deploying it as the static app. So here is what we should do to deploy Next.js app to Azure App Service, besides what we have already done for the previous app:

In the root project folder create server.js file with the next content and install all missing dependencies:

const { createServer } = require("http");
const next = require("next");

const port = process.env.PORT || 3000;
const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  createServer((req, res) => {
    handle(req, res); 
  }).listen(port, (err) => {
    if (err) throw err;
    console.log(`> Ready on http://localhost:${port}`);
  });
});

Change your start script in the package.json file to “node server”.
In the projects root create web.config file with the code:

<?xml version="1.0" encoding="utf-8"?>
<!--
     This configuration file is required if iisnode is used to run node processes behind
     IIS or IIS Express.  For more information, visit:
     https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config
-->

<configuration>
  <system.webServer>
    <!-- Visit http://blogs.msdn.com/b/windowsazure/archive/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites.aspx for more information on WebSocket support -->
    <webSocket enabled="false" />
    <handlers>
      <!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
      <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
    </handlers>
    <rewrite>
      <rules>
        <!-- Do not interfere with requests for node-inspector debugging -->
        <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
          <match url="^server.js\/debug[\/]?" />
        </rule>

        <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
        <rule name="StaticContent">
          <action type="Rewrite" url="public{REQUEST_URI}"/>
        </rule>

        <!-- All other URLs are mapped to the node.js site entry point -->
        <rule name="DynamicContent">
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
          </conditions>
          <action type="Rewrite" url="server.js"/>
        </rule>
      </rules>
    </rewrite>

    <!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
    <security>
      <requestFiltering>
        <hiddenSegments>
          <remove segment="bin"/>
        </hiddenSegments>
      </requestFiltering>
    </security>

    <!-- Make sure error responses are left untouched -->
    <httpErrors existingResponse="PassThrough" />

    <!--
      You can control how Node is hosted within IIS using the following options:
        * watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
        * node_env: will be propagated to node as NODE_ENV environment variable
        * debuggingEnabled - controls whether the built-in debugger is enabled
      See https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config for a full list of options
    -->
    <iisnode watchedFiles="web.config;*.js"/>
  </system.webServer>
</configuration>

Reproduce all steps for deploying node.js app.

Congrats! Deploying both front-end and back-end applications is finally finished. The last thing we need to migrate is the Mongo database.

The first and main thing you should know before starting the migration database to Azure Cosmos DB for Mongo – don’t ever do this!!! Strapi and Azure Cosmos DB for Mongo are almost incompatible. Actually, I still don’t understand what Azure Cosmos for Mongo is compatible with.

It doesn’t support a lot of operators and expressions that Strapi uses. For example: $let, $where, $meta and others. I have made a migration and faced indexing problems and a lot of unsupported operators. After a huge amount of work was done and after most of the problems were fixed, it finally started to work together. But when I updated the Strapi to the new version, I got one thousand additional problems. And finally, official representatives of the company Strapi gave me the answer:

Technically CosmosDB is not entirely MongoDB (even with the API implemented) It's not on the list of supported databases, and may not fully work with the ORM being used (mongoose).

Moreover, it has a complicated way to take backups. The system takes snapshots, but you can't get them immediately. Firstly you need to create a support request for the Microsoft Support team. It can be done manually in 2 minutes in Mongo Atlas. Just select the required snapshot and click the restore button. Looks much simpler, doesn't it?

Don't waste time fixing problems, there is an easy way to avoid them. If your target is just to speed up the application, use Mongo Atlas for hosting the database and select the Azure cloud provider and the region closest to your customers. In case you need more options for regions, backup settings and some other benefits, learn about dedicated cluster tier features.

If Mongo Atlas cluster is hosted on Azure servers, most of the requests will not go over the public network, they will use the Azure backbone network instead. Which is more secure and the fastest way to deliver the data.

In the end, we have two applications moved to Azure and Mongo DB hosted on the Mongo Atlas. It is the optimal solution for my purposes. But be ready to read more about Azure, believe me, you will definitely need it.

From zero to one. How to Deploy your MongoDB, Node, Strapi, NextJS app to Microsoft Azure.

Chuiko Liliia — Wed, 29 Dec 2021 15:18:26 +0000

Part 1. Introduction and creating all required for migration resources.

Introduction

Hi to everyone! This article will be helpful if you have little or no knowledge of cloud technologies.

There are three main cloud providers: Google Cloud, AWS and Azure. Let’s imagine that your task is to move the application to Azure.

Before continuing, note that the best way to familiarize with basic Azure cloud features, to gain a foundational knowledge of cloud services, and the way those services are provided with Microsoft Azure is to learn and pass Exam AZ-900: Microsoft Azure Fundamentals. The exam is for candidates who are just beginning to work with cloud-based solutions and services or are new to Azure. Azure Fundamentals can be used to prepare for other Azure role-based or specialty certifications, but it is not a prerequisite for any of them. All Microsoft Azure learning has two options: online, which is always free, and instructor-led, which is paid. Passing the exam and getting the certification is always paid. The price depends on the country. One more tip: learn it before migration because learning during the process is a bad idea. There is much to say about passing Microsoft exams, but I suggest we move on to the next step and explore the project structure.

Project structure and reasons for migration to Azure

So, let’s do a deep dive into the project structure before moving on.

Front-end: NEXT.js app, hosted on Vercel.
Back end: Strapi CMS + custom node scripts, hosted on Heroku
DB: Mongo db hosted on Mongo Atlas

The common problems with current providers include:

No simple ways to spread application to multiply regions and elastically scale the capacity based on demand.
No static inbound and outbound IP addresses (only via proxy), which I needed to secure back-end and DB connections.
No obvious ways to give separate accesses to resources, based on roles.

First steps to start to work with Azure, regardless wich computing services you choose to host applications

Firstly go to Microsoft Azure Portal and create the account. After you complete the registration, you will have a single tenant ID associated with your account, which will not change unless you ask Microsoft to delete your account. Tenant is associated with a single identity (person, company, or organization) and can own one or several subscriptions. At this step you will only have one subscription. An Azure subscription is a logical container used to provision resources in Azure. It holds the details of all your resources like virtual machines (VMs), databases, and more. When you create an Azure resource like a VM, you identify the subscription it belongs to. A subscription is linked to a payment setup and each subscription will result in a separate bill and can use different payment methods. Resources from one subscription are isolated from resources in other subscriptions.

During the registration in Azure you may choose to get 200$ dollars on balance of the default subscription that you can spend on Azure services. It is a very useful option for beginners in cloud technologies to test different options.

Now you are signed in, have a tenant and one subscription inside it. The next step is to decide which Azure services to use for your apps hosting.

Choose the appropriate Azure services

Azure offers three main cloud computing platform services: SaaS (Software as a Service), IaaS (Infrastructure as a Service), PaaS (Platform as a Service). The main differences and maintaining levels are displayed on the diagram below:

If you don’t want to be responsible for the operating system, data, runtime and middleware, but still need to manage and configure the application, the PaaS cloud computing service is a good choice.

So, PaaS — it is where Azure provider hosts the hardware and software on its own infrastructure and delivers this platform to the user as an integrated solution, solution stack, or service through an internet connection, while the developer is allowed to develop, run, and manage his own apps without having to build and maintain the infrastructure or platform usually associated with the process.

When we have decided which cloud computing service to use, let's proceed to the next step.

Creating required resources

The next step is to create the App Service Plan and the Resource Group.

An App Service Plan, in two words, at a very high level is just the container in which your web applications run. It is used to determine the resources available to your application (or applications) and their boundary. Comparing this to an on premises environment, the app service environment is one server or servers on which your application is deployed. The app service plan defines what configuration of hardware your app runs on and how many servers you have. You can deploy multiple web applications inside the same App Service Plan. You do not need a separate web app plan for each web app.

When you create an App Service plan in a certain region (for example, Western Europe), a set of compute resources is created for that plan in that region. Whatever apps you put into this App Service plan run on these compute resources as defined by your App Service plan.

A resource group is a logical container into which Azure resources like web apps, databases, and storage accounts are deployed and managed. The Resource Group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.

Steps to create App Service Plan with Resource Group simultaneously:

Type App Service Plan in the search bar, select it from the dropdown and click +Create new.

Now you need to configure it. As you don’t have the Resource Group yet, press create new, enter its name, and it will be created with the App Service Plan and placed inside it. Some other tips:
Enter the App Service Plan name that will clearly describe group of resources inside it (for example, name of the project or of the group of projects) select the region (the better option is to choose the closest region to your customers' location because it will affect the latency)
Select operating system to run your apps, in this case Linux was selected
Select the pricing tier. You can choose from dev/test or production plans. But in case you want to configure automatic deployment from GitHub, choose the P1V2 or higher pricing tier. The application plans less than P1V2 have a list of limitations. The next features are not available:

a) Auto-scale feature. Autoscale is a built-in feature of Cloud Services, Mobile Services, Virtual Machine Scale Sets, and Websites that helps applications perform their best when demand changes.
b) Daily backups. Here, probably, nothing to explain.
c) Traffic manager improves performance and availability by routing traffic between multiple instances of your app.
d) Staging slots. Useful for testing and deployments before swapping them into production.

If you want to create a high volume of resources in the future, use tags. Azure tags are name-value pairs that are used to organize resources in Azure Portal. You can apply tags for individual resources or tag the resource group that they are part of.

Press Review and create. It can take up to 10 minutes.

App Service Plan and the Resource Group are ready to place resources inside. That’s why we can proceed to the next steps.

Creating instances for applications

As PaaS was selected, we should search among its services. The appropriate service is App Service. It enables you to build and host web apps, mobile back ends, and RESTful APIs in the programming language of your choice without managing infrastructure. It offers auto-scaling and high availability, supports both Windows and Linux, and enables automated deployments from GitHub, Azure DevOps, or any Git repo.

To create the App Service find this category in the search bar and press +Create.
You will be redirected to this service configuration page. You need to select from the dropdown the subscription on the resource group, where it needs to be located. Put the name of the application (for example my-project-back-end-development).
In the Publish tab select Code option if you are going to just put the code of your project instead of the ready Docker container. It will make Azure create the Docker container for you itself and run your application inside it.
Select Node from the dropdown of runtime stack.
The application region and operating system will be chosen automatically, according to your App Service Plan settings.
Press next and in the Monitoring section I fully recommend you to switch on Application Insights. It allows you to automatically monitor your application. It will automatically detect performance anomalies and includes powerful analytics tools to diagnose issues and to understand how users actually use your app. It's designed to help you continuously improve performance and usability. It works for apps on various platforms, including .NET, Node.js, Java, and Python hosted on-premises, hybrid, or any public cloud. It integrates with your DevOps process and has connection points to various development tools. All other settings, at this moment, let's keep by default. Click create and review, check if all settings are correct, and confirm. It can take up to 5-10 minutes.

The instance for hosting the back-end is ready, and you can reproduce previous steps to create a separate App Service instance for the front-end application. Once it is ready we go to the next part.

Creating instances for database

As mentioned, MongoDB is used in the project. Azure has an opportunity to place MongoDB using the Azure Cosmos DB's API for MongoDB. It has some limitations. With the full list of supported operators and limitations or exceptions you can familiarize by the link; To create DB go to Azure Cosmos DB Resource and click on Create Azure Cosmos DB account. On the next screen select Azure Cosmos DB API for MongoDB.

The instance for hosting the database is ready, and you As on previous steps, select subscription and resource group, enter the database name. Select the location closest to the rest of your resources and customers to decrease the requests time. Select the Mongo version.

Choosing the capacity mode of the instance is an important step to save your money. You need to know the differences between these two options. Provisioned has throughput at a constant rate, regardless of whether operations are being performed on our Cosmos DB account. Serverless Mode — we only use throughput when operations are performed on our Cosmos DB resources. Each of these options has pros and cons and if you want to know more, follow the link. But in two words, serverless — pay only when using, provisioned — reserve capacity for the instance and pay for it all the time. I need to highlight that it is cheaper to use the serverless mode for non-highly loaded projects. Press the create button and wait until it is ready.

Summary

Let’s check what we have at the moment. You can find all the created instances in your resource group on Azure Portal. Each of the application instances are already available with the Microsoft example page by the url, which you can find in the app essentials section. Cosmos db account is ready for moving your database into it.

Now all resources are ready to deploy your applications and database. The next part of the article is going to be about the migration processes and how to connect all instances. Make sure you read both parts of the article and then proceed to work because we will talk about database migration in the next steps.