npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@thingweb/async-api-converter

v1.0.0

Published

Provides AsyncAPI instance generation for WoT Thing Descriptions

Downloads

85

Readme

Eclipse Thingweb - TD to AsyncAPI Converter

The package provides support for AsyncAPI instance generation (output as json or yaml), using a Thing Description (TD) as input.

Usage

You can use this package to integrate AsyncAPI instance generation from a TD in your application.

  • Install this package via NPM (npm install @thingweb/async-api-converter) (or clone the repo, change to node/async-api-converter and install the package with npm install)

  • Node.js or Browser import:

    • Node.js: Require the package and use the functions
const tdToAsyncAPI = require("@thingweb/async-api-converter");
  • Browser: Import the tdToAsyncAPI object as a global by adding a script tag to your HTML.
<script src="./node_modules/@thingweb/async-api-converter/dist/web-bundle.min.js"></script>
  • Now you can convert a TD to an AsyncAPI instance.
tdToAsyncAPI(td).then((AsyncAPI) => {
    console.log(JSON.stringify(AsyncAPI.json, undefined, 2));
    console.log(AsyncAPI.yaml);
});

You can find usage examples in the tests folder, or the [web] and [cli] packages.

License

Licensed under the Eclipse or W3C license, see License.

Limitations

This conversion package should be seen as a first draft. It is currently limited to the MQTT protocol and converting observable properties or subscribable events of a Thing Description instance to channels of an AsyncAPI instance. Furthermore, it converts some general information about the documents, e.g., an id if available. Due to the structure of both specifications, there occur other limitations, e.g., an AsyncAPI document does not allow specifying servers only for some channels or security restrictions for specific channels/operations/messages.

Possible Extensions

Resulting of the current Limitations there are possible extensions for the future:

  • Supporting HTTP:
    Both the TD and the AsyncAPI specification support describing http-based operations but they are doing so in a quite different way, which is the tricky part if one wants to convert from one to another. The Thing Description supports HTTP for asynchronous and synchronous messages. In AsyncAPI, the HTTP protocol is always mentioned to support "HTTP streaming APIs". The specification does not mention certain subprotocols but allows defining HTTP messages (as request/response and with the method) so one way of converting could be to specify necessary messages for every subprotocol. Still, this does probably not represent the real implementations properly.

  • Supporting WebSockets:
    AsyncAPI treats WebSocket connections as independent protocols with given restrictions, e.g., only one WebSocket connection is possible per AsyncAPI instance (because routing channels to certain servers is not possible and WebSocket does not support channels/topics/...). This should be taken into account for the conversion, one promising approach for converting protocols other than MQTT-like, could be to generate one AsyncAPI instance per available server to deal with the in this case more expressive TDs.

  • Adding security support:
    The focus of AsyncAPI is hardly on security (since event-based solutions are often used in closed systems) but still it supports quite some mechanisms. The more complicated part in converting this from TD to AsyncAPI is that TDs support different security mechanisms for every operation, while AsyncAPI allows only defining them per Server (and there is no server-to-channel/operation/message mapping).

  • Add further use cases: Currently, only two types of TD interactions are mapped to their AsyncAPI equivalents:

    • Properties with the op observeproperty indicating that the property can be watched asynchronously

    • Events to which a client can subscribe (subscribeevent)

      But there could be other use cases that should be taken into account, e.g., reading (possible with retain option) variables via MQTT that might not be an asynchronous operation itself but useful to support since MQTT operations cannot be represented with OpenAPI instances.

  • Think about how to treat interactions with the same path (-> same AsyncAPI channel), e.g., a property and an event that both interact with thing.example.com/status

Comments

A TD doesn't necessarily to be valid to be converted to an AsyncAPI instance. This converter will only throw an Error if the invalid part has a strong effect on the conversion result, but tries to ignore the most cases. This is by purpose, since there is the possibility to validate a TD using, e.g., the playground core package and the conversion of experimental TDs for example to create new TD features, should be supported.