Hi Team, happy to return back.
I would much appreciate some advice and directions on the preferable ServiceStack technologies, in the following architecture.
Client = Flutter on web (page will be hosted in the ServiceStack API)
Server = ServiceStack API (.net core) preferable in Azure AppService (alternatively classic Cloud Service )
Message Broker = Redis (between Server and other services)
Server will get messages from Redis (posted from the back-end services) and send them to the Clients.
2.Client will make API calls (commands ) to the Server.
Question for the 1: What technology is preferable to send the messages from Server to Client ?
I think there are not ServerEvents for Dart.
GRPC maybe it would be a good choice, but there is no support yet in Azure AppServices.
I can see the Redis Server Events, but I assume they are appropriate for communication between services, not client side.
Client connection should be always on, to get new events.
Question for the 2: I assume the better way for the Client to send commands (not often), is the API Calls to Server. Or to use other technology like the GRPC ?
Since Server Sent Events (SSE) is thankfully a web standard , there are multiple Dart libraries that do support this form of communication. So while the ServiceStack Dart library doesn’t currently have SSE support, it as a technology choice seems like a decent choice when combined with the requirements you’ve outlined.
As a proof of concept, I created a small Flutter Dart using the sse_client Dart package. This is running on Android but I can see there are several that support Dart web. I had to downgrade the version of the sse_client due to a dependency conflict currently with the current version of the servicestack client library as well FYI.
I just initialized the client in a State class (which may not be right but worked for illustration purposes) and the bulk of it looked something like this.
This is obviously not ideal way of doing things since the servicestack Dart library doesn’t yet have a specific SSE client like Java or C#, I imagine this is something we would consider adding as more users request this feature.
Flutter is creating a great developer workflow for cross platform clients, and is something we likely will invest efforts in going forward.
Hi @mythz .
gRPC it is a good choice. and I had seen before the “Server Events using a gRPC Stream API:”
The only problem is that Azure AppService does not support gRPC, as far as I know.
But maybe, alternatively. we could start with Azure classic Cloud Service in small VMs and wait, wait, wait MS.
Messages being pushed are controlled by the ServiceStack server, so it should be up to how you setup SSE on the server. See Sending Server Events.
@mythz also rightfully pointed out to me that there will likely be a lack of hearbeat calls in a 3rd party library, so disconnection/reconnection might not be handled, making the gRPC approach (if you can get around the Azure AppSevices limitation) more robust approach at the moment to get you up and running.