Architecture#
Components#
Mainflux IoT platform is comprised of the following services:
| Service | Description |
|---|---|
| auth | Manages platform's orgs and auth concerns |
| users | Manages platform's users and auth concerns |
| things | Manages platform's things, channels, groups and access policies |
| http-adapter | Provides an HTTP interface for accessing communication channels |
| mqtt-adapter | Provides an MQTT and MQTT over WS interface for accessing communication channels |
| coap-adapter | Provides a CoAP interface for accessing communication channels |
| lora-adapter | Provides a LoRa Server forwarder for accessing communication channels |
| mainflux-cli | Command line interface |
Domain Model#
The platform is built around 5 main entities: users, orgs, groups, things and channels:
User: represents users of the system via e-mail and password, which he uses as platform access credentials in order to obtain an access token. Once logged into the system, user can manage his resources in CRUD fashion and define access control policies with orgs and groups roles.
Orgs represents an organisation of users with different roles that allow to invite users and create groups. The creator has owner role and can invite other users and give them admin, editor or viewer roles. admin can invite other users, create groups and access any organisation one. editor can't invite users and can create groups but to access others groups he has to be previously invited. Finally, viewer can only access others groups if he was previously invited.
Thing represents devices of the system.
Channel represents a communication channel defining the profile of a at least one device. It allows to configure messages payload format and data consumption (storage, rules engine, notifications and webhooks).
Groups represents a group of things and channels with member roles access control.
Messaging#
Mainflux uses NATS as its messaging backbone, due to its lightweight and performant nature. You can treat its subjects as physical representation of Mainflux channels, where subject name is constructed using channel unique identifier.
In general, there is no constrained put on content that is being exchanged through channels. However, in order to be post-processed and normalized, messages should be formatted using SenML.
Edge#
Mainflux platform can be run on the edge as well. Deploying Mainflux on a gateway makes it able to collect, store and analyze data, organize and authenticate devices. To connect Mainflux instances running on a gateway with Mainflux in a cloud we can use two gateway services developed for that purpose:
Unified IoT Platform#
Running Mainflux on gateway moves computation from cloud towards the edge thus decentralizing IoT system. Since we can deploy same Mainflux code on gateway and in the cloud there are many benefits but the biggest one is easy deployment and adoption - once the engineers understand how to deploy and maintain the platform, they will have the same known work across the whole edge-fog-cloud continuum. Same set of tools can be used, same patches and bug fixes can be applied. The whole system is much easier to reason about, and the maintenance is much easier and less costly.