PowerSync generally assumes that you have some kind of “backend application” as part of your overall application architecture - whether it’s Supabase, Node.js, Rails, Laravel, Django, ASP.NET, some kind of serverless cloud functions (e.g. Azure Functions, AWS Lambda, Google Cloud Functions, Cloudflare Workers, etc.), or anything else.
When you integrate PowerSync into your app project, PowerSync relies on that “backend application” for a few purposes:
uploadData()
function that you defined in the Client-Side Setup part of the implementation. That uploadData()
function should call your backend application API to apply the writes to your backend database. The reason why we designed PowerSync this way is to give you full control over things like data validation and authorization of writes, while PowerSync itself requires minimal permissions.An overview of how PowerSync interacts with your backend application.
The next section, Writing Client Changes, provides guidance on how can handle write operations in your backend application.
General authentication for your app users is outside the scope of PowerSync. A service such as Auth0 or Clerk may be used, or any other authentication system.
PowerSync assumes that you have some kind of authentication system already in place that allows you to communicate securely between your client-side app and backend application.
The fetchCredentials()
function that you defined in the Client-Side Setup can therefore call your backend application API to generate a JWT which can be used by PowerSync Client SDK to authenticate with the PowerSync Service.
See Authentication Setup for details.
See our Example Projects page for examples of custom backend implementations (e.g. Django, Node.js, Rails, etc.)
For Postgres developers, using Supabase is an easy alternative to a custom backend. Several of our demo apps demonstrate how to use Supabase as the Postgres backend.