Encode App server's MQTT messages with protobuf

ChirpStack Application Server
1

I have noticed that there is an option in the bridge to encode MQTT messages using protobuf. Are there plans on doing the same for application server and network server? The benefit would be not only efficiency, but one could generate the client code in number of languages.

2

bumping this…

3

The APIs are already using gRPC which uses Protobuf (the LoRa App Server component provides this API also as RESTFul JSON api for convenience) :slight_smile: Only the device events published over MQTT / HTTP by LoRa App Server are in JSON.

You’ll find the .proto files here:

4

thanks for response, but integrating over MQTT has the benefit of storing the messages on the broker, so e.g. during my app restarts I won’t lose any messages. So far I’ve wrote the JSON deserialization based on models.go, it’s not a big issue, just thought it would be more convenient and also performant.

5

For the MQTT messages (integrations in general) this might be an option for the future. I was not sure what you were referring to:

Are there plans on doing the same for application server and network server?

I first need to re-model these messages to .proto based messages in a backwards compatible way before I can add this option. I’ll keep this in mind!

1 Like
6

yeah I was under the impression that I could get frames from NS via MQTT, that’s why I included it in my question. So I will have to use gRPC API anyway, but this might be suggestion for another feature/improvement :slight_smile:

1 Like
7

If you’re gauging interest in protobuf-over-MQTT as an additional marshaler to App Server’s default JSON, we would be interested in this, as well. We are currently consuming from the gateway/# topic as protobuf, but unmarshaling JSON for devices from application/#.

8

This might be a bit more challenging as the JSON format depends also on the codec function, so it could be different per application. Ideally with Protobuf the model is fixed so that all the fields can be typed.

9

Good point. I was thinking of the case where a codec has not been configured, and the end service only cares about receiving the decrypted []byte data field.

It would be nice to save the costs of unmarshaling JSON and decoding base64, and just decode a protobuf instead.