Data Microservice

Step 7. Running and testing the microservice

To run our microservice, we need to add just one last bit of code. In the bin folder, create a run.js file with the following:


let BeaconsProcess = require('../obj/src/container/BeaconsProcess').BeaconsProcess;

try {
    let proc = new BeaconsProcess();
    proc._configPath = "./config/config.yml";;
} catch (ex) {

In the code above, all we’re doing is creating an instance of the container we described earlier, telling it where to find the configuration file, and running it using the run() method.

To run the microservice, execute the following command from a terminal at the root of the project:

 node ./bin/run.js

You should get a result similar to the one shown below.

Since we opted for the console logger in our configuration file, all information is going to be printed to the console. The service is using the in-memory persistence by default. To switch over to the MongoDB persistence, the MONGO_ENABLED environment variable has to be set and MongoDB should be running. This can be done either by starting the service from a script, in which we set our environment variables beforehand, or by configuring them in the OS’s environment.

Let’s use the following two commands to set our environment variable and start our microservice using the MongoDB persistence:

export MONGO_ENABLED=truenode .\bin\run.js

Make sure that you have MongoDB running locally (see [Environment Setup]) or in an accessible Docker container (i.e. whose ports are exposed), and that the connection parameters set in the configuration file are correct.

We can use the following docker composer configuration to run MongoDB in Docker:


version: '3.3'


    image: mongo:latest
      - "27017:27017"

And use the following command to get it up and running:

docker-compose -f ./docker/docker-compose.yml up

Once the microservice has started, we can check whether or not it is available by requesting the following URL from a browser: http://localhost:8080/heartbeat. If everything is working correctly, we should receive the current date and UTC time in the JSON format. This mechanism allows us to check whether or not our microservice is up and running at any given time.

Now let’s request the status URL from our browser: http://localhost:8080/status. This should generate a response with information about the service in a JSON format, such as: its name, what modules are loaded, etc. This mechanism allows us to identify our microservices while they’re running.

  "id": "microservice-server",
  "name": "beacons",
  "description": "Beacons microservice",
  "start_time": "2020-06-11T10:48:03.623Z",
  "current_time": "2020-06-11T10:49:19.777Z",
  "uptime": 76154,
  "properties": {},
  "components": [

Let’s move on to testing the main functionality of our microservice. Our set of commands for working with the service is available at the base path of http://localhost:8080/v1/beacons, using the POST method.

We could use a REST client to test our microservice, but for the sake of this example, we’ll be using curl instead.

Let’s check the availability of our commands - the very same ones we defined in our CommandSet:

First, we’ll attempt to create a few beacons in the system:

curl -X POST -H "Content-Type: application/json" -d "{\"beacon\":{\"id\": \"1\", \"udi\": \"00001\",  \"type\": \"altbeacon\",  \"site_id\": \"1\",    \"label\": \"TestBeacon1\", \"center\": { \"type\": \"Point\", \"coordinates\": [ 0, 0 ] },\"radius\": 50}}"

curl -X POST -H "Content-Type: application/json" -d "{\"beacon\":{\"id\": \"2\", \"udi\": \"00002\",  \"type\": \"altbeacon\",  \"site_id\": \"1\",    \"label\": \"TestBeacon2\", \"center\": { \"type\": \"Point\", \"coordinates\": [ 2, 2 ] },\"radius\": 70}}"

Update the second beacon by changing its coordinates and radius:

curl -X POST -H "Content-Type: application/json" -d "{\"beacon\":{\"id\": \"2\", \"udi\": \"00002\", \"type\": \"altbeacon\", \"site_id\": \"1\", \"label\": \"TestBeacon2\", \"center\": { \"type\": \"Point\", \"coordinates\": [ 2, 4 ] },\"radius\": 80}}" http://localhost:8080/v1/beacons/update_beacon

Retrieve a list of all available beacons using the command below:

curl -X POST http://localhost:8080/v1/beacons/get_beacons

We should get the following JSON response with all of the beacons currently in the system:


Try to get the first beacon by its UDI using the command:

curl -X POST -H "Content-Type: application/json" -d "{\"udi\":\"00001\"}" http://localhost:8080/v1/beacons/get_beacon_by_udi

We should receive the following response:


To calculate a device’s position, use the following request:

curl -X POST -H "Content-Type: application/json" -d "{\"site_id\": \"1\",\"udis\": [\"00001\", \"00002\"]}" http://localhost:8080/v1/beacons/calculate_position

As a result, we should get the following coordinates:


Now let’s delete a beacon by its id:

curl -X POST -H "Content-Type: application/json" -d "{\"beacon_id\":\"1\"}" http://localhost:8080/v1/beacons/delete_beacon_by_id

The system will return the deleted beacon if deletion was successful:


Let’s make sure that there’s only one beacon left in the system by asking again for a list of all available beacons:

curl -X POST  http://localhost:8080/v1/beacons/get_beacons

As a result, only the beacon with an id of “2” is returned.


And that’s it! Congratulations! You’ve created a microservice that’s far more advanced than the regular “Hello, World” example!
All source code is available on