pglite
pglite copied to clipboard
electric-sql
React native support
I'm very interested in this and can help if I can. I have no idea what is required and I don't know much about WASM but I am willing to dig in.
https://github.com/cawfree/react-native-webassembly
looks like react native can support web assembly
Hey,
We're looking into that (https://github.com/cawfree/react-native-webassembly) route to RN support, but it's going to require quite a bit of work as it wouldn't be compatible with the current build.
We are exploring two opens:
- WASM with something like above or another third party runtime integration.
- Having a native build of PGlite that can link to the native app and be wrapped with the TypeScript api.
Both of these will be dependent on the "libpglite" we are currently working on.
We hope to have a better idea soon, but rest assured, React native support is at the top of our to-do list.
Seems like option 2 would make sense. Can we help with this? I don't see any obvious branches here.
The way to do it would be option 2, using turbo native modules and cross platform turbo native modules. It may be as simple as plugging PGliteInterface into react native's codegen and adding boilerplate to call the native pglite functions from the generated interface.
Seems like option 2 would make sense. Can we help with this? I don't see any obvious branches here.
@chris-garrett most likely we will be using WASI build of current code with experimental changes to wasi-sdk 23 to be tested with option 1, after success then we will just retarget assembly to C89 to make native builds for 2).
so far only blocker is wasm extensions loading which is not obvious on wasm3 ( or any wasi runtime so far)
@samwillis is this the best place to track support for Expo and React Native? I assume it is.
Any progress on getting pglite running on react-native? A status update would be appreciated or some pointers to areas where help is needed.
Hey @evelant
We're making good progress, RN support depends on our "libpglite" project. This is going well, we have a good understanding of what's needs and have some early prototyping that showing that it's feasible.
we have two priorities right now: pg_dump (prerequisite to any PG version bump) and RN support.
There's a chain of things to do to get there, but we have a firm plan: libpglite -> retarget to native C -> Kotlin and Swift wrappers -> React native.
Hey @evelant
We're making good progress, RN support depends on our "libpglite" project. This is going well, we have a good understanding of what's needs and have some early prototyping that showing that it's feasible.
we have two priorities right now: pg_dump (prerequisite to any PG version bump) and RN support.
There's a chain of things to do to get there, but we have a firm plan: libpglite -> retarget to native C -> Kotlin and Swift wrappers -> React native.
Did you consider using Nitro ? https://github.com/mrousavy/nitro
I wish I could help push this forward but unfortunately I have little experience with C/C++ and time is too tight for me to spend time learning it at the moment ☹️ . I love what electric is building and am very excited to try it out and contribute in the future. IMO it's definitely the right direction to finally have a robust offline capable sync for apps!
I assume this would also help with Flutter and other native platform support too right, if the pure C code can be interacted with via FFI? Would a WASM build also be feasible or just focusing on the pure C build for now?
This will be an awesome addition and I am much more inclined to buy in to the ecosystem if it lands some time. Props for pglite btw. Incredible!!!
wasi build can help, you turn track it here https://github.com/electric-sql/pglite/pull/433
wasi build won't help, there's no way to run wasm on react native. Due to iOS JIT restrictions the best you could do is a wasm interpreter so performance would likely be poor.
| Due to iOS JIT restrictions
@evelant True, wasi cannot help directly on iOS .. But if you give up on most contrib extensions there are ways to have wasi code running natively on a statically linked iOS app.
But since it is a tech i previously only used on android games, i whould just need to have a react iOS skeleton project that would call pglite typescript functions "as if they were native in C" ( ie stubs for me to replace)
https://nitro.margelo.com/docs/nitro-modules might help. Looks like a faster, easier to maintain, and overall better solution for including cross platform cpp in react native projects compared to expo modules or turbomodules. Just write a TS interface definition and nitrogen will give you kotlin/swift/cpp stubs to work against to call any native side stuff synchronously even allowing calling back into js.
Looking at how pglite builds unfortuantely I'm not sure there's much I can do to help -- the build process appears quite complex and I have little experience with make/cmake and bash scripts. Since it's all C however theoretically as far as I know there shouldn't be anything in the way of defining a nitro module interface and directly calling the C functions as needed. I just lack the expertise using C build tools to try it myself.
As @samwillis said earlier, we have a pretty good idea on how to achieve this - and more! We just need some more time to implement it.
As @samwillis said earlier, we have a pretty good idea on how to achieve this - and more! We just need some more time to implement it.
Do you think would be possible with https://github.com/callstackincubator/polygen from the callstack guys
Hey @octalpixel
Polygen is very cool! I've been keeping my eye on it. One of the routes we've been exploring is very similar, it's also using wasm to c. Using polygen may well work in future, but it's missing some critical functionality at the moment.
Hey @octalpixel
Polygen is very cool! I've been keeping my eye on it. One of the routes we've been exploring is very similar, it's also using wasm to c. Using polygen may well work in future, but it's missing some critical functionality at the moment.
Super! Looking forward to it!
Any update on the progress here or somewhere to track progress more granularly?
