Generating Core Services

CX Cloud provides selected ready-made (Node.js) core services (e.g. commerce, content, search, authentication) which can be generated and added to the project using CX Cloud CLI. These can, of course, be customized later on.
Requirements
It is required to use a monorepo structure in order to deploy all microservices with CI/CD pipeline. More information about monorepo development strategy can be found here.
Service generation
You can start by creating a new folder for a new service in monorepo packages folder, for example:
1
my-monorepo
2
├── packages
3
|   ├── package-commerce
4
|   |   ├── .cxcloud.yaml
5
|   |   └── ...
6
└── ...
Copied!
Then navigate inside the newly created folder and start service generation by running the following commands:
1
$ cd package-commerce
2
$ cxcloud generate service
Copied!
You will go through a number of questions and get to choose which service to create.
To enable ready-made functionality for services, CX Cloud provides a set of core modules that can be used when generating services. To enable the desired level of granularity, one can use multiple core modules for one service or create multiple services based on the same core module. It should be noted that if generating service with multiple core modules, some services might conflict with each other. In this case, you will get a warning. Example of such conflict is Commerce and Auth services. Commerce includes own authentication service, making Auth in this case redundant.
Currently CLI supports the following core modules:
Commerce (commercetools)
Content (Contentful)
Auth (AWS Cognito)
Search (Algolia)
Configuration
After you have generated the service, it's time to provide it with configurations.
Create a .env file in the root directory of the monorepo and add environment-specific variables on new lines in the form NAME=VALUE. For example:
1
CONTENTFUL_API_KEY=12345
2
CTP_CLIENT_ID=qwerty-567
3
AUTH_URL=https://auth.example.com
4
...
Copied!
Do Not commit sensitive information such as API keys to GitHub or other versioning systems. Make sure the .env file is included in .gitignore of the root folder.
In order to provide a consistent configuration interface to the services, which can be extended and overridden during further development, the configurations are stored in configuration files within the service. For these purposes, we are using node-config. The generated with CLI services are already prepackaged with node-config and basic configuration files. Among other settings, the configuration files include references to the environment variables which are loaded from .env file into process.env. Documentation for node-config can be found here.
The configurations below are used in CX Cloud Demo and can be copied and modified in default configuration file config/default.js of generated service.
Example configuration for Commerce:
1
"store": {
2
    "defaultCurrency": "EUR",
3
    "supportedCurrencies": ["EUR", "USD", "GBP"]
4
},
5
"commerceTools": {
6
    "authHost": `${process.env.CTP_AUTH_URL}`,
7
    "apiHost": `${process.env.CTP_API_URL}`,
8
    "projectKey": process.env.CTP_PROJECT_KEY,
9
    "admin": {
10
        "clientId": process.env.CTP_CLIENT_ID,
11
        "clientSecret": process.env.CTP_CLIENT_SECRET
12
    },
13
    "user": {
14
        "clientId": process.env.CTP_USER_CLIENT_ID,
15
        "clientSecret": process.env.CTP_USER_CLIENT_SECRET
16
    }
17
}
Copied!
Example configuration for Content:
1
"contentful": {
2
    "sdkConfig": {
3
        "space": process.env.CONTENTFUL_SPACE_ID,
4
        "accessToken": process.env.CONTENTFUL_DELIVERY_API_TOKEN
5
    }
6
}
Copied!
Example configuration for Auth:
1
"cognito": {
2
    "userPoolId": process.env.USER_POOL_ID,
3
    "clientId": process.env.CLIENT_ID,
4
    "encryptionKey": process.env.ENCRYPTION_ID
5
}
Copied!
Example configuration for Search:
1
"algolia": {
2
    "applicationId": process.env.ALGOLIA_APPLICATION_ID,
3
    "apiKey": process.env.ALGOLIA_API_KEY
4
}
Copied!
CXCloud does not provide any testable configurations for 3rd party solutions. You must get test account or purchase licenses for selected services and set them up yourself.
Local test
After generation is finished and configurations are set, the generated service will be working as a single API. To test locally, run the following set of commands at the root of your repository with the service:
1
$ npm install
2
$ npm run build
3
$ npm run start
Copied!
It will install all required npm packages, build your Swagger documentation and start the local server for you to be able to test your configurations. Swagger provides an interface for testing right in the browser.
In case of commerce service and default settings, you should be able to see Swagger API documentation at http://localhost:4003/api/commerce/v1/api-docs
Deployment
CI/CD pipeline handles the deployment of microservices within the monorepo. Therefore, CI/CD pipeline should be set up and configured prior deployment of the services. More information about CI/CD pipeline configuration and monorepo settings for deployment can be found here.
When applications is deployed, all sensitive information such as keys, secrets or tokens are stored as Kubernetes secret object in the intended namespace. You can find an example of using Kubernetes' secrets to configure your project here.
Routing
After deployment, you can make your service available to the world using a Routing Manifest.
Commit
As a final step, add git remote origin corresponding to your monorepo and commit changes to your Github repository by running the following commands:
1
$ git remote add origin https://github.com/user/my-monorepo.git
2
$ git add .
3
$ git commit -m "initial commit"
4
$ git push
Copied!
Provision Infrastructure
Generating a Frontend Demo
Last modified 2yr ago
Copy link
Contents