cote
Advanced tools
Comparing version 0.20.0 to 0.20.1
@@ -114,2 +114,6 @@ "use strict"; | ||
const timeoutHandle = setTimeout(() => { | ||
// Remove the request from the request queue so that it's not sent to responders (#183) | ||
const req = sock.queue.findIndex(r => r[r.length - 1] == messageCallback); | ||
if (req > -1) sock.queue.splice(req, 1); // Remove the request callback | ||
delete sock.callbacks[messageCallback.id]; | ||
@@ -116,0 +120,0 @@ cb(new Error('Request timed out.')); |
{ | ||
"name": "cote", | ||
"version": "0.20.0", | ||
"version": "0.20.1", | ||
"keywords": [ | ||
@@ -41,3 +41,3 @@ "microservices", | ||
"eventemitter2": "5.0.1", | ||
"lodash": "^4.17.11", | ||
"lodash": "^4.17.15", | ||
"portfinder": "1.0.20", | ||
@@ -44,0 +44,0 @@ "socket.io": "2.2.0", |
@@ -11,2 +11,3 @@ ![cote](https://user-images.githubusercontent.com/698308/32996603-1517088a-cd85-11e7-85c5-8ef9b3ae2e49.png) | ||
[![GitHub license](https://img.shields.io/badge/license-MIT-blue.svg)](https://raw.githubusercontent.com/dashersw/cote/master/LICENSE) | ||
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fdashersw%2Fcote.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fdashersw%2Fcote?ref=badge_shield) | ||
@@ -76,3 +77,2 @@ **cote lets you write zero-configuration microservices in Node.js without nginx, | ||
+ Docker compose configuration for running the system locally | ||
+ Docker cloud configuration for running the system in Docker Cloud | ||
@@ -915,3 +915,3 @@ cote plays very well with Docker, taking advantage of its network overlay | ||
``` | ||
To connect publisher and sockend, you need to add `broadcasts:` parameter to your options | ||
To connect publisher and sockend, you need to add `broadcasts:` parameter to your options | ||
@@ -942,3 +942,3 @@ ```js | ||
You can check complete code for `Responder`s and `Publisher`s in the `examples` folder. Fire them up | ||
You can check complete code for `Responder`s and `Publisher`s in the `examples` folder. Fire them up | ||
on default or 'rnd' namespace and watch them glow with magic on | ||
@@ -1047,12 +1047,28 @@ `http://localhost:5555`. | ||
Since every component discovers and tries to communicate with every other | ||
component on the horizon (this is called a "mesh network"), it might be | ||
desirable to tune the performance of an application by grouping certain | ||
components together over the use of a `key`. | ||
component on the horizon (this is called a "mesh network"), if different | ||
services request and respond to different types of messages, you will | ||
experience lost messages. In other words, if service A responds to messages X | ||
and Y, and service B responds to messages Z and T, you will lose half of the | ||
messages, because messages Z and T will also end up at service A, but it won't | ||
know how to handle them. The same is true for service B: messages X and Y | ||
will end up at it, but service B won't know how to respond to them. | ||
Keys are useful in this scenario: requesters and responders around service A | ||
and messages X and Y should use one particular key, and requesters and | ||
responders around service B and messages Z and T should use another key. In | ||
this case, no messages will be lost, and the services will be segregated. | ||
In our experience, the best way to segregate services is to follow the | ||
principles of domain-driven design. In this regard, for example, each domain | ||
could have its own `key`. | ||
could have its own `key`. If you need more granular services, you should use | ||
multiple keys inside the same domain. The principle is to ensure distinct keys | ||
for a distinct set of messages. In other words, keys should represent a | ||
distinct set of requests. | ||
`key`s are are also given as parameters to the configuration objects. | ||
Please refer to [Creating the arbitration service] | ||
(https://github.com/dashersw/cote#creating-the-arbitration-service) for an | ||
example of keys in action. | ||
`key`s are given as parameters to the configuration objects. | ||
When deciding whether to create a connection to another service, cote components | ||
@@ -1225,3 +1241,2 @@ make use of `key`s and `environment`s together. Therefore, two components with | ||
| `COTE_BROADCAST_ADDRESS` | See [Broadcast address](#broadcast-address). | ||
| `DOCKERCLOUD_IP_ADDRESS` | Default broadcast address in Docker Cloud is `10.7.255.255`. Passing any value to this variable will change default broadcast value from `255.255.255.255` to `10.7.255.255`. This setting shouldn't be changed by users, but rather is there to make cote play extremely well with Docker Cloud. | ||
| `COTE_USE_HOST_NAMES` | In certain, extremely rare conditions, auto-discovery might fail due to components reporting wrong IP addresses. If you find out that is the case, you can command cote to use the reported host names instead. | ||
@@ -1231,2 +1246,3 @@ | `COTE_DISCOVERY_REDIS` | See [Using centralized discovery tools](#using-centralized-discovery-tools). | ||
| `COTE_DISCOVERY_REDIS_HOST` | See [Using centralized discovery tools](#using-centralized-discovery-tools). | ||
| `DISCOVERY_HOSTNAME` | See [Using centralized discovery tools](#using-centralized-discovery-tools). | ||
| `COTE_REQUEST_TIMEOUT` | See [Requester Timeout](#timeout). | ||
@@ -1241,3 +1257,3 @@ | `COTE_LOG` | Boolean. Whether to display hello and status logs for other discovered services. Has precedence over `COTE_STATUS_LOGS_ENABLED` and `COTE_HELLO_LOGS_ENABLED`. | ||
## Deploying with Docker Cloud | ||
## Deploying with Docker Cloud (deprecated) | ||
@@ -1265,5 +1281,5 @@ cote plays extremely well with Docker Cloud. Even if your cloud provider doesn't | ||
cote is built to be zero-configuration, and relies on IP broadcast/multicast | ||
to work. However, as of 2017, cloud providers don't support this functionality | ||
out of the box. In these cases, one can use Docker Cloud and its Weave network | ||
integration. However, Docker Cloud may not be suitable for everyone, due to | ||
to work. cloud providers don't support this functionality (and they won't) | ||
out of the box. In these cases, one can use the Weave network overlay | ||
integration. However, this may not be suitable for everyone, due to | ||
varying reasons. | ||
@@ -1274,3 +1290,3 @@ | ||
In these cases, in order to let cote work, we developed a plugin mechanism to | ||
accomodate different solutions that can serve as the automated service | ||
accommodate different solutions that can serve as the automated service | ||
discovery tool. Currently, redis is supported out of the box, and cote | ||
@@ -1283,2 +1299,6 @@ makes use of the [node_redis](https://github.com/NodeRedis/node_redis) | ||
You should also set `DISCOVERY_HOSTNAME` to the **IP address** | ||
of the container/instance since it defaults to machine's hostname which in | ||
most cloud/docker setups is not routable. | ||
### Configuring redis | ||
@@ -1304,6 +1324,7 @@ | ||
| --------------------------: | :---------- | | ||
| COTE_DISCOVERY_REDIS | If you are running redis on localhost, setting this variable to true will use the locally available redis at port 6379. If you need any other redis URL or host, you don't need to use this variable. | ||
| COTE_DISCOVERY_REDIS_URL | Sets the redis connection URL. Has to start with either `redis://` or `//`. Enables the redis plugin. | ||
| COTE_DISCOVERY_REDIS_HOST | Sets the redis connection host name. Enables the redis plugin. | ||
| COTE_DISCOVERY_REDIS_PORT | Sets the redis connection port. Enables the redis plugin. | ||
| `COTE_DISCOVERY_REDIS` | If you are running redis on localhost, setting this variable to true will use the locally available redis at port 6379. If you need any other redis URL or host, you don't need to use this variable. | ||
| `COTE_DISCOVERY_REDIS_URL` | Sets the redis connection URL. Has to start with either `redis://` or `//`. Enables the redis plugin. | ||
| `COTE_DISCOVERY_REDIS_HOST` | Sets the redis connection host name. Enables the redis plugin. | ||
| `COTE_DISCOVERY_REDIS_PORT` | Sets the redis connection port. Enables the redis plugin. | ||
| `DISCOVERY_HOSTNAME` | This defaults to your machine's `hostname`. If this is not routable you need to set this to the routable IP address of this instance. | ||
@@ -1317,3 +1338,3 @@ cote also supports other connection options supported by | ||
```sh | ||
COTE_DISCOVERY_REDIS_HOST=redis node service.js | ||
COTE_DISCOVERY_REDIS_HOST=redis DISCOVERY_HOSTNAME=127.0.0.1 node service.js | ||
``` | ||
@@ -1374,6 +1395,5 @@ | ||
network. For this purpose, Docker is the best tool. Deploy your application in | ||
Docker containers and you can take advantage of its overlay networks. cote works | ||
out of the box with Docker Cloud and users of Docker Swarm can make use of the | ||
[Weave Net plugin](https://www.weave.works/docs/net/latest/plugin-v2/). Weave | ||
also has [an addon](https://www.weave.works/docs/net/latest/kube-addon/) for | ||
Docker containers and you can take advantage of its overlay networks. Users of | ||
Docker Swarm can make use of the [Weave Net plugin](https://www.weave.works/docs/net/latest/plugin-v2/). | ||
Weave also has [an addon](https://www.weave.works/docs/net/latest/kube-addon/) for | ||
enabling multicast/broadcast for Kubernetes. | ||
@@ -1423,1 +1443,3 @@ | ||
SOFTWARE. | ||
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fdashersw%2Fcote.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fdashersw%2Fcote?ref=badge_large) |
Sorry, the diff of this file is not supported yet
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
196612
1007
1431
10
Updatedlodash@^4.17.15