azure-signalr
azure-signalr copied to clipboard
Change message protocol with Azure Management SDK
Hi,
I have a question regarding Microsoft.Azure.SignalR.Management
package.
Is there a way to change the protocol (MessagePack, NewtonSoftJson, Protobuf, ...) ? (like with a 'classic' SignalR client)
After reading the code, it seems that, when we create a HubContext with CreateHubContextAsync
there is a hardcoded AddSignalRCore()
so we cannot add protocol options.
https://github.com/Azure/azure-signalr/blob/6faf565144c0bacc31d001cda3c2ca3dbc78602b/src/Microsoft.Azure.SignalR.Management/ServiceManager.cs#L55
Is there a way change the default serialisation protocol when using SignalR Management SDK ? If no, do you plan to add it as a new feature ? Do you want a PR to be able to add options to SignalR Management ?
Thanks !
SignalR only support json and messagepack. When you use Management SDK, SignalR client support both json and messagepack. There's no chance to change serialisation protocol. But add it as a new feature is a great idea. We welcome any PR, thanks.
Thanks for your answer ! With the current Mamangement SDK how can I switch from Json to MessagePack ? When I create a hub context there is no options to choose MessagePack as the message protocol. Thanks
The management sdk always use MessagePack to send messages, the signalr service will convert to the correct protocal (only support json/messagepack) to the signalr client. So the only thing you need to care about is the signalr client's protocol. For example, you can try to use MessagePack in signlar client
// message pack
var connection = new HubConnectionBuilder().WithUrl(url).AddMessagePackProtocol().Build();
// json
var connection = new HubConnectionBuilder().WithUrl(url).Build();
and use a management sdk to send message, you will see both can receive messages.
For other protocols, I think add a ProtocolProvider to management sdk is fine. When use protocols other than json/messagepack, the sianglr service will not recoginize special messages like close messages. But management sdk doesn't design to support it, so its ok to simply add a ProtocolProvider in management sdk.
This will be great to have this feature implemented. The issue we have faced on our side is that API app uses CamelCase naming strategy by default for response serialization. We use Azure SignalR Management package to push notifications to UI app, but the payload is serialized with PascalCase naming. This can be customized by using JsonObjectAttribute, but this is possible only for a root-level object, inner objects are still serialized using PascalCase naming strategy, which leads to inconsistency in naming on UI as well inability to reuse some core models (e.g. classes that hold error or user info). It will be great if we have the ability to provide JsonSerializerOptions when creating a hub context.
@dmitrykarnitski As a workaround you could set a global default serializer settings for Newtonsoft.JSON in your startup file:
JsonConvert.DefaultSettings = () => new JsonSerializerSettings
{
ContractResolver = new CamelCasePropertyNamesContractResolver()
};
Not exactly what the requester wanted, but since some posts in this thread are about JSON serialization in Microsoft.Azure.SignalR.Management, I posted here too. The problem is that the content of the requests sent to the SignalR REST API get serialized with the default settings.
I created the PR https://github.com/Azure/azure-signalr/pull/1196 that allows the change of the JSON serialization settings.
When the PR gets accepted (and a new version gets released), it will work like that:
_serviceManager = new ServiceManagerBuilder().WithOptions(options =>
{
options.ConnectionString = connectionString;
options.JsonSerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver(); // The PR allows to change serialization settings
}).Build();
Update: Now the latest SDK version supports customizing JSON and MessagePack hub protocol. See the guide here: https://github.com/Azure/azure-signalr/blob/dev/docs/management-sdk-guide.md#transport-type