|
4 years ago | |
---|---|---|
.. | ||
test | 4 years ago | |
README.md | 4 years ago | |
discover.js | 4 years ago | |
index.js | 4 years ago | |
package.json | 4 years ago | |
publish.js | 4 years ago |
The @joystream/service-discovery
package provides an API for role services to publish
discovery information about themselves, and for consumers to resolve this
information.
In the Joystream network, services are provided by having members stake for a role. The role is identified by a worker id. Resolving service information associated with the worker id is the main purpose of this module.
This implementation is based on IPNS as well as runtime information.
The discovery workflow provides worker id to the discover()
function, which
will eventually return structured data.
Under the hood, discover()
the bootstrap nodes from the runtime are
used in a browser environment, or the local ipfs node otherwise.
There is a distinction in the discovery workflow:
Web services providing the HTTP endpoint used in the first approach will themselves use the second approach for fulfilling queries.
The publishing workflow is a little more involved, and requires more interaction with the runtime and the trusted IPFS node.
Any JSON data can theoretically be published with this system; however, the following structure is currently imposed:
Service specifications are JSON Objects, not Arrays. All service specifications
come with their own version
field which should be intepreted by clients making
use of the information.
Additionally, some services may only provide an endpoint
value, as defined
here:
version
: A numeric version identifier for the service info field.endpoint
: A publicly accessible base URL for a service API.The endpoint
should include a scheme and full authority, such that appending
swagger.json
to the path resolves the OpenAPI definition of the API served
at this endpoint.
The OpenAPI definition must include a top level path component corresponding to the service name, followed by an API version component. The remainder of the provided paths are dependent on the specific version of the API provided.
For example, for an endpoint value of https://user:password@host:port/
the
following must hold:
https://user:password@host:port/swagger.json
resolves to the OpenAPI
definition of the API(s) provided by this endpoint.https://user:password@host:port/XXX/vYYY
where
XXX
is the service name, identical to the field name of the service spec
in the published service information.YYY
the version identifier for the published service API.Note: The version
field in the spec indicates the version of the spec.
The YYY
path component above indicates the version of the published OpenAPI.
Publishes version
and endpoint
as above; the version
field is currently
always 1
.
Publishes version
and endpoint
as above; the version
field is currently
always 1
.
{
"asset": {
"version": 1,
"endpoint": "https://foo.bar/"
},
"discovery": {
"version": 1,
"endpoint": "http://quux.io/"
}
}
Here, the following must be true:
https://foo.bar/swagger.json
must include paths beginning with https://foo.bar/asset/vXXX
where XXX
is the API version of the asset API.https://quux.io/swagger.json
must include paths beginning with https://foo.bar/discovery/vYYY
where XXX
is the API version of the asset API.