Advice for Flutter - Dart - Server communication architecture

1

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)

  1. 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 ?
thanks

2

Hi @StefanT,

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.

  String chatResponse;
  SseClient channel;

  @protected
  @mustCallSuper
  void initState() {
    super.initState();
    channel = SseClient.connect(Uri.https("chat.netcore.io", "/event-stream", {"channels":"home"}));
    channel.stream.listen((event) {
      this.setState(() {
        chatResponse = event;
      });
    });
  }

1857×1068

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.

1 Like
3

@layoric thanks a lot for your effort. We will try it and give a feedback here next week, I hope.
In our case, each client will get messages only for him, it will have his channel I suppose.

"I had to downgrade the version of the sse_client " Do you remember the version?

4

I’d recommend using the Dart generic smart Service Clients which offer a better development UX then code generated proxies like a gRPC client could.

For real-time notifications you could also consume Server Events using a gRPC Stream API:
https://docs.servicestack.net/grpc-dart#dart-server-events-grpc-server-stream-example

1 Like
5

Hi @mythz :slightly_smiling_face:.
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.

6

pubspec.yaml

  sse_client: ^0.0.3

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.

1 Like
7

I’ll check all of them @layoric
First priority the gRPC approach . I can say to management to use a small 2 cores VM in classic cloud service, even temporarily. Cloud Service has gRPC support, I think

1 Like