> Firebase Data Connect provides you with a local emulator for end-to-end prototyping as well as continuous integration and continuous deployment (CI/CD) flows
Developers at Google have chosen PGLite for those qualities so that users of Firebase Data Connect had better CI/CD workflows. It wouldn't be fair to say this is an insignificant use case.
PGlite is coming — we have a new WASI build that is the basis for native mobile support. (It’s working in dev, but still needs some more polishing and bindings).
- the WASI build is targeting WASI snapshot preview 1, and so should work in any compatible runtime.
- for the web, currently we use Emscripten, but we are considering moving to a single WASI build there as well. We'll be writing our own JS WASI shim if we do. Having full control of the JS code will help to solve some of the problems we've faced with Emscripten.
- we are also exploring a route to native where we take the WASI build and decompile it back to C. This seems a little mad, but it makes it possible to compile (with any tool chain) a native binary with a very minimal WASI-like api that can be linked to from any app. It essentially end up a little like the SQLite amalgamated header file as a build route. It's very experimental, and we haven't committed to it yet, but it looks like it may work.
Dynamic linking on iOS is complex, and Android also brings some toolchain complexities. It would be possible to do a native build and link it, and that is a route we are also exploring, but a single C file that can be linked with any existing toolchain would simplify things for users.
It also allows us to implement a VFS layer underneath PGlite in a native mode. So things like the in-memory VFS, or a custom VFS, would be possible.
We have not committed to one route or the other yet.
Hey, one of the things here is to define shapes that are shared. If you imagine syncing a shape that is that user’s data then it may be unique. But if you sync, say, one shape per project that that user has access to and a small shape of unique user data then you get shared cache between users who have access to each project.
It’s worth noting that Electric is still efficient on read even if you miss the CDN cache. The shape log is a sequential read off disk.
I'm curious on how you'd configure this. Is it common (and safe) to let a cdn cache private data for authenticated users?
Say Jira used electric, would you be able to put all tickets for a project behind a cdn cache key? You'd need a cdn that is able to run auth logic such as verifying a jwt to ensure you don't leak data to unauthorized users, right?
So you can have local-first sync in a Phoenix app using Electric. And you can use Electric to sync data into a LiveView using Phoenix.Streams, which is a very natural fit.
We have a couple of example apps showing things in action:
Great stuff. Voice AI is great to run locally not just for privacy / access to personal data but also because of the low latency requirement. If there's a delay in conversation caused by a network call, it just feels weird, like an old satellite phone call.
ElectricSQL | https://electric-sql.com | PGlite Engineer | Remote in Europe or eastern US | €80-100k + Equity
We're looking for a generalist web and systems engineer to join the core PGlite team, working mainly in Typescript, Rust and C++.
PGlite (https://pglite.dev) is a lightweight, embeddable WASM Postgres. It's a fast growing open source project, with 8k GitHub stars and 100k+ weekly downloads. It opens up new possibilities for local-first apps and systems built on an embedded, real-time, reactive Postgres, such as https://postgres.new
Technically, you need strong Typescript and systems programming experience, ideally in C++ and Rust. It would be great if (but is not essential that) you're familiar with some aspects of database internals, filesystems and WASM.
If you’re doing data analytics in Python it’s well worth a look.
reply