@ti-engine/core 1.0.6 → 1.0.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +62 -15
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -23,25 +23,72 @@ These are just some benefits **ti-engine** offers. Get to know it better to find
|
|
|
23
23
|
|
|
24
24
|
## prerequisites & installation
|
|
25
25
|
In order to run the basic ti-engine framework you will need a couple of things:
|
|
26
|
-
|
|
27
|
-
|
|
26
|
+
* A local [node.js installation](https://nodejs.org/en/download/) with a minimum version of **14.17.0**
|
|
27
|
+
* A local or remote [Redis cache installation](https://redis.io/download) with a minimum version of **5.0.14**
|
|
28
|
+
|
|
29
|
+
If you are working under Windows OS and you need to install Redis, take a look at this [guide](https://redis.com/blog/redis-on-windows-10/).
|
|
28
30
|
|
|
29
31
|
To get the framework itself, use the command `npm install @ti-engine/core`. And to include it directly in your package.json dependencies execute `npm install @ti-engine/core --save-prod`.
|
|
30
32
|
|
|
31
33
|
## getting started
|
|
32
|
-
To start using the **ti-engine**, you will have to make sure that all prerequisites are available and operational.
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
34
|
+
To start using the **ti-engine**, you will have to make sure that all prerequisites are available and operational. However, before we get to the fun part you need to also consider a couple of very important things while working with this framework:
|
|
35
|
+
1. The runtime configuration of the framework can be customized using ENV variables. These can be provided to node.js in all the standard ways, but there is also an option to include an `.env` file.
|
|
36
|
+
2. It loads your framework-related custom scripts and files dynamically, but it always assumes their provided paths are relative to the _current working directory_ (i.e. it uses `process.cwd()`). Be mindful of that whenever you declare file paths in the various settings.
|
|
37
|
+
|
|
38
|
+
Once you have everything else ready, you should download the **ti-engine** tester module with the command `npm install @ti-engine/tester`. The tester module packages an example microservice that shows the basic approach for using the framework. To make sure everything is working properly, you should try and start the tester service:
|
|
39
|
+
1. Open a command prompt and navigate to the directory of the tester module; it should be something like that:
|
|
40
|
+
`[path to your project]/node_modules/@ti-engine/tester`
|
|
41
|
+
2. Execute the following command `node ../core/bin/start-instance.js`
|
|
42
|
+
3. If everything was done properly, you should see the following output:
|
|
43
|
+
```shell
|
|
44
|
+
[timestamp]: [instance-id] - notice - Starting new instance of type 'tester-service' with instance ID '[instance-id]'.
|
|
45
|
+
[timestamp]: [instance-id] - info - Starting service registration process. There is NO default service handler provided.
|
|
46
|
+
[timestamp]: [instance-id] - info - Registration of defined services completed with 2 successful out of 2 total.
|
|
47
|
+
[timestamp]: [instance-id] - notice - Instance '[instance-id]' started successfully.
|
|
48
|
+
[timestamp]: [instance-id] - info - Connection to Redis server 127.0.0.1:6379 (re)established by client 'connection-msg-responses-out' and is ready to be used.
|
|
49
|
+
[timestamp]: [instance-id] - info - Connection to Redis server 127.0.0.1:6379 (re)established by client 'system' and is ready to be used.
|
|
50
|
+
[timestamp]: [instance-id] - info - Connection to Redis server 127.0.0.1:6379 (re)established by client 'connection-msg-requests-in' and is ready to be used.
|
|
51
|
+
[timestamp]: [instance-id] - info - Connection to Redis server 127.0.0.1:6379 (re)established by client 'connection-msg-requests-out' and is ready to be used.
|
|
52
|
+
[timestamp]: [instance-id] - info - Connection to Redis server 127.0.0.1:6379 (re)established by client 'connection-msg-responses-in' and is ready to be used.
|
|
53
|
+
[timestamp]: [instance-id] - notice - Execution of service1 result:
|
|
54
|
+
{ exception: undefined, isSuccessful: true, payload: { s1Timestamp: [timestamp] } }
|
|
55
|
+
[timestamp]: [instance-id] - notice - Execution of service2 result:
|
|
56
|
+
{ exception: undefined, isSuccessful: true, payload: { s1Timestamp: [timestamp], s2TimestampStart: [timestamp], s2TimestampEnd: [timestamp] } }
|
|
57
|
+
```
|
|
58
|
+
Now let's analyse that output. For the sake of completeness, the `[timestamp]` and `[instance-id]` are placeholders of the actual values you'll see there. The timestamps are in UTC and show a date followed by time.
|
|
59
|
+
|
|
60
|
+
At the start of the output log you can see a NOTICE that tells you a couple of important things:
|
|
61
|
+
* The instance name - in this case `tester-service`. In the terminology of the framework, this is also known as a _service domain name_.
|
|
62
|
+
* The _instance identificator_. It is an uuid string with a `ti-` prefix, that is generated by the framework at process start. It can and will be used to trace the messages during their movement through the microservice ecosystem. But more on that later.
|
|
63
|
+
|
|
64
|
+
Following that come a couple of INFO lines that inform you about the microservice interface state. The framework starts with the process of registration of _business services_ within the service domain of the microservice `tester-service` and successfully adds 2 such services. The necessary information for this is read from a JSON config file included in the package. We'll get into more details on what this all means in the section [creating a microservice](#creating-a-microservice).
|
|
65
|
+
|
|
66
|
+
Once the initialization sequence has completed the framework informs you that the microservice instance has started successfully. If the framework encountered an error during initialization instead, you would see something like this:
|
|
67
|
+
```shell
|
|
68
|
+
[timestamp]: [instance-id] - notice - Starting new instance of type 'tester-service' with instance ID '[instance-id]'.
|
|
69
|
+
[timestamp]: [instance-id] - alert - Error detected in the instance startup script!
|
|
70
|
+
```
|
|
71
|
+
The following 5 lines inform you about the successful connection to Redis. The default configuration assumes that your Redis is running on localhost and uses the default port. If you have a different setup, you can provide the host and port via ENV variables. We'll cover that in the section [using the framework](#using-the-framework).
|
|
72
|
+
|
|
73
|
+
Finally, you should see a couple of execution statements with their results in JSON format.
|
|
74
|
+
|
|
75
|
+
You can now kill the node process which should show you the following two lines:
|
|
76
|
+
```shell
|
|
77
|
+
[timestamp]: [instance-id] - notice - SIGINT event detected in main instance process.
|
|
78
|
+
[timestamp]: [instance-id] - notice - Instance '[instance-id]' shut down successfully.
|
|
79
|
+
```
|
|
80
|
+
The framework will always try to capture the shut-down event and log it. This should work even in container environment, but it might depend on your setup whether the last two entries will reach the logging system or not.
|
|
81
|
+
|
|
82
|
+
The tester module gets its starting configuration from an `.env` file included in the package. If you open it, this is what you'll see:
|
|
83
|
+
```shell
|
|
84
|
+
TI_INSTANCE_CLASS=tester-service.js
|
|
85
|
+
TI_INSTANCE_CONFIG=tester-service.json
|
|
86
|
+
TI_INSTANCE_NAME=tester-service
|
|
87
|
+
TI_LOG_MIN_LEVEL=200
|
|
88
|
+
```
|
|
89
|
+
The first variable `TI_INSTANCE_CLASS` is mandatory for every microservice you create with the **ti-engine**. It needs to specify the path to the module that is your microservice. Remember, that this path has to be relative to the working directory in which you plan to execute the `node` command. This is especially important when you're configuring your microservices to work in containers. You can find the full list of available ENV variables and what they do below.
|
|
90
|
+
|
|
91
|
+
Before moving on, also take a good look at the file `bin/start-instance.js`. It should give you an idea on how to the process of starting and stopping a microservice operates. In most cases this file should be sufficient as a starting script for your **ti-engine** based microservice applications. You can, of course, create your own starting script, but then you'll have to consider all necessary steps to properly handle the microservice instance.
|
|
45
92
|
|
|
46
93
|
## architecture
|
|
47
94
|
Under development...
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ti-engine/core",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.7",
|
|
4
4
|
"description": "The ti-engine is an open source, free to use - both for personal and commercial projects - framework for the creation of microservice-based solutions using node.js.",
|
|
5
5
|
"author": "Boris Kostadinov <kostadinov.boris@gmail.com>",
|
|
6
6
|
"license": "ISC",
|