search

bytemunch / bevy-supabase

Supabase + Bevy
Apache License 2.0
5 stars 1 forks source link

Should not depend on unstable upstream realtime crate #3

Closed bytemunch closed 5 months ago

bytemunch commented 6 months ago

realtime-rs should be stabilised and bevy-realtime should depend on a specific version, in order to prevent future dependency and API mismatch problems like #1

bytemunch commented 6 months ago

Another solution could be to do the same as I did for auth and postgrest, just write (yoink and change a bit) it bespoke for bevy. This could remove tokio from the pipeline entirely, allowing the crate to leverage bevy's async runtime instead

richchurcher commented 6 months ago

I actually had the same thought... like, how do other networking plugins for Bevy navigate this using Bevy's async runtime? I'd be curious to dive into this more.

bytemunch commented 6 months ago

I've started a bit of work on the nokio branch, using bevy's AsyncComputeTaskPool to run the websocket client without blocking rendering. Bit of restructuring and refactoring to go but I think this is the best approach :)

richchurcher commented 6 months ago

Nice! Will help if I can in any way. nokio indeed :laughing:

richchurcher commented 6 months ago

Can confirm after some struggles, it works! It does block rendering (black screen) if you get the details wrong. Ahem. So I suppose some means of failing out more gracefully might be in order, but we can work on that. Fascinating this new (to me) realm of juggling rendering and networking! I guess this is the bed I've made for myself. Is there a concrete way I could help out? Feel free to farm out an issue potentially suitable for a clod such as me.

bytemunch commented 6 months ago

@richchurcher

Aha don't be so down on yourself, you're skilled enough to get this crate working with near zero documentation, not to be sniffed at lol.

It still blocks rendering cos I've got the call to connect still on the main thread, and currently that call hangs if it fails instead of noticing and dying. Moving the call to the thread solves the render blocking problem, but I think would introduce a new problem with bevy systems trying to access client systems before the client is ready.

It blocks because the setup in lib.rs is trying to make a ClientManager on a disconnected client, which hangs.

I still don't know why a bad URL causes a hang ;_;

Best place to start if you think you're a beginner is writing docs as and when you use and understand a system, or rewriting function return values to handle and pass errors to the call site if you've got a good handle on the Result type.

I'm not worrying about testable code examples in docs yet as the API is so fluid, but descriptions of functions could be made clearer.

As I say this is all very undercooked and uses the ever popular 0ver so don't worry about changing the API if it makes life easier! :P

richchurcher commented 6 months ago

I think the one piece of the puzzle I'm still slightly missing is how to make use of bevy-realtime from bevy-supabase... does it need some of its API exposed, or am I just missing something super-obvious? At the moment I'm just yoinking it out of src/crates and including it locally from cargo 😆

richchurcher commented 6 months ago

Maybe I'll see if I can figure that bit out first and write a rough guide.