-
Notifications
You must be signed in to change notification settings - Fork 227
Packages
The Azure IoT SDK for Node.js covers 2 types of applications:
- Server-side applications (that manage devices or handle messages coming from devices for example)
- Device-side applications (running on connected objects that send and receive data from your IoT hub)
- Tools that can be used by the customer to explore features or diagnose issues when connecting to Azure IoT Hub.
There is code that can be shared between the service side and the device side. Errors, some protocol-layer code, etc. That's why there are 3 "common" packages used by the device and the service side:
-
azure-iot-common: contains all the logic and objects used across the SDK and not specific to any transport. -
azure-iot-amqp-base: contains the AMQP code that can be reused on the device and the service side. -
azure-iot-http-base: contains the HTTP code that can be reused on the device and the service side.
On top of these common packages, each SDK has multiple packages that separate responsibilities:
-
azure-iot-device: contains the client code -
azure-iot-device-amqp: contains the AMQP transport class that is specific to devices and support AMQP and AMQP over Websockets -
azure-iot-device-mqtt: contains the MQTT transport class that is specific to devices and support MQTT and MQTT over Websockets
-
azure-iothub: contains the whole service SDK
Why separate the transport on the device side but not the service side?
That's because device can be memory-constrained and we want as little packages and dependencies as possible installed on it. That is not as much the case on the service side.
Also, while the device has only one client that can use only one transport, the service has multiple clients (Client, Registry...) and each
depend on a specific transport, so separating the client from its mandatory transport could be error-prone for customers.
iothub-explorer can be used to explore features of IoT Hub, manage devices and test messaging features during development.
The easiest way to use iothub-explorer is to install the npm package globally.
If you'd like to clone the source code and maybe contribute to the project, the repository is here
iothub-diagnostics can be used to diagnose connectivity issues with your Azure IoT hub. Running it will tell you what kind of connectivity
issues it finds (if any) and what protocols can be used within your firewall.
If you'd like to clone the source code and maybe contribute to the project, the repository is here
The Azure IoT SDK for Node.js follows semantic versioning rules (see http://www.semver.org). It means the SDK version numbering is driven by the type of changes that we introduce and not marketing or date/time.
Within a version of the SDK, internal dependencies (from one package to another) are fixed to a specific version.
We sometimes release preview packages: the version numbers have a suffix (eg. -dmpreview.x) and are tagged with the suffix. The preview packages
are not tagged latest: only stable packages are. Therefore if you want to install preview packages, you have to use the tag or the specific version nubmer.
Occasionally we may want to deprecate an API: when this is the case we will mark it as @deprecated in the documentation, and we will remove it at the next
major version bump.
Breaking Changes Policy
Our policy is as much as possible to never introduce breaking changes. If we ever do, we will bump the major version number. This being said, the definition of breaking change can vary from one person to the next, and we are not exempt from making mistakes: if you ever encounter a breaking change that didn't come with a major version bump, please do let us know, it's likely a bug (unless it's a bugfix and even then).
We do have a comprehensive testing policy that should prevent such an eventuality.