Is the intent to publish bevy-realtime as a separate crate?

[richchurcher]

This is probably my lack of familiarity with Rust crates talking, but... should it be possible to work with bevy-realtime from bevy-supabase? Near as I can tell, this kind of thing is impossible due to the lack of exported types:

use bevy::prelude::*;
use bevy_http_client::HttpClientPlugin;
use bevy_supabase::prelude::*;

#[allow(dead_code)]
#[derive(Clone, Event, Debug)]
pub struct ChatMessageEvent {
    payload: PostgresChangesPayload,
}

impl PostgresPayloadEvent for ChatMessageEvent {
    fn new(payload: PostgresChangesPayload) -> Self {
        Self { payload }
    }
}

fn main() {
    let Ok(apikey) = std::env::var("SUPABASE_LOCAL_ANON_KEY") else {
        panic!("SUPABASE_LOCAL_ANON_KEY must be set.");
    };

    let mut app = App::new();

    app.add_plugins((
        DefaultPlugins,
        HttpClientPlugin,
        SupabasePlugin {
            apikey,
            endpoint: "http://127.0.0.1:54321".into(),
            ..default()
        },
    ))
    .add_systems(Startup, init)
    .add_systems(Update, read_chat_messages)
    .add_postgres_event::<ChatMessageEvent, BevyChannelBuilder>();

    app.run()
}

pub fn init(client: ResMut<Client>, mut commands: Commands) {
    let channel = client.channel("table_changes".into());

    let mut c = commands.spawn(BevyChannelBuilder(channel));

    c.insert(PostgresForwarder::<ChatMessageEvent>::new(
        PostgresChangesEvent::Insert,
        PostgresChangeFilter {
            schema: "public".into(),
            table: Some("messages".into()),
            filter: None,
        },
    ));
    c.insert(BuildChannel);
}

fn read_chat_messages(mut evr: EventReader<ChatMessageEvent>) {
    for _ev in evr.read() {
        println!("::: chat message received :::");
    }
}

However, if bevy-realtime were available separately, this isn't really an issue anymore! I'm not sure if there's some magic I'm supposed to be able to perform with the crates/ directory to get this to work :sweat_smile:

The Cargo.tomls in crates/ look as if they might end up being published separately, so I'm not sure if the intent is for them to be exposed as types in the base crate.

[richchurcher]

I cannot replicate the channel disconnect issue using the above sample, which is good news! I'll PR the prelude I'm using to your nokio branch and you can use/discard as you see fit, depending on plans for publishing the crate.

[bytemunch]

I was unsure about how I'd publish when designing the overall architecture so put the separate functionalities in different crates for future flexibility. If you think there's utility in having them published separately then I think that's a good direction to go in :)

[richchurcher]

I think so? I don't know if it makes the maintenance more annoying though :confused:

[bytemunch]

Ah it's 4 crates, not too much extra admin. Do you think they should be in their own repos too? I guess the issues would be in integration, but that'll not be an issue if each of the crates depends on an API compatible target version of another.

[richchurcher]

I think the rule would be, if you can conceivably see someone needing to use one without all the others, then separate repo? The whole sub-crate approach is, I suspect, going to lead to a large prelude or figuring out which types to expose etc... so hardly an expert, but I'd opt for small crates that can be composed as required.

[bytemunch]

Realtime repo created :) https://github.com/bytemunch/bevy-realtime