sdk api for MessageBundle with variants

[jldec]

Context

The current MessageQueryApi operates on Message objects.

export type MessageQueryApi = {
    create: (args: { data: Message }) => boolean
    get: ((args: { where: { id: Message["id"] } }) => Readonly<Message>) & {
        subscribe: (
            args: { where: { id: Message["id"] } },
            callback: (message: Message) => void
        ) => void
    }
    // use getByDefaultAlias() to resolve a message from its alias, not subscribable
    getByDefaultAlias: ((alias: Message["alias"]["default"]) => Readonly<Message>) & {
        subscribe: (alias: Message["alias"]["default"], callback: (message: Message) => void) => void
    }
    includedMessageIds: Subscribable<Message["id"][]>
    /*
     * getAll is deprecated do not use it
     */
    getAll: Subscribable<Readonly<Message[]>>
    update: (args: { where: { id: Message["id"] }; data: Partial<Message> }) => boolean
    upsert: (args: { where: { id: Message["id"] }; data: Message }) => void
    delete: (args: { where: { id: Message["id"] } }) => boolean
}

☝️ is exposed as project.query.messages in the InlangProject api

export type InlangProject = {
//  ....
    query: {
        messages: MessageQueryApi
        messageLintReports: MessageLintReportsQueryApi
    }
}

Proposal

From MESDK-77

after introducing UUIDs for variants / we will have to expose a project.query.variant.* next to project.query.messageBundle.* and project.query.message.*.

The comment above suggests a new MessageBundleQueryApi for apps to operate directly on the MessageBundle structure.

@samuel.stroschein @martin.lysk1
Given our experience with MessageQueryApi, do you think this proposal the right approach to use at this time?

[jldec]

Related serializability comment from @jan.johannes

https://linear.app/opral/issue/INBOX-16/would-a-multi-threadedworker-state-management-solution-enable-multiple#comment-bc61c942

[samuelstroschein]

Yes, we will need a new query api. Given that every API is changing, I propose to

1. introduce project.query2.* APIs for the feature flag
2. keeping project.query.* for backwards compatibility during the feature flag
3. Remove project.query.* and rename query2 to query when persistency etc is nearing GA and release the sdk under a new major version

project.query2.messageBundle.*
project.query2.message.*
project.query2.variant.*
project.query2.pattern.*
project.query2.lintReports.*

Notes:

• the wording "apps operating on message bundle" confused me for a sec. apps will use apis for all primitives i.e. (MessageBundle, Message, Variant)
• instead of rolling our own query engine, we could (should?) take a look at solutions like https://rxdb.info/.
  • we can write our own persistency
  • runtime query optimization and execution would be handled for us (indexes, relational schema, etc)
  • BUT dependency and opens questions about exposing reactivity etc

[jldec]

👍

I like the query2.* idea for the feature flagged api