Open BoD opened 3 years ago
+1 over here.
It looks like most of the Kotlin/Native world is forced to use Ktor for client HTTP. On Linux, Ktor currently only supports cURL for networking, with CIO maybe to come later. So, with that in mind, I have 2 questions 😬
Can Apollo runtime work on top of Ktor + cURL, which would then support all Kotlin/Native targets out of the box?
What's the main blocker for runtime support on Linux, given that Mac is already supported?
Thanks! <3
Hi @milosmns 🐧 👋
Nope, apollo-runtime
isn't compiled for linux at the moment so you can't make it work with cURL. You can though use apollo-api
directly without apollo-runtime
(documentation). It contains the parsers and everything you need to compose a query but not the actual HTTP client.
I don't think there's a hard blocker, it's mostly a matter of prioritization and linux support hasn't been a focus lately. The main problem I can envision is that apollo-runtime
currently expects a DefaultHttpEngine and I'd prefer we don't pull ktor in the dependencies by default. But I think starting with a placeholder HttpEngine
that throws NotImplementedException
would be fine. Then we'd need a separate ktor HttpEngine
that users could register at runtime. Then we'd also need linuxArm64
maybe?
All in all, you can use linuxX64 today if you write the networking code yourself. Getting apollo-runtime
to work will require some plumbing but it's certainly doable.
Thanks for the quick response @martinbonnin!
Alright, makes sense, appreciate the update. I think that your proposal with a "not implemented" error on Linux should also work for the time being and would reduce the amount of plumbing needed for whoever wants to use this on Linux. But Linux for ARM is another beast altogether... not sure if even Ktor is supporting it, I'd need to check.
Apollo Android v3 doesn't currently target Linux.