apple / swift-openapi-generator

Generate Swift client and server code from an OpenAPI document.
https://swiftpackageindex.com/apple/swift-openapi-generator/documentation
Apache License 2.0
1.23k stars 89 forks source link

Realtime chat client #507

Closed miguel-arrf closed 4 months ago

miguel-arrf commented 4 months ago

Question

Hi!

I'm developing a toy project for a real-time chat system.

I'm wondering if, now that we have Streams, if this is the way to go for what I want or, if for some reason, something like gRPC, plain SSE or WSS would be better.

Essentially I want to have a long-lived connection while my app is open so that I can receive any necessary update (like new messages).

Looking into this (very clear) example: https://github.com/apple/swift-openapi-generator/blob/main/Examples/event-streams-client-example/Sources/EventStreamsClient/EventStreamsClient.swift, I wonder how will it handle (for instance) if the client disconnects. Where and how should I handle a retry-connection logic.

Do you feel like Swift OpenAPI is a good-to-go approach for something like this?

Thank you! :)

czechboy0 commented 4 months ago

Hi @miguel-arrf,

any sort of live pub/sub system should be a good match for any of the three streaming formats we added built-in support for recently: JSON Lines, JSON Sequence, or Server-sent Events. Unless you need something more advanced, I think starting with JSON Lines is a good idea, as it's the simplest one.

Note that what's provided is just a way to produce/parse a stream of events, but as you point out, any logic to manage the connection and resumes, for example for a client that needs to handle such a stream in a HTTP response, would need to be written by you, wrapping the low-level generated calls to the server.

The idea would be, each event has a unique ID, you keep track of the latest ID you saw, and if the response stream gets interrupted, make the HTTP request again, sending the latest ID to the server, allowing the server to only replay what you missed since that ID.

So to answer your question: yes, the provided tools can be used as the low-level building blocks, but the stateful connection management needs to be built on top of it, as the details can differ between applications.

miguel-arrf commented 4 months ago

Hi @czechboy0!

Thank you so much for your detailed answer 🚀 😊 ! Just one more question:

if the response stream gets interrupted

How do I know if the stream got interrupted?

(I haven't yet run the example code as I'm still understanding my options. Maybe if I have had run it I would already have the answer for this 😓 )

czechboy0 commented 4 months ago

Great question, it's not immediately obvious.

For example, if you make a request to GET /stream and get back 200 OK immediately, with a content type application/jsonl, you'd get the HTTPBody type, which represents the response body stream.

As shown in the examples, you'd then turn it into a stream of parsed, deserialized events, so the full thing looks like this:

let response = try await client.getGreetingsStream(
    query: .init(name: "Example", count: 3),
    headers: .init(accept: [.init(contentType: .application_jsonl)])
)
let greetingStream = try response.ok.body.application_jsonl.asDecodedJSONLines(
    of: Components.Schemas.Greeting.self
)
for try await greeting in greetingStream { 
    print("Got greeting: \(greeting.message)") 
}

Now, if the connection gets interrupted, the for loop at the end is what I'd expect to throw an error. But the details depend on the ClientTransport implementation you're using.

But if you wrap the for loop in a do/catch block, that at least signals to you when you need to re-establish the connection.

miguel-arrf commented 4 months ago

Awesome, thank you so much for all the help!!