Quick summary: We’re adding optional turnkey backend functionality for PowerSync that handles writing to the backend database (with initial support for MongoDB) and generating JWTs. This makes PowerSync easier to implement for developers who prefer not having to maintain their own backend code and infrastructure.
Background: Bring-Your-Own-Backend Architecture
When we launched PowerSync as a standalone product in 2023, one of our key architectural decisions was to allow developers to use their own backend to persist writes to their source database (e.g. Postgres or MongoDB). Based on years of experience working with enterprises on sync use cases, we knew that many developers would want to apply their own custom business logic, data validations and authorization rules to these write operations.
Accordingly, we designed PowerSync to handle the read and write paths of syncing differently:
- Read path: Sync data directly from the source backend database (using change data capture to detect changes) via the PowerSync Service to a client-side SQLite database.
- Write path: The client-side application can perform writes directly on the local SQLite database. The writes are also automatically placed into an upload queue by the PowerSync client SDK. The SDK then uses a developer-defined %%uploadData()%% function to manage the uploading of those writes to the backend. In the %%uploadData()%% function, the developer calls their backend API.
In this way, the developer gets the benefits of a sync engine in that it simplifies state transfer between backend and frontend (for example: real-time streaming updates; no need to worry about network errors or retry logic), while not sacrificing control over writes, or even needing to give write permissions to the sync engine.
The developer’s backend also plays a role in authentication: it is used to generate JWTs for PowerSync.
Conflict Resolution & Consistency
In this paradigm, conflict resolution is relatively straightforward with PowerSync as long as developers are comfortable with “bringing their own backend”. Because of the server-authoritative nature of PowerSync, whatever is written to the backend database will automatically be reflected on all clients (without overwriting local changes that have not yet been uploaded). The simplest backend implementation is to apply writes as they are received, which typically means “last update wins; deletes always win” conflict resolution behavior. The developer can implement more sophisticated conflict resolution logic in their backend API if needed.
Consistency is also automatically provided by PowerSync. The developer ensures that the backend database is in a consistent state, and PowerSync reflects that state to clients: it syncs operations to clients until it reaches a consistent state (called a checkpoint) and then atomically updates the client-side SQLite database with that state.
Need for Turnkey Backend Functionality
In contrast to PowerSync, MongoDB’s Atlas Device Sync (deprecated in September 2024) provided turnkey writes/uploads to the backend database. As a result, we have seen that many developers who are migrating to PowerSync from Atlas Device Sync are expecting equivalent functionality in PowerSync.
While the original PowerSync architecture optimizes for customizability, this kind of “baked-in” backend functionality of Atlas Device Sync optimizes for convenience and low maintenance overhead instead: you don’t have to write any backend code or deal with having to host a separate backend yourself.
We therefore decided to move quickly to enhance PowerSync with more turnkey backend options for developers. Today we are announcing our first solution, as well as our roadmap for future improvements.
Phase 1: Serverless Cloud Functions for Turnkey Backend Functionality
PowerSync was spun off from JourneyApps Platform, a full-stack app platform that our company originally created. One of the components of JourneyApps Platform is CloudCode, a serverless cloud functions engine based on Node.js and AWS Lambda.
It is now possible to use JourneyApps Platform CloudCode for turnkey backend functionality for PowerSync when used with a MongoDB backend source database. We have added a template to CloudCode that developers can quickly spin up that provides the needed backend functionality “out of the box”, including endpoints for generating JWTs and uploading writes.
Developers have the ability to customize the template, or they can use it as-is. CloudCode is provided as a fully-managed service running on the same cloud infrastructure as the rest of PowerSync Cloud. PowerSync and JourneyApps Platform exist as sibling products that share the same login system, so you don’t need to create a separate account to use CloudCode.
We have added documentation with more step-by-step instructions on how to use this template in CloudCode. At this time you will also need a short “white-glove” onboarding session with our team — please get in touch. Lastly, before going into production with this solution, you will also need to set up authentication on the HTTP endpoints exposed by the CloudCode tasks — we can also assist with this.
Turnkey Conflict Resolution
Using the MongoDB backend template in CloudCode gives developers turnkey conflict resolution behavior that is roughly equivalent to what’s provided by MongoDB Atlas Device Sync: deletes always win, last update wins, and primary keys designate object identity.
Phase 2: Serverless Cloud Functions Fully Integrated Into PowerSync
The next step on our roadmap is to fully integrate CloudCode into the PowerSync Dashboard, eliminating the need to use the separate sibling product (JourneyApps Platform). We expect to release this in the first half of 2025.
Phase 3: First-Class Backend Package/Service in PowerSync
Lastly, an even more turnkey option is on our roadmap for later in 2025: A first-class package that can run alongside the PowerSync Service that provides backend functionality. We may also provide this as a managed service as part of PowerSync Cloud.
Making PowerSync Easier to Use
By making these turnkey options available, our aim is to give developers the best of both worlds: “bring your own backend”, or a hassle-free managed option if that is preferable. Both give you deep customizability: If you use CloudCode, you can still customize the template to fit your exact needs.
We’d love to hear your thoughts. If you have any feedback or questions, please get in touch!
PS: Migration Path for Atlas Data API and Custom HTTPS Endpoints
As you can see, our CloudCode functionality can also serve as a replacement for MongoDB’s deprecated Atlas Data API and Atlas Custom HTTPS Endpoints. If you use these deprecated features, are interested in migrating from them to CloudCode, and would like some assistance, please get in touch.
