https://kotlinlang.org logo
Join Slack
Powered by
I've been trying to consume a subscription in Kotl...
# apollo-kotlin
n
I've been trying to consume a subscription in Kotlin Multiplatform and finding that I often have many missing elements in my flow. The code I'm using is in the thread.
Graph is just a poor-man's dependency graph, where we set up the GraphQL subscription client.
Untitled
I've set up code like this for the creation of the ApolloClient for the subscription handling. This connects, and does get one or two elements... But if the elements come in too fast, it seems I don't get them all. When the server delays sending, all of the elements do come in.
Untitled
What am I missing? Am I doing it wrong?
m
That's interesting. Sounds like a 
CONFLATED
channel somewhere... Do you have a rough idea of the delay that makes everything work again? Are we talking milliseconds or seconds?
n
More than 100ms and works pretty reliably around 1s. I have a little time to play with this today, but then I have to move on.
m
Do you mind opening an issue with your code in the repo (pseudo code work too)? Make sure we can track this?
n
I don't mind at all. Since the GraphQL playground seems to be able to get all of the data, I am going to focus on the KMP side and see where I've gone wrong. The server side is using graphql-kotlin, and the code I used for that is really small.
🙏 1
❤️ 1
m
Also quick question, is this JVM, native or both?
n
The app will be iOS and Android, so both.
I have only tested on Android so far.
👍 1
Okay, wrote: https://github.com/apollographql/apollo-android/issues/3095 Let me know if you want more information inside that report, @mbonnin
m
Thanks, will look into it! 
graphql-ws
is getting some attention lately, I know @Doug Chappelle has been looking into it too a couple of threads just above this one so looks like there might be something to do there
👍 1
n
Funny I was just looking at exactly that line.
m
🙂
Not sure there is a reason for this, I guess we should make it configurable somehow, with the defaultcertainly to not drop items
n
I'll see if I can get set up to experiment with the different options on that webSocketConnection.broadcast() function...
m
These days, 
SharedFlow
might be an option too, I think it didn't exist at the time
n
That's true.
m
Buffering will work to a certain extent but proper backpressure handling will require more work
n
I've cloned the repo, but not sure the easiest way to make small code changes, publish to my local maven repo and try it in my code?
m
Yep, publishToMavenLocal works well
You can also include the build but tbh that might take longer in gradle sync compared to maven local
n
Okay, 
publishToMavenLocal
works. Just doing that and testing a few things out here.
So, making ApolloWebSocketNetworkTransport.kt:180 read:
Copy code
private val messageChannel: BroadcastChannel<ByteString> = webSocketConnection.broadcast(Channel.BUFFERED)
works the way I'd expect it to. I get all of the data items delivered.
👍 1
m
Nice! Want to submit a PR to make this a parameter of 
ApolloWebSocketNetworkTransport
? We can figure out the backpressure stuff later
n
Sure, will give that a shot.
Okay, I've made a PR: https://github.com/apollographql/apollo-android/pull/3096 and do let me know in the PR if you'd prefer a different implementation. I simply went for minimal changes, and defaults to the current value.
👍 1
m
Looks good to me, thank you so much for the contribution 😊 !
n
You're welcome. Looking forward to using it to finish this feature I'm working on. I'll keep my eye out for when it gets into the repo. Thanks for your help with it!
👍 1
34 Views
Open in Slack
PreviousNext
Powered by