Roadmap for persisting sdk v2 MessageBundles

[jldec]

MESDK-109

Capturing here for wider readability.

This tasklist describes the steps toward full persistence and apis for v2 MessgaeBundles. This is part of an ongoing effort to streamline the sdk architecture as described in https://github.com/opral/inlang-message-sdk/issues/15.

• [X] 1. load/store JSON v2 MessageBundles under experimental persistence feature flag PR 2801
• [X] 2. New CRUD api for MessageBundles. This api will be async and non-reactive.
• [ ] 3. Project-level subscribe api which does not depend on solidjs. PR 2913
• [ ] 4. createMessageBundle, createMessage, createVariant helpers with auto-generated unique id's
• [ ] 5. UI framework adapter(s) built on top of the async crud + subscribe api
• [ ] 6. Maybe shim the existing MessageQueryApi exposing partial v2 MessageBundles to existing inlang apps for backward compatiblity.

[samuelstroschein]

Regarding the framework adapter:

Exposing RxJS Observables has high interop. The only "adapter" (just a binding function) that UI frameworks would need is to .subscribe.

In Solid land this is as simple as:

function Component(){
  const message = from(project.query.message.subscribe("blabla"))
  return <>{message()}</>
}

https://docs.solidjs.com/reference/reactive-utilities/from

In React land

function Component(){
  const message = useObservable(project.query.message.subscribe("blabla"))
  return <>{message}</>
}

https://github.com/crimx/observable-hooks

Hence, I think going with RxJS for internal reactivity and exposing observables via .subscribe is our easiest path to put the reactivity discussions behind us. cc @martin.lysk1

[martin-lysk]

Agree - any thoughts on this one from you @jan.johannes

[jldec]

Thanks for the feedback 🙏
Here's a quick TL;DR of how I'm thinking about the api layers for now.
Internal means below the === line.

UI code
- - - - - - - - - - - - - - - - - -
UI framework adapter
- - - - - - - - - - - - - - - - - -
generic reactive api: RxJS ?
===================================
js subscribe (e.g. to CRUD events)
- - - - - - - - - - - - - - - - - -
messages CRUD api (not reactive)
- - - - - - - - - - - - - - - - - -
store api (DB/files)

To be extra clear @martin.lysk1, I don't think we want reactivity in the bottom layers, even knowing that we want observable database queries in the future.

At the time when we have lix apis for change-tracking on a DB, we can look at DBs with watchable queries, but I did not interpret @samuel.stroschein's suggestion for RxJS to mean that we should implement this in our v2 store using RxJS internally.

The v2 store is a very bare-bones database designed to live in text files versioned by git while we continue working on lix.

[samuelstroschein]

What is the generic reactive api? JS subscribe can be applied to any api no?

for example:
project.settings.subscribe()

i would prob also change the api to project.{api}.get|set|subscribe:

project.settings.get()
project.settings.set()
project.settings.subscribe()

• future proofs API by avoiding breaking changes https://github.com/opral/monorepo/issues/1680
• exposing subscriptions for all props become possible if apps need it. else they just use get()
• no special framework adapter needed that wraps the entire api. only a utility function that maps .subscribe() to a frameowkrs reactive system is all thats needed

but I did not interpret @samuel.stroschein's suggestion for RxJS to mean that we should implement this in our v2 store using RxJS internally.

Yep. Doesn't have to use rxjs internally BUT Ui state always needs to be correct. wiring everything manyally will be hard ( i assume). you can try a non rxjs implementation. if bugs pop up, we will know why

[jldec]

change the api to project.{api}.get|set|subscribe

• Nice suggestion @samuelstroschein, I feel we're finally starting to get closer to a cleaner v2 sdk api design.
• I also liked the why discussion in the issue #1680
• Do you have a sense of where query() might fit in this model?
• I do wonder how we might incorporate @felixhaeberle 's request for projectList.subscribe in MESDK-36

---

What is the generic reactive api? JS subscribe can be applied to any api no?

This was just my interpretation of the app-facing RxJS api suggestion you made earlier. I agree that we should start with a basic subscribe first.

[samuelstroschein]

change the api to project.{api}.get|set|subscribe

Do you have a sense of where query() might fit in this model?

No. Except that we can prob drop the .query.* namespace.

project.messages.get()
project.messages.update()
project.messages.*
project.messages.subscribe()
project.lintReports.update()
project.lintReports.subscribe()

I do wonder how we might incorporate @felixhaeberle 's request for projectList.subscribe in MESDK-36

Yep. probably with the same pattern. Although, we break tree-shaking here.

listProjects.get()
listProjects.subscribe()

[felixhaeberle]

Yep. probably with the same pattern.

Agree 👍