# Architecture Overview Source: https://docs.powersync.com/architecture/architecture-overview The core components of PowerSync are the service and client SDKs

The [PowerSync Service](/architecture/powersync-service) and client SDK operate in unison to keep client-side SQLite databases in sync with a backend database. Learn about their architecture: ### Protocol Learn about the sync protocol used between PowerSync clients and a [PowerSync Service](/architecture/powersync-service): ### Self-Hosted Architecture For more details on typical architecture of a production self-hosted deployment, see here: # Client Architecture Source: https://docs.powersync.com/architecture/client-architecture ### Reading and Writing Data From the client-side perspective, there are two data flow paths: * Reading data from the server or downloading data (to the SQLite database) * Writing changes back to the server, or uploading data (from the SQLite database) #### Reading Data App clients always read data from a local SQLite database. The local database is asynchronously hydrated from the PowerSync Service. A developer configures [Sync Rules](/usage/sync-rules) for their PowerSync instance to control which data is synced to which users. The PowerSync Service connects directly to the backend database and uses a change stream to hydrate dynamic data partitions, called [sync buckets](/usage/sync-rules/organize-data-into-buckets). Sync buckets are used to partition data according to the configured Sync Rules. (In most use cases, only a subset of data is required in a client's database and not a copy of the entire backend database.)

The local SQLite database embedded in the PowerSync SDK is automatically kept in sync with the backend database, based on the [Sync Rules](/usage/sync-rules) configured by the developer:

#### Writing Data Client-side data modifications, namely updates, deletes and inserts, are persisted in the embedded SQLite database as well as stored in an upload queue. The upload queue is a blocking [FIFO](https://en.wikipedia.org/wiki/FIFO_%28computing_and_electronics%29) queue that gets processed when network connectivity is available. Each entry in the queue is processed by writing the entry to your existing backend application API, using a function [defined by you](/installation/client-side-setup/integrating-with-your-backend) (the developer). This is to ensure that existing backend business logic is honored when uploading data changes. For more information, see the section on [integrating with your backend](/installation/client-side-setup/integrating-with-your-backend).

### Schema On the client, the application [defines a schema](/installation/client-side-setup/define-your-schema) with tables, columns and indexes. These are then usable as if they were actual SQLite tables, while in reality these are created as SQLite views. The client SDK maintains the following tables: 1. `ps_data__` This contains the data for `

` , in JSON format. This table's schema does not change when columns are added, removed or changed. 2. `ps_data_local__

` Same as the above, but for local-only tables. 3. `

` (VIEW) - this is a view on the above table, with each defined column extracted from the JSON field. For example, a "description" text column would be `CAST(data ->> '$.description' as TEXT)`. 4. `ps_untyped` - Any synced table that does is not defined in the client-side schema is placed here. If the table is added to the schema at a later point, the data is then migrated to `ps_data__

`. 5. `ps_oplog` - This is data as received by the [PowerSync Service](/architecture/powersync-service), grouped per bucket. 6. `ps_crud` - The local upload queue. 7. `ps_buckets` - A small amount of metadata for each bucket. 8. `ps_migrations` - Table keeping track of SDK schema migrations. Most rows will be present in at least two tables — the `ps_data__

` table, and in `ps_oplog`. It may be present multiple times in `ps_oplog`, if it was synced via multiple buckets. The copy in `ps_oplog` may be newer than the one in `ps_data__

`. Only when a full checkpoint has been downloaded, will the data be copied over to the individual tables. If multiple rows with the same table and id has been synced, only one will be preserved (the one with the highest `op_id`). If you run into limitations with the above JSON-based SQLite view system, check out [this experimental feature](/usage/use-case-examples/raw-tables) which allows you to define and manage raw SQLite tables to work around some limitations. We are actively seeking feedback about this functionality. # Consistency Source: https://docs.powersync.com/architecture/consistency PowerSync uses the concept of "checkpoints" to ensure the data is consistent. ## PowerSync: Designed for causal+ consistency PowerSync is designed to have [Causal+ Consistency](https://jepsen.io/consistency/models/causal), while providing enough flexibility for applications to perform their own data validations and conflict handling. ## How it works: Checkpoints A checkpoint is a single point-in-time on the server (similar to an [LSN in Postgres](https://www.postgresql.org/docs/current/datatype-pg-lsn.html)) with a consistent state — only fully committed transactions are part of the state. The client only updates its local state when it has all the data matching a checkpoint, and then it updates the state to exactly match that of the checkpoint. There is no intermediate state while downloading large sets of changes such as large server-side transactions. Different tables and sync buckets are all included in the same consistent checkpoint, to ensure that the state is consistent over all data in the app. ## Local client changes Local changes are applied on top of the last checkpoint received from the server, as well as being persisted into an upload queue. While changes are present in the upload queue, the client does not advance to a new checkpoint. This means the client never has to resolve conflicts locally. Only once all the local changes have been acknowledged by the server, and the data for that new checkpoint is downloaded by the client, does the client advance to the next checkpoint. This ensures that the operations are always ordered correctly on the client. ## Types of local operations The client automatically records changes to the local database as PUT, PATCH or DELETE operations — corresponding to INSERT, UPDATE or DELETE statements. These are grouped together in a batch per local transaction. Since the developer has full control over how operations are applied, more advanced operations can be modeled on top of these three. For example an insert-only "operations" table can be added, that records additional metadata for individual operations. ## Validation and conflict handling With PowerSync offering full flexibility in how changes are applied on the server, it is also the developer's responsibility to implement this correctly to avoid consistency issues. Some scenarios to consider: While the client was offline, a record was modified locally. By the time the client is online again, that record has been deleted. Some options for handling the change: * Discard the change. * Discard the entire transaction. * Re-create the record. * Record the change elsewhere, potentially notifying the user and allowing the user to resolve the issue. Some other examples include foreign-key or not-null constraints, maximum size of numeric fields, unique constraints, and access restrictions (such as row-level security policies). With an online-only application, the user typically sees the error as soon as it occurs, and can make changes as required. In an offline-capable application, these errors may occur much later than when the change was made, so more care is required to handle these cases. Special care must be taken so that issues such as those do not block the upload queue — the queue cannot advance if the server does not acknowledge a change. There is no single correct choice on how to handle write failures such as mentioned above — the best action depends on the specific application and scenario. However, we do have some suggestions for general approaches: 1. In general, consider relaxing constraints somewhat on the server where it is not absolutely important. It may be better to accept data that is somewhat inconsistent (e.g. a client not applying all expected validations), rather than discarding the data completely. 2. If it is critical to preserve all client changes and preserve the order of changes: 1. Block the client's queue on unexpected errors (don't acknowledge the change). 2. Implement error monitoring to be notified of issues, and resolve the issues as soon as possible. 3. If it is critical to preserve all client changes, but the exact order may not be critical: 1. On a constraint error, persist the transaction in a separate server-side queue, and acknowledge the change. 2. The server-side queue can then be inspected and retried asynchronously, without blocking the client-side queue. 4. If it is acceptable to lose some changes due to constraint errors: 1. Discard the change, or the entire transaction if the changes must all be applied together. 2. Implement error notifications to detect these issues. See also: * [Handling Update Conflicts](/usage/lifecycle-maintenance/handling-update-conflicts) * [Custom Conflict Resolution](/usage/lifecycle-maintenance/handling-update-conflicts/custom-conflict-resolution) If you have any questions about consistency, please [join our Discord](https://discord.gg/powersync) to discuss. # PowerSync Protocol Source: https://docs.powersync.com/architecture/powersync-protocol This contains a broad overview of the sync protocol used between PowerSync clients and a [PowerSync Service](/architecture/powersync-service) instance. For details, see the implementation in the various client SDKs. ## Design The PowerSync protocol is designed to efficiently sync changes to clients, while maintaining [consistency](/architecture/consistency) and integrity of data. The same process is used to download the initial set of data, bulk download changes after being offline for a while, and incrementally stream changes while connected. ## Concepts ### Buckets All synced data is grouped into [buckets](/usage/sync-rules/organize-data-into-buckets). A bucket represents a collection of synced rows, synced to any number of users. [Buckets](/usage/sync-rules/organize-data-into-buckets) is a core concept that allows PowerSync to efficiently scale to thousands of concurrent users, incrementally syncing changes to hundreds of thousands of rows to each. Each bucket keeps an ordered list of changes to rows within the bucket — generally as "PUT" or "REMOVE" operations. * PUT is the equivalent of "INSERT OR REPLACE" * REMOVE is slightly different from "DELETE": a row is only deleted from the client if it has been removed from *all* buckets synced to the client. ### Checkpoints A checkpoint is a sequential id that represents a single point-in-time for consistency purposes. This is further explained in [Consistency](/architecture/consistency). ### Checksums For any checkpoint, the client and server can compute a per-bucket checksum. This is essentially the sum of checksums of individual operations within the bucket, which each individual checksum being a hash of the operation data. The checksum helps to ensure that the client has all the correct data. If the bucket data changes on the server, for example because of a manual edit to the underlying bucket storage, the checksums will stop matching, and the client will re-download the entire bucket. Note: Checksums are not a cryptographically secure method to verify data integrity. Rather, it is designed to detect simple data mismatches, whether due to bugs, manual data modification, or other corruption issues. ### Compacting To avoid indefinite growth in size of buckets, the history of a bucket can be compacted. Stale updates are replaced with marker entries, which can be merged together, while keeping the same checksums. ## Protocol A client initiates a sync session using: 1. A JWT token that typically contains the user\_id, and additional parameters (optional). 2. A list of current buckets and the latest operation id in each. The server then responds with a stream of: 1. "Checkpoint available": A new checkpoint id, with a checksum for each bucket in the checkpoint. 2. "Data": New operations for the above checkpoint for each relevant bucket, starting from the last operation id as sent by the client. 3. "Checkpoint complete": Sent once all data for the checkpoint have been sent. The server then waits until a new checkpoint is available, then repeats the above sequence. The stream can be interrupted at any time, at which point the client will initiate a new session, resuming from the last point. If a checksum validation fails on the client, the client will delete the bucket and start a new sync session. Data for individual rows are represented using JSON. The protocol itself is schemaless - the client is expected to use their own copy of the schema, and gracefully handle schema differences. #### Write Checkpoints Write checkpoints are used to ensure clients have synced their own changes back before applying downloaded data locally. Creating a write checkpoint is a separate operation, which is performed by the client after all data has been uploaded. It is important that this happens after the data has been written to the backend source database. The server then keeps track of the current CDC stream position on the database (LSN in Postgres, resume token in MongoDB, or binlog position in MySQL), and notifies the client when the data has been replicated, as part of checkpoint data in the normal data stream. # PowerSync Service Source: https://docs.powersync.com/architecture/powersync-service Each PowerSync instance runs a copy of the PowerSync Service. The primary purpose of this service is to stream changes to clients. This service has the following components: ## Replication The service continuously replicates data from the source database, then: 1. Pre-processes the data according to the [sync rules](/usage/sync-rules) (both data queries and parameter queries), splitting data into [sync buckets](/usage/sync-rules/organize-data-into-buckets) and transforming the data if required. 2. Persists each operation into the relevant sync buckets, ready to be streamed to clients. The recent history of operations to each row is stored, not only the current version. This supports the "append-only" structure of sync buckets, which allows clients to efficiently stream changes while maintaining data integrity. Sync buckets can be compacted to avoid an ever-growing history. Replication is initially performed by taking a snapshot of all tables defined in the sync rules, then data is incrementally replicated using [logical replication](https://www.postgresql.org/docs/current/logical-replication.html). When sync rules are updated, this process restarts with a new snapshot. ## Authentication The service authenticates users using [JWTs](/installation/authentication-setup), before allowing access to data. ## Streaming Sync Once a user is authenticated: 1. The service calculates a list of buckets for the user to sync using [parameter queries](/usage/sync-rules/parameter-queries). 2. The service streams any operations added to those buckets since the last time the user connected. The service then continuously monitors for buckets that are added or removed, as well as for new operations within those buckets, and streams those changes. Only the internal (replicated) storage of the PowerSync Service is used — the source database is not queried directly during streaming. ## Source Code To access the source code for the PowerSync Service, refer to the [powersync-service](https://github.com/powersync-ja/powersync-service) repo on GitHub. ## See Also * [PowerSync Overview](/intro/powersync-overview) # .NET (alpha) Source: https://docs.powersync.com/client-sdk-references/dotnet SDK reference for using PowerSync in .NET clients. This SDK is distributed via NuGet [\[External link\].](https://www.nuget.org/packages/PowerSync.Common/) Refer to the powersync-dotnet repo on GitHub. A full API Reference for this SDK is not yet available. This is planned for a future release. Gallery of .NET example projects/demo apps built with PowerSync. This SDK is currently in an [**alpha** release](/resources/feature-status). It is not suitable for production use as breaking changes may still occur. ## Supported Frameworks and Targets The PowerSync .NET SDK supports: * **.NET Versions**: 6, 8, and 9 * **.NET Framework**: Version 4.8 (requires additional configuration) * **MAUI**: Cross-platform support for Android, iOS, and Windows * **WPF**: Windows desktop applications **Current Limitations**: * Blazor (web) platforms are not yet supported. For more details, please refer to the package [README](https://github.com/powersync-ja/powersync-dotnet/tree/main?tab=readme-ov-file). ## SDK Features * Provides real-time streaming of database changes. * Offers direct access to the SQLite database, enabling the use of SQL on both client and server sides. * Enables subscription to queries for receiving live updates. * Eliminates the need for client-side database migrations as these are managed automatically. ## Quickstart For desktop/server/binary use-cases and WPF, add the [`PowerSync.Common`](https://www.nuget.org/packages/PowerSync.Common/) NuGet package to your project: ```bash dotnet add package PowerSync.Common --prerelease ``` For MAUI apps, add both [`PowerSync.Common`](https://www.nuget.org/packages/PowerSync.Common/) and [`PowerSync.Maui`](https://www.nuget.org/packages/PowerSync.Maui/) NuGet packages to your project: ```bash dotnet add package PowerSync.Common --prerelease dotnet add package PowerSync.Maui --prerelease ``` Add `--prerelease` while this package is in alpha. Next, make sure that you have: * Signed up for a PowerSync Cloud account ([here](https://accounts.journeyapps.com/portal/powersync-signup?s=docs)) or [self-host PowerSync](/self-hosting/getting-started). * [Configured your backend database](/installation/database-setup) and connected it to your PowerSync instance. ### 1. Define the schema The first step is defining the schema for the local SQLite database. This schema represents a "view" of the downloaded data. No migrations are required — the schema is applied directly when the local PowerSync database is constructed (as we'll show in the next step). You can use [this example](https://github.com/powersync-ja/powersync-dotnet/blob/main/demos/CommandLine/AppSchema.cs) as a reference when defining your schema. ### 2. Instantiate the PowerSync Database Next, you need to instantiate the PowerSync database — this is the core managed database. Its primary functions are to record all changes in the local database, whether online or offline. In addition, it automatically uploads changes to your app backend when connected. **Example**: The initialization syntax differs slightly between the Common and MAUI SDKs: ```cs using PowerSync.Common.Client; class Demo { static async Task Main() { var db = new PowerSyncDatabase(new PowerSyncDatabaseOptions { Database = new SQLOpenOptions { DbFilename = "tododemo.db" }, Schema = AppSchema.PowerSyncSchema, }); await db.Init(); } } ``` ```cs using PowerSync.Common.Client; using PowerSync.Common.MDSQLite; using PowerSync.Maui.SQLite; class Demo { static async Task Main() { // Ensures the DB file is stored in a platform appropriate location var dbPath = Path.Combine(FileSystem.AppDataDirectory, "maui-example.db"); var factory = new MAUISQLiteDBOpenFactory(new MDSQLiteOpenFactoryOptions() { DbFilename = dbPath }); var Db = new PowerSyncDatabase(new PowerSyncDatabaseOptions() { Database = factory, // Supply a factory Schema = AppSchema.PowerSyncSchema, }); await db.Init(); } } ``` ### 3. Integrate with your Backend The PowerSync backend connector provides the connection between your application backend and the PowerSync client-side managed SQLite database. It is used to: 1. Retrieve an auth token to connect to the PowerSync instance. 2. Apply local changes on your backend application server (and from there, to your backend database) Accordingly, the connector must implement two methods: 1. [PowerSyncBackendConnector.FetchCredentials](https://github.com/powersync-ja/powersync-dotnet/blob/main/demos/CommandLine/NodeConnector.cs#L50) - This is called every couple of minutes and is used to obtain credentials for your app backend API. -> See [Authentication Setup](/installation/authentication-setup) for instructions on how the credentials should be generated. 2. [PowerSyncBackendConnector.UploadData](https://github.com/powersync-ja/powersync-dotnet/blob/main/demos/CommandLine/NodeConnector.cs#L72) - Use this to upload client-side changes to your app backend. -> See [Writing Client Changes](/installation/app-backend-setup/writing-client-changes) for considerations on the app backend implementation. **Example**: ```cs using System; using System.Collections.Generic; using System.Net.Http; using System.Text; using System.Text.Json; using System.Threading.Tasks; using PowerSync.Common.Client; using PowerSync.Common.Client.Connection; using PowerSync.Common.DB.Crud; public class MyConnector : IPowerSyncBackendConnector { private readonly HttpClient _httpClient; // User credentials for the current session public string UserId { get; private set; } // Service endpoints private readonly string _backendUrl; private readonly string _powerSyncUrl; private string? _clientId; public MyConnector() { _httpClient = new HttpClient(); // In a real app, this would come from your authentication system UserId = "user-123"; // Configure your service endpoints _backendUrl = "https://your-backend-api.example.com"; _powerSyncUrl = "https://your-powersync-instance.powersync.journeyapps.com"; } public async Task FetchCredentials() { try { // Obtain a JWT from your authentication service. // See https://docs.powersync.com/installation/authentication-setup // If you're using Supabase or Firebase, you can re-use the JWT from those clients, see // - https://docs.powersync.com/installation/authentication-setup/supabase-auth // - https://docs.powersync.com/installation/authentication-setup/firebase-auth var authToken = "your-auth-token"; // Use a development token (see Authentication Setup https://docs.powersync.com/installation/authentication-setup/development-tokens) to get up and running quickly // Return credentials with PowerSync endpoint and JWT token return new PowerSyncCredentials(_powerSyncUrl, authToken); } catch (Exception ex) { Console.WriteLine($"Error fetching credentials: {ex.Message}"); throw; } } public async Task UploadData(IPowerSyncDatabase database) { // Get the next transaction to upload CrudTransaction? transaction; try { transaction = await database.GetNextCrudTransaction(); } catch (Exception ex) { Console.WriteLine($"UploadData Error: {ex.Message}"); return; } // If there's no transaction, there's nothing to upload if (transaction == null) { return; } // Get client ID if not already retrieved _clientId ??= await database.GetClientId(); try { // Convert PowerSync operations to your backend format var batch = new List

Environment Variable	Value
`PS\_DATABASE\_TYPE`	postgresql
`PS\_DATABASE\_URI`	Connection string obtained from Supabase See step 5 in [Connect PowerSync to Your Supabase](/integration-guides/supabase-+-powersync#connect-powersync-to-your-supabase)
`PS\_PORT`	Keep default value (8080)
`PS\_MONGO\_URI`	mongodb://mongo:27017
`PS\_JWKS\_URL`	Keep default value

```yaml {5} ... # Client (application end user) authentication settings client_auth: # Enable this if using Supabase Auth supabase: true ... ```

Environment Variable	Value
`PS\_DATABASE\_TYPE`	postgresql OR mongodb OR mysql
`PS\_DATABASE\_URI`	The database connection URI (according to your database type) where your data is stored.
`PS\_PORT`	Default value (8080) You can change this if you want the PowerSync Service to be available on a different port.
`PS\_MONGO\_URI`	mongodb://mongo:27017
`PS\_JWKS\_URL`	The URL of the JWKS endpoint of your authentication service.

```yaml {5, 11-15,18, 23} ... # Client (application end user) authentication settings client_auth: # Enable this if using Supabase Auth supabase: false # JWKS URIs can be specified here jwks_uri: !env PS_JWKS_URL # Optional static collection of public keys for JWT verification jwks: keys: - kty: 'oct' k: 'use_a_better_token_in_production' alg: 'HS256' # JWKS audience audience: ["powersync-dev", "powersync", "http://localhost:8080"] api: tokens: # These tokens are used for local admin API route authentication - use_a_better_token_in_production ``` # Base `Compose` file The following Compose file serves as a universal starting point for deploying the PowerSync Service on Coolify. ```yaml services: mongo: image: mongo:7.0 command: --replSet rs0 --bind_ip_all --quiet restart: unless-stopped ports: - 27017:27017 volumes: - mongo_storage:/data/db # Initializes the MongoDB replica set. This service will not usually be actively running mongo-rs-init: image: mongo:7.0 depends_on: - mongo restart: on-failure entrypoint: - bash - -c - 'mongosh --host mongo:27017 --eval ''try{rs.status().ok && quit(0)} catch {} rs.initiate({_id: "rs0", version: 1, members: [{ _id: 0, host : "mongo:27017" }]})''' # PowerSync Service powersync: image: journeyapps/powersync-service:latest container_name: powersync depends_on: - mongo-rs-init command: [ "start", "-r", "unified"] restart: unless-stopped environment: - NODE_OPTIONS="--max-old-space-size=1000" - POWERSYNC_CONFIG_PATH=/home/config/powersync.yaml - PS_DATABASE_TYPE=${PS_DEMO_BACKEND_DATABASE_TYPE:-postgresql} - PS_DATABASE_URI=${PS_DATABASE_URI:-postgresql://postgres:postgres@localhost:5432/postgres} - PS_PORT=${PS_PORT:-8080} - PS_MONGO_URI=${PS_MONGO_URI:-mongodb://mongo:27017} - PS_SUPABASE_AUTH=${USE_SUPABASE_AUTH:-false} - PS_JWKS_URL=${PS_JWKS_URL:-http://localhost:6060/api/auth/keys} ports: - ${PS_PORT}:${PS_PORT} volumes: - ./volumes/config:/home/config - type: bind source: ./volumes/config/sync_rules.yaml target: /home/config/sync_rules.yaml content: | bucket_definitions: user_lists: # Separate bucket per To-Do list parameters: select id as list_id from lists where owner_id = request.user_id() data: - select * from lists where id = bucket.list_id - select * from todos where list_id = bucket.list_id - type: bind source: ./volumes/config/powersync.yaml target: /home/config/powersync.yaml content: | # yaml-language-server: $schema=../schema/schema.json # Note that this example uses YAML custom tags for environment variable substitution. # Using `!env [variable name]` will substitute the value of the environment variable named # [variable name]. # migrations: # # Migrations run automatically by default. # # Setting this to true will skip automatic migrations. # # Migrations can be triggered externally by altering the container `command`. # disable_auto_migration: true # Settings for telemetry reporting # See https://docs.powersync.com/self-hosting/telemetry telemetry: # Opt out of reporting anonymized usage metrics to PowerSync telemetry service disable_telemetry_sharing: false # Settings for source database replication replication: # Specify database connection details # Note only 1 connection is currently supported # Multiple connection support is on the roadmap connections: - type: !env PS_DATABASE_TYPE # The PowerSync server container can access the Postgres DB via the DB's service name. # In this case the hostname is pg-db # The connection URI or individual parameters can be specified. # Individual params take precedence over URI params uri: !env PS_BACKEND_DATABASE_URI # Or use individual params # hostname: pg-db # From the Docker Compose service name # port: 5432 # database: postgres # username: postgres # password: mypassword # SSL settings sslmode: disable # 'verify-full' (default) or 'verify-ca' or 'disable' # 'disable' is OK for local/private networks, not for public networks # Required for verify-ca, optional for verify-full # This should be the certificate(s) content in PEM format # cacert: !env PS_PG_CA_CERT # Include a certificate here for HTTPs # This should be the certificate content in PEM format # client_certificate: !env PS_PG_CLIENT_CERT # This should be the key content in PEM format # client_private_key: !env PS_PG_CLIENT_PRIVATE_KEY # This is valid if using the `mongo` service defined in `ps-mongo.yaml` # Connection settings for sync bucket storage storage: type: mongodb uri: !env PS_MONGO_URI # Use these if authentication is required. The user should have `readWrite` and `dbAdmin` roles # username: my-mongo-user # password: my-password # The port which the PowerSync API server will listen on port: !env PS_PORT # Specify sync rules sync_rules: path: /home/config/sync_rules.yaml # Client (application end user) authentication settings client_auth: # Enable this if using Supabase Auth supabase: true # JWKS URIs can be specified here jwks_uri: !env PS_JWKS_URL # Optional static collection of public keys for JWT verification # jwks: # keys: # - kty: 'RSA' # n: !env PS_JWK_N # e: !env PS_JWK_E # alg: 'RS256' # kid: !env PS_JWK_KID # JWKS audience audience: ["powersync-dev", "powersync"] api: tokens: # These tokens are used for local admin API route authentication - use_a_better_token_in_production ``` {/* # Steps Add the PowerSync Service resource to your project by either scrolling through the `Services` section or by searching for `powersync` in the search bar.

The default one-click deployable PowerSync Service uses * MongoDB for internal storage, * PostgreSQL for replication, and * [Sync Rules](/usage/sync-rules) as defined for the To-Do List demo application found in [Demo Apps / Example Projects](/resources/demo-apps-example-projects). If you are running the demo To-Do List application, you can jump to Step 4 and simply deploy the PowerSync Service. Navigate to the `Environment Variables` tab and update the environment variables as per your requirements. For more information on what environment variables are available, see [Environment Variables](/tutorials/self-host/coolify#environment-variables).

Navigate to the `Storages` tab and update the `sync_rules.yaml` and `powersync.yaml` files as needed. For more information see [Sync Rules](/usage/sync-rules) and the skeleton config file in [PowerSync Service Setup](/self-hosting/installation/powersync-service-setup).

You can expand the content by dragging the bottom right corner of the editor.

There are two parameters whose values should be changed manually if necessary. - `disable_telemetry_sharing` in telemetry, and - `supabase` in client_auth Click on the `Deploy` button to deploy the PowerSync Service.

The PowerSync Service will now be available at * `http://localhost:8080` if default config was used, or * `http://{your_coolify_domain}:{PS_PORT}` if a custom domain or port was specified. */} {/* ## What to do next */} {/* Update your backend/client `.env` file with the PowerSync URL from [Step 4](#step-4-deploy-the-powersync-service) above. For this example we assume we have an environment variable named `POWERSYNC_URL`. ```bash POWERSYNC_URL=http://localhost:8080 ``` */} {/* ## Environment Variables

Environment Variable	Description	Example
`POWERSYNC_CONFIG_PATH`	This is the path (inside the container) to the YAML config file	/home/config/powersync.yaml
`PS_DATABASE_TYPE`	Database replication type	postgresql
`PS_BACKEND_DATABASE_URI`	Database connection URI	postgresql://postgres:postgres@localhost:5432/postgres
`PS_PORT`	The port the PowerSync API is accessible on	8080
`PS_MONGO_URI`	The MongoDB URI used internally by the PowerSync Service	mongodb://mongo:27017
`PS_JWKS_URL`	Auth URL	http://localhost:6060/api/auth/keys

*/} # FlutterFlow + PowerSync Source: https://docs.powersync.com/integration-guides/flutterflow-+-powersync Integration guide for creating local-first apps with FlutterFlow and PowerSync with Supabase as the backend. Used in conjunction with **FlutterFlow**, PowerSync enables developers to build local-first apps that are robust in poor network conditions and that have highly responsive frontends while relying on Supabase for their backend. This guide walks you through configuring PowerSync within your FlutterFlow project that has Supabase integration enabled. **New and Improved integration**: Welcome to our updated FlutterFlow integration guide. This version introduces a dedicated [PowerSync FlutterFlow Library](https://marketplace.flutterflow.io/item/dm1cuOwYzDv6yQL2QOFb), offering a simpler and more robust solution compared to the [previous version](/integration-guides/flutterflow-+-powersync/powersync-+-flutterflow-legacy) which required extensive custom code. Key improvements are: * Uses the new [PowerSync FlutterFlow Library](https://marketplace.flutterflow.io/item/dm1cuOwYzDv6yQL2QOFb) * Supports Web-based test mode * Streamlined Setup * No more dozens of custom actions * Working Attachments package - learn how to sync attachments [here](/integration-guides/flutterflow-+-powersync/handling-attachments). Note that using libraries in FlutterFlow requires being on a [paid plan with FlutterFlow](https://www.flutterflow.io/pricing). If this is not an option for you, you can use our [legacy guide](/integration-guides/flutterflow-+-powersync/powersync-+-flutterflow-legacy) with custom code to integrate PowerSync in your FlutterFlow project. This guide uses **Supabase** as the backend database provider for its seamless integration with PowerSync. However, you can integrate a different backend using custom actions. For more information, refer to the [Custom backend connectors](#custom-backend-connectors) section. ## Guide Overview Before starting this guide, you'll need: * A PowerSync account ([sign up here](https://accounts.journeyapps.com/portal/powersync-signup?s=docs)). * A Supabase account ([sign up here](https://supabase.com/dashboard/sign-up)). * A [paid plan](https://www.flutterflow.io/pricing) with FlutterFlow for the ability to import a Library into a project. This guide walks you through building a basic item management app from scratch and takes about 30-40 minutes to complete. You should then be able to use this knowledge to build and extend your own app. 1. Configure Supabase and PowerSync Prerequisites 2. Initialize Your FlutterFlow Project 3. Build a Sign-in Screen 4. Read Data 5. Create Data 6. Update Data (Guide coming soon) 7. Delete Data 8. Sign Out 9. (New) Display Connectivity and Sync Status 10. Secure Your App 11. Enable RLS in Supabase 12. Update Sync Rules in PowerSync ## Configure Supabase 1. Create a new project in Supabase. 2. To set up the Postgres database for our demo app, we will create a `lists` table. The demo app will have access to this table even while offline. Run the below SQL statement in your **Supabase SQL Editor**: ```sql create table public.lists ( id uuid not null default gen_random_uuid (), created_at timestamp with time zone not null default now(), name text not null, owner_id uuid not null, constraint lists_pkey primary key (id), constraint lists_owner_id_fkey foreign key (owner_id) references auth.users (id) on delete cascade ) tablespace pg_default ``` 3. PowerSync uses the Postgres [Write Ahead Log (WAL)](https://www.postgresql.org/docs/current/wal-intro.html) to replicate data changes in order to keep PowerSync SDK clients up to date. Run the below SQL statement in your **Supabase SQL Editor** to create a Postgres role/user with replication privileges: ```sql -- Create a role/user with replication privileges for PowerSync CREATE ROLE powersync_role WITH REPLICATION BYPASSRLS LOGIN PASSWORD 'myhighlyrandompassword'; -- Set up permissions for the newly created role -- Read-only (SELECT) access is required GRANT SELECT ON ALL TABLES IN SCHEMA public TO powersync_role; ``` To restrict read access to specific tables, explicitly list allowed tables for both the `SELECT` privilege, and for the publication mentioned in the next step (as well as for any other publications that may exist). 4. Create a Postgres publication using the SQL Editor. This will enable data to be replicated from Supabase so that your FlutterFlow app can download it. ```sql -- Create a publication to replicate tables. -- Specify a subset of tables to replicate if required. -- The publication must be named "powersync" CREATE PUBLICATION powersync FOR ALL TABLES; ``` ## Configure PowerSync ### Create a PowerSync Cloud Instance 1. In the **Overview** workspace of the [PowerSync Dashboard](/usage/tools/powersync-dashboard), you will be prompted to create your first instance:

If you've previously created an instance in your project, you can create an additional instance by navigating to **Manage instances** and clicking **Create new instance**:

You can also create an entirely new [project](/usage/tools/powersync-dashboard#hierarchy%3A-organization%2C-project%2C-instance) with its own set of instances. Click on the PowerSync icon in the top left corner of the Dashboard or on **Admin Portal** at the top of the Dashboard, and then click on **Create Project**. 2. Give your instance a name, such as "Testing". 3. \[Optional] You can change the default cloud region from US to EU, JP (Japan), AU (Australia) or BR (Brazil) if desired. * Note: Additional cloud regions will be considered on request, especially for customers on our Enterprise plan. Please [contact us](/resources/contact-us) if you need a different region. 4. \[Optional] You can opt in to using the `Next` version of the Service, which may contain early access or experimental features. Always use the `Stable` version in production. 5. Click **Next**. ### Connect PowerSync to Your Supabase 1. From your Supabase Dashboard, select **Connect** in the top navigation bar (or follow this [link](https://supabase.com/dashboard/project/_?showConnect=true)):

2. In the **Direct connection** section, copy the complete connection string (including the `[YOUR-PASSWORD]` placeholder)

3. Back in the PowerSync Dashboard, paste the connection string into the **URI** field. PowerSync will automatically parse this URI to populate the database connection details. 4. Update the **Username** and **Password** fields to use the `powersync_role` and password you created when configuring your Supabase for PowerSync (see [Source Database Setup](/installation/database-setup#supabase)). 5. Note: PowerSync includes Supabase's CA certificate by default, so you can use `verify-full` SSL mode without additional configuration. 6. Your connection settings should look similar to this:

7. Verify your setup by clicking **Test Connection** and resolve any errors. 8. Click **Next**. 9. PowerSync will detect the Supabase connection and prompt you to enable Supabase auth. To enable it, copy your JWT Secret from your project's settings ([JWT Keys](https://supabase.com/dashboard/project/_/settings/jwt) section in the Supabase dashboard) and paste it here:

10. Click **Enable Supabase auth** to finalize your connection settings. PowerSync will now create an isolated cloud environment for your instance. This typically takes a minute or two. You can update your instance settings by navigating to the **Manage instances** workspace, opening your instance options and selecting **Edit instance**.

### Configure Sync Rules [Sync Rules](/usage/sync-rules) allow developers to control which data gets synced to which user devices using a SQL-like syntax in a YAML file. For the demo app, we're going to specify that each user can only see their own lists. 1. To update your Sync Rules, open the `sync-rules.yaml` file.

2. Replace the `sync-rules.yaml` file's contents with the below: ```yaml # This will sync the entire table to all users - we will refine this later bucket_definitions: global: data: - SELECT * FROM lists ``` 3. In the top right, click **"Validate sync rules"** and ensure there are no errors. This validates your sync rules against your Postgres database. 4. In the top right, click **"Deploy sync rules"** and select your instance. 5. Confirm in the dialog and wait a couple of minutes for the deployment to complete. * For additional information on PowerSync's Sync Rules, refer to the [Sync Rules](/usage/sync-rules) documentation. * If you're wondering how Sync Rules relate to Supabase Postgres [RLS](https://supabase.com/docs/guides/auth/row-level-security), see [this subsection](/integration-guides/supabase-+-powersync/rls-and-sync-rules). ## Initialize Your FlutterFlow Project 1. Create a new Blank project in FlutterFlow. 2. Under **"App Settings" -> "Integrations"**, enable "Supabase". 1. Enter your Supabase "API URL" and public "Anon Key". You can find these under **"Project Settings" -> "API Keys" -> `anon` `public`** in your Supabase dashboard. 2. Click "Get Schema". 3. Add the [PowerSync Library](https://marketplace.flutterflow.io/item/dm1cuOwYzDv6yQL2QOFb) to your FlutterFlow account. 4. Under **"App Settings" -> "Project Dependencies" -> "FlutterFlow Libraries"** click "Add Library". 1. Select the "PowerSync" library. 2. Add your schema: 1. On the PowerSync Dashboard, right-click on your instance and select "Generate Client-Side Schema" and select "FlutterFlow" as the language.

2. Copy and paste the generated schema into the "PowerSyncSchema" field. 3. Copy and paste your PowerSync instance URL into the "PowerSyncUrl" field.

4. Note: The default path for the "HomePage" field under "Library Pages" can be left as is and ignored. FlutterFlow does not currently provide a way to remove it. 5. Close the library config. 5. Under **"Custom Pub Dependencies"**, add a dependency on `powersync_core:1.3.0`:

This version of `powersync_core` is required for running FlutterFlow on Web. ## Build A Sign-In Screen 1. Under the **"Page Selector"**, click **"Add Page, Component, or Flow"**.

2. Select the "Auth 1" template and name the page `Login`. 3. Delete the *Sign Up*, *Forgot Password* and *Social Login* buttons — we will only be supporting Sign In for this demo app.

4. Under **"App Settings" -> "App Settings" -> "Authentication"**: 1. Enable Authentication. 2. Set "Authentication Type" to "Supabase". 3. Set "Entry Page" to the `Login` page you just created. 4. Set "Logged In Page" to "HomePage".

5. In your Supabase Dashboard, under **"Authentication"**, click on **"Add User" -> "Create new user"** and create a user for yourself to test with:

6. Test your app with test mode:

**Checkpoint:** You should now be able to log into the app using the Supabase user account you just created. After logging in you should see a blank screen.

## Read Data We will now create our first UI and bind it to the data in the local SQLite database on the device. There are three ways to read data from the SQLite database using PowerSync's FlutterFlow library: 1. Auto-updating queries for Layout Elements with Dynamic Children e.g. the ListView Element * This uses the library's `PowerSyncQuery` component. 2. Auto-updating queries for basic Layout Elements e.g. Text Elements. * This uses the library's `PowerSyncStateUpdater` component. 3. Once-off reads for static data. * This uses the library's `PowerSyncQueryOnce` custom action. ### Prepare Supabase Tables for Reads For reading data in FlutterFlow, you need a Custom Function per Supabase table to map Supabase rows to data that can be used by the library. This is because FlutterFlow Libraries do not support Supabase classes. 1. Navigate to **"Custom Code"** and add a Custom Function. 2. Name the function `supabaseRowsToList` (if your Supabase table name is "Customers", you would name this `supabaseRowsToCustomers`). 3. Under **Function Settings** on the right, set the "Return Value" to `Supabase Row` 1. Check "Is List". 2. Uncheck "Nullable". 3. Under "Table Name", select `lists`. 4. Also under Function Settings, click "Add Arguments". 1. Set its "Name" to `supabaseRows` 2. Set its "Type" to "JSON". 3. Check "Is List". 4. Uncheck "Nullable". 5. In the Function Code, paste the following code: ```dart /// MODIFY CODE ONLY BELOW THIS LINE return supabaseRows.map((r) => ListsRow(r)).toList(); ``` 6. Click "Save Function".

### 1. Auto-updating queries for Layout Elements with Dynamic Children #### Create a Component to display List Items 1. Under the **"Page Selector"**, click **"Add Page, Component, or Flow"**. 2. Select the **"New Component"** tab. 3. Select "Create Blank" and call the component `ListItems`. 4. Under the **"Widget Palette"**, drag a "ListView" widget into the `ListItems` component. 5. Still under the **"Widget Palette"**, drag a "ListTile" into the `ListView` widget.

6. Under the **"Widget Tree"**, select the `ListItems` component. 1. At the top right under "Component Parameters" click "Add Parameters". 2. Click "Add Parameter". 3. Set its "Name" to `lists`. 4. Set its "Type" to `Supabase Row`. 5. Check "Is List". 6. Under "Table Name", select `lists`. 7. Click "Confirm". 7. Still under the **"Widget Tree"**, select the "ListView" widget. 1. Select the **"Generate Dynamic Children"** panel on the right. 2. Set the "Variable Name" to `listItem`. 3. Set the "Value" to the component parameter created in the previous step (`lists`). 4. Click "Confirm". 5. Click "Save". 6. Click "Ok" when being prompted about the widget generating its children dynamically.

8. Still under the **"Widget Tree"**, select the `ListTile` widget. 1. In the **"Properties"** panel on the right, under "Title", click on the settings icon next to "Text". 2. Set as "listItem Item". 3. Under "Available Options", select "Get Row Field". 4. Under "Supabase Row Fields", select "name". 5. Click "Confirm".

9. Repeat Step 8 above for the "Subtitle", setting it to "created\_at".

#### Display the List Component and populate it with Data 1. Under the **"Page Selector"**, select your `HomePage`. 2. Under the **"Widget Palette"**, select the "Components and custom widgets imported from library projects" panel.

3. Drag the `PowerSyncQuery` library component into your page. 4. In the Properties panel on the right, under **"Component Parameters" -> "child"**:

1. Click on "Unknown". 2. Select `ListItems` we previously created. 3. Click on `lists`. 4. Set the "Value" to "Custom Functions" -> `supabaseRowsToList` we created previously. 5. Under the `supabaseRows` argument, set the "Value" to "Widget Builder Parameters" -> `rows`. 6. Click "Confirm". 7. Click "Confirm". 5. Still under "Component Parameters" add the SQL query to fetch all list items from the SQLite database: 1. Paste the following into the "sql \[String]" field: `select * from lists order by created_at;` 2. For this query there are no parameters - this will be covered further down in the guide. 6. Still under "Component Parameters", check "watch \[Boolean]". This ensures that the query auto-updates. #### Test your App 1. Check that there are no project issues or errors. 2. Reload your app or start another test session. 3. Notice that your homepage is still blank. This is because the `lists` table is empty in Supabase. Create a test row in the table by clicking on "Insert" -> "Insert Row" in your Supabase Table Editor. 1. Leave `id` and `created_at` blank. 2. Enter a name such as "Test from Supabase". 3. Click "Select Record" for `owner_id` and select your test user. **Checkpoint:** You should now see your single test row magically appear in your app:

### 2. Auto-updating queries for basic Layout Elements In this section, we will be making the `ListView` component clickable and navigate the user to a page which will eventually display the list's To-Do items. This page will show the selected list's name in the title bar ("AppBar"). This uses Page State and the `PowerSyncStateUpdater` library component. #### Create a Page Parameter This parameter will store the selected list's ID. 1. Under the **"Page Selector"**, click **"Add Page, Component, or Flow"**.

2. Create a blank page and name it `Todos`. 3. Under the **"Widget Tree"**, select your `Todos` page. 4. At the top right of the **"Properties"** panel on the right, click on the plus icon for Page Parameters. 5. Click "Add Parameter". 6. Set the "Parameter Name" to `id`. 7. Set the "Type" to "String". 8. Click "Confirm". #### Create a Local Page State Variable This variable will store the selected list row. 1. Still in the **"Widget Tree"** with the `Todos` page selected: 2. Select the **"State Management Panel"** on the right.

3. Click on "Add Field". 4. Set "Field Name" to `list`. 5. Set the "Type" to "Supabase Row". 6. Under "Table Name", select `lists`. 7. Click "Confirm". #### Bind the Page Title to the Page State 1. Under the **"Widget Palette"**, select the "Components and custom widgets imported from library projects" panel.

2. Drag the `PowerSyncStateUpdater` library component into your page. 3. Under the **"Widget Tree"**, select the `PowerSyncStateUpdater` component. 4. In the **"Properties"** panel on the right, under "Component Parameters": 1. Add the SQL query to fetch the selected list from the SQLite database. Paste the following into the "sql \[String]" field: `select * from lists where id = :id;` 2. Click on "parameters \[Json]" select "Create Map (JSON)" as the variable. 1. Under "Add Map Entries", click "Add Key Value Pair". 2. Set the "Key" to `id`. 3. Set the "Value" to the page parameter created previously called `id`. 4. Check "watch \[Boolean]". This ensures that the query auto-updates. 5. Click "Confirm".

5. Still under "Component Parameters", configure the "onData" action: 1. Open the "Action Flow Editor". 2. Select the "Callback" trigger type. 3. Click "Add Action". 4. Search for "update page" and select "Update Page State". 5. Click "Add Field". 6. Select your `list` page state variable. 7. Set "Select Update Type" to "Set Value". 8. Set "Value to set" to "Custom Functions" -> `supabaseRowsToList`. 9. Set the "Value" to "Callback Parameters" -> `rows` 10. Click "Confirm". 11. Under "Available Options", select "Item at Index". 12. Set "List Index Options" to "First" 13. Click "Confirm".

14. Close the Action Flow Editor. 6. Still under the **"Widget Tree"**, select the "AppBar" -> "Text" widget. 1. In the **"Properties"** panel on the right, click on settings icon next to "Text". 2. Click on "Page State" -> "List". 3. Set "Supabase Row Fields" to "name". 4. (Optional) Set the "Default Variable Value" to `List Name`. 5. Click "Confirm". #### Make the `ListView` Component Clickable 1. Under the **"Page Selector"**, select your `ListItems` component. 2. Under the **"Widget Tree"**, select the `ListTile` widget. 3. In the **"Actions"** panel on the right, click "Add Action". "On Tap" should be selected by default. 4. In the "Navigation" subsection, select "Navigate To". 5. Select the "Todos" page. 6. Under "Parameters" click "Pass". 7. "id" should be auto-selected, click on it. 8. Click on the settings icon next to "Value" 9. Set it to "listItem Item". 10. Under "Available Options" select "Get Row Field" 11. Under "Supabase Row Fields" select "id". 12. Click "Confirm". 13. (Optional) Enable the back button to navigate back: 1. Under the **"Page Selector"**, select your `Todos` page. 2. Under the **"Widget Tree"**, select the "AppBar" component. 3. In the **"Properties"** panel on the right, enable "Show Default Button". #### Test your App Instant Reload your app or start another test session. **Checkpoint:** You should now be able to click on a list item and it should navigate you to a new page showing the name of the list in the title bar:

### 3. Once off reads for static data This section is a work in progress. Please reach out on [our Discord](https://discord.gg/powersync) if you have any questions. ## Create Data You will now update the app so that we can capture new list entries. 1. Under the **"Page Selector"**, select your `HomePage` page. 2. Under the **"Widget Palette"**, search for "float" and drag the "FAB" widget onto your page. 3. In the **"Actions"** panel on the right, click "Add Action". 1. Under "Custom Action" -> "PowerSync", select "powersyncWrite". 2. Under the "Set Action Arguments" -> "sql" section, add the SQL query to create a new list item. For the purpose of this guide we are hardcoding the list's name, normally you would build UI for this. 1. Paste the following into the "Value" field: `INSERT INTO lists(id, created_at, name, owner_id) VALUES(uuid(), datetime(), 'new item', :userId);` 3. Under the "parameters" section, set the `userId` parameter we're using the above query: 1. Click on "UNSET". 2. Select "Create Map (JSON)" as the variable. 3. Under "Add Map Entries", click "Add Key Value Pair". 4. Set the "Key" to `userId`. 5. Set the "Value" to "Authenticated User" -> "User ID". 6. Click "Confirm". **Checkpoint:** Reload your app and click on the + floating action button. A new list item should appear, which also automatically syncs to Supabase:

## Update Data Updating data is possible today using the `powersyncWrite` helper of the Library, and a guide will be published soon. In the mean time, use the section below about [Deleting Data](#delete-data) as a reference. Please reach out on [our Discord](https://discord.gg/powersync) if you have any questions. ## Delete Data In this section we will add the ability to swipe on a `ListTile` to delete it. 1. Under the **"Page Selector"**, select your `ListItems` component. 2. Under the **"Widget Tree"**, select the `ListTile` widget. 3. In the **"Properties"** panel on the right, enable "Slidable". 4. Click "Open Slidable". 5. Select the "SlidableActionWidget".

6. In the **"Actions"** panel on the right, click "Add Action". 1. Under "Custom Action" -> "PowerSync", select "powersyncWrite". 2. Under the "Set Action Arguments" -> "sql" section, add the SQL query to delete the list item. 1. Paste the following into the "Value" field: `delete from lists where id = :id;` 3. Under the "parameters" section, set the `id` parameter we're using the above query: 1. Click on "UNSET". 2. Select "Create Map (JSON)" as the variable. 3. Under "Add Map Entries", click "Add Key Value Pair". 4. Set the "Key" to `id`. 5. Set the "Value" to "listItem Item". 6. Under "Available Options" select "Get Row Field". 7. Under "Supabase Row Fields" select "id". 8. Click "Confirm". 9. Click "Confirm". **Checkpoint:** Reload your app and swipe on a list item. Delete it, and note how it is deleted from the list as well as from Supabase. ## Sign Out 1. Navigate to **"Custom Code"** and create a new Custom Action called `signOut` without Arguments or Return Values and paste the below code: In the below code, `power_sync_b0w5r9` is the project ID of the PowerSync library. Update it if it changes. ```dart // Automatic FlutterFlow imports import '/backend/supabase/supabase.dart'; import "package:power_sync_b0w5r9/backend/schema/structs/index.dart" as power_sync_b0w5r9_data_schema; import 'package:ff_theme/flutter_flow/flutter_flow_theme.dart'; import '/flutter_flow/flutter_flow_util.dart'; import '/custom_code/actions/index.dart'; // Imports other custom actions import '/flutter_flow/custom_functions.dart'; // Imports custom functions import 'package:flutter/material.dart'; // Begin custom action code // DO NOT REMOVE OR MODIFY THE CODE ABOVE! import 'package:power_sync_b0w5r9/custom_code/actions/initialize_power_sync.dart' as ps; Future signOut() async { final database = await ps.getOrInitializeDatabase(); //await database.disconnectAndClear(); // this will completely delete all the local data, use with caution as there may be items still in the upload queue await database .disconnect(); //this will simply disconnect from the PowerSync Service and preserve all local data } // Set your action name, define your arguments and return parameter, // and then add the boilerplate code using the green button on the right! ``` 2. Click "Save Action". 3. Under the **"Page Selector"**, select your `HomePage` page. 4. Under the **"Widget Palette"**, drag a "Button" onto the right of your "AppBar".

5. In the **"Properties"** panel on the right, rename the "Button Text" to `Sign Out`. 6. Switch to the **"Actions"** panel and open the **"Action Flow Editor"**. 7. Select "On Tap" as the action trigger. 8. Click "Add Action" and add a call to the `signOut` Custom Action. 9. Chain another Action and call to "Supabase Authentication" -> "Log Out":

10. Click "Close". **Checkpoint:** You should now be able to reload your app and sign out and in again. ## (Optional) Display Connectivity and Sync Status The PowerSync library provides a built-in component that displays real-time connectivity and synchronization status. Since the sync state is available globally as part of your app state, you can easily monitor the database status throughout your application. To add this status indicator: 1. Under the **Widget Palette**, select the "Components and custom widgets imported from library projects" panel.

2. Drag the `PowerSyncConnectivity` component into your home page's "AppBar".

## Secure Your App PowerSync's [Sync Rules](/usage/sync-rules) and Supabase's support for [Row Level Security (RLS)](https://supabase.com/docs/guides/auth/row-level-security) can be used in conjunction. Here are some high level similarities and differences: * RLS should be used as the authoritative set of security rules applied to your users' CRUD operations that reach Postgres. * Sync Rules are only applied for data that is to be downloaded to clients — they do not apply to uploaded data. * Sync Rules can typically be considered to be complementary to RLS, and will generally mirror your RLS setup. ### Enable RLS in Supabase Run the below in your Supabase console to ensure that only list owners can perform actions on the lists table where `owner_id` matches their user id: ```sql alter table public.lists enable row level security; create policy "owned lists" on public.lists for ALL using ( auth.uid() = owner_id ) ``` ### Update Sync Rules Currently all lists are synced to all users, regardless of who the owner of the list is. You will now update this so that only a user's lists are synced to their device: 1. Navigate to the [PowerSync Dashboard](https://powersync.journeyapps.com/) and open your `sync-rules.yaml` file. 2. Delete the existing content and paste the below contents: ```yaml bucket_definitions: user_lists: parameters: select request.user_id() as user_id data: - select * from lists where owner_id = bucket.user_id ``` 3. Click on **"Validate"**. 4. Click on **"Deploy sync rules"**. 5. Wait for the deploy to complete. **Checkpoint:** Your app should continue running seamlessly as before. ## Arrays, JSON and Other Types For column values, PowerSync supports three basic types: Integers, doubles, and strings. These types have been chosen because they're natively supported by SQLite while also being easy to transport as JSON. Of course, you may want to to store other values in your Postgres database as well. When syncing a value that doesn't fit into the three fundamental types, PowerSync will [encode it as a JSON string](/usage/use-case-examples/custom-types-arrays-and-json#custom-types). To use those values in your app, you'll need to apply a mapping so that you display the correct values and use the correct representation when uploading data. As an example, let's consider an added `tags` column on the `lists` table used in this guide. These tags will be encoded as a string array in Postgres: ```SQL CREATE TABLE public.lists ( # ... existing columns, tags text[] DEFAULT '{"default", "tags"}' ); ``` Like all array values, PowerSync will transport this as a JSON string. For instance, a row with the default tags would be represented as this string: `["default", "tags"]`. FlutterFlow does not support extracting a list from that string, so the [custom functions](#read-data) responsible for mapping SQLite rows to FlutterFlow classes needs to be aware of the transformation and reverse it: ```dart /// MODIFY CODE ONLY BELOW THIS LINE return supabaseRows.map((r) { return ListsRow({ ...r, 'tags': jsonDecode(r['tags'] as String), }); }).toList(); ``` This transforms the `'["default", "tags"]'` value as it appears into `["default", "tags"]`, the list value expected for this row. A similar approach is necessary when making local writes. The local database should be consistent with the data synced with PowerSync. So all [local writes](#create-data) should write array and JSON values as strings by encoding them as JSON. Finally, the PowerSync mapping also needs to be reverted when uploading rows to Postgres. For a `text[]` column for instance, the local string value would not be accepted by Supabase. For this reason, the upload behavior for columns with advanced types needs to be customized. **New feature:** This option has been added in version `0.0.7` of the PowerSync FlutterFlow library. Please make sure you're using that version or later. To customize the uploading behavior, create a new custom action (e.g. `applyPowerSyncOptions`). After the default imports, put this snippet: ```dart import 'package:power_sync_b0w5r9/custom_code/actions/initialize_power_sync.dart'; Future applyPowerSyncOptions() async { // Add your function code here! powerSyncOptions.transformData = (table, data) { switch (table) { case 'lists': data['tags'] = jsonDecode(data['tags'] as String); } }; } ``` Also, add this function to your `main.dart` as a final action. When setting `powersyncOptions.transformData`, a callback is invoked every time a created or updated row is uploaded to Supabase. This allows you to customize how individual values are represented for Postgres. In this case, the `tags` column of the `lists` table is decoded as JSON so that it's uploaded as a proper array while being stored as a list locally. ## Custom Backend Connectors To enable an easy setup, the PowerSync FlutterFlow library integrates with Supabase by default. This means that as long as you use Supabase for authentication in your app, PowerSync will automatically connect as soon as users log in, and can automatically upload local writes to a Supabase database. For apps that don't use Supabase, you can disable this default behavior and instead rely on your own backend connectors. For this, create your own custom action (e.g. `applyPowerSyncOptions`). It's important that this action runs before anything else in your app uses PowerSync, so add this action to your `main.dart` as a final action. ```dart import 'package:power_sync_b0w5r9/custom_code/actions/initialize_power_sync.dart'; import 'package:powersync/powersync.dart' as ps; Future applyPowerSyncOptions() async { // Disable the default Supabase integration powerSyncOptions.useSupabaseConnector = false; final db = await getOrInitializeDatabase(); // TODO: Write your own connector and call connect/disconnect when a user logs // in. db.connect(connector: _MyCustomConnector()); } final class _MyCustomConnector extends ps.PowerSyncBackendConnector { @override Future fetchCredentials() { // TODO: implement fetchCredentials throw UnimplementedError(); } @override Future uploadData(ps.PowerSyncDatabase database) { // TODO: implement uploadData throw UnimplementedError(); } } ``` For more information on writing backend connectors, see [integrating with your backend](/client-sdk-references/flutter#3-integrate-with-your-backend). ## Known Issues, Limitations and Gotchas Below is a list of known issues and limitations. 1. Deploying to the Apple App Store currently requires some workarounds due to limitations in FlutterFlow: 1. Download the code from FlutterFlow. 2. Open the `Podfile` located in the `ios/` directory. 3. The following option in the `Podfile` needs to be updated from `use_frameworks! :linkage => :static` to `use_frameworks!` (remove everything after the exclamation sign). 4. After removing that option, clean the build folder and build the project again. 5. You should now be able to submit to the App Store. 2. Exporting the code from FlutterFlow using the "Download Code" action in FlutterFlow requires the same workaround listed above. 3. Other common issues and troubleshooting techniques are documented here: [Troubleshooting](/resources/troubleshooting). # Flutter Web Source: https://docs.powersync.com/integration-guides/flutterflow-+-powersync/flutter-web PowerSync supports Flutter Web. This section is a work in progress — reach out to us on our [Discord](https://discord.gg/powersync) if you need assistance in the meantime. # Full-Text Search Source: https://docs.powersync.com/integration-guides/flutterflow-+-powersync/full-text-search PowerSync supports [Full-Text Search](/usage/use-case-examples/full-text-search) on all Flutter platforms. This section is a work in progress — reach out to us on our [Discord](https://discord.gg/powersync) if you need assistance in the meantime. # Handling Attachments Source: https://docs.powersync.com/integration-guides/flutterflow-+-powersync/handling-attachments Learn how to sync attachments such as images and PDFs with PowerSync, FlutterFlow and Supabase Storage. You can synchronize attachments, such as images and PDFs, between user devices and a remote storage provider using the [`powersync_attachments_helper`](https://pub.dev/packages/powersync_attachments_helper) package for Flutter. This guide uses Supabase Storage as the remote storage provider to store and serve photos. Other media types, like [PDFs](/tutorials/client/attachments-and-files/pdf-attachment), are also supported. At a high level, the \[`powersync_attachments_helper`] package syncs attachments by: * Storing files locally on the device in a structured way, linking them to specific database records. * Maintaining attachment metadata in the local SQLite database to track the sync state of each attachment. * Managing uploads, downloads, and retries through a local attachment queue to ensure local files stay in sync with remote storage. * Providing a file operations API with methods to add, remove, and retrieve attachments. ## Prerequisites To follow this guide, ensure you have completed the [FlutterFlow + PowerSync integration guide](/integration-guides/flutterflow-+-powersync). At minimum, you should have implemented everything up to step 4, which involves reading data where your app's `lists` are displayed and clickable. ## Update schema to track attachments Here we add a `photo_id` column to the `lists` table to link a photo to a list. ### Update Supabase schema 1. In your Supabase dashboard, run the below SQL statement in your Supabase SQL Editor to add the `photo_id` column to the `lists` table: ```sql ALTER TABLE public.lists ADD COLUMN photo_id text; ``` 2. In FlutterFlow, under **"App Settings" -> "Integrations"**, click "Get Schema". ### Update PowerSync schema The schema of the local SQLite database should now be updated to include the new `photo_id` column. Additionally, we need to set up a local-only table to store the metadata of photos which is being managed by the helper package. 1. In the PowerSync Dashboard, generate your updated client-side schema: Right-click on your instance and select "Generate Client-Side Schema" and select "FlutterFlow" as the language.

2. In FlutterFlow, under "App Settings" -> "Project Dependencies" -> "FlutterFlow Libraries", click "View Details" of the PowerSync library. 3. Copy and paste the generated schema into the "PowerSyncSchema" field. ## Configure Supabase Storage 1. To configure Supabase Storage for your app, navigate to the **Storage** section of your Supabase project and create a new bucket:

2. Give the storage bucket a name, such as **media**, and hit "Save".

3. Next, configure a policy for this bucket. For the purpose of this demo, we will allow all user operations on the media bucket. 4. Create a new policy for the **media** bucket:

2. Give the new policy a name, and allow SELECT, INSERT, UPDATE, and DELETE.

3. Proceed to review and save the policy. 4) Finally, back in FlutterFlow, create an App Constant to store the bucket name: 1. Under **"App Values" -> "Constants"**, click "Add App Constant". 2. Set "Constant Name" to `supabaseStorageBucket`. 3. Click "Create". 4. Set the "Value" to the name of your Supabase Storage bucket, e.g. `media`.

## Add the PowerSync Attachments Helper to your project 1. Under **"App Settings" -> "Project Dependencies" -> "Custom Pub Dependencies"** click "Add Pub Dependency". 2. Enter `powersync_attachments_helper: ^0.6.18`. 3. Click "Add". ## Create `setUpAttachments` Custom Action This creates an attachment queue which is responsible for tracking, storing and synching attachment metadata and CRUD operations. 1. Navigate to **"Custom Code"** and add a Custom Action. 2. Name the action `setUpAttachments`. 3. Add the following code: In the below code, `power_sync_b0w5r9` is the project ID of the PowerSync library. Update it if it changes. ```dart // DO NOT REMOVE OR MODIFY THE CODE ABOVE! import 'dart:async'; import 'dart:io'; import 'package:powersync/powersync.dart' as powersync; import 'package:powersync_attachments_helper/powersync_attachments_helper.dart'; import 'package:power_sync_b0w5r9/custom_code/actions/initialize_power_sync.dart' show db; Future setUpAttachments() async { // Add your function code here! await _initializeAttachmentQueue(db); } PhotoAttachmentQueue? attachmentQueue; final _remoteStorage = SupabaseStorageAdapter(); class SupabaseStorageAdapter implements AbstractRemoteStorageAdapter { @override Future uploadFile(String filename, File file, {String mediaType = 'text/plain'}) async { _checkSupabaseBucketIsConfigured(); try { await Supabase.instance.client.storage .from(FFAppConstants.supabaseStorageBucket) .upload(filename, file, fileOptions: FileOptions(contentType: mediaType)); } catch (error) { throw Exception(error); } } @override Future downloadFile(String filePath) async { _checkSupabaseBucketIsConfigured(); try { return await Supabase.instance.client.storage .from(FFAppConstants.supabaseStorageBucket) .download(filePath); } catch (error) { throw Exception(error); } } @override Future deleteFile(String filename) async { _checkSupabaseBucketIsConfigured(); try { await Supabase.instance.client.storage .from(FFAppConstants.supabaseStorageBucket) .remove([filename]); } catch (error) { throw Exception(error); } } void _checkSupabaseBucketIsConfigured() { if (FFAppConstants.supabaseStorageBucket.isEmpty) { throw Exception( 'Supabase storage bucket is not configured in App Constants'); } } } /// Function to handle errors when downloading attachments /// Return false if you want to archive the attachment Future onDownloadError(Attachment attachment, Object exception) async { if (exception.toString().contains('Object not found')) { return false; } return true; } class PhotoAttachmentQueue extends AbstractAttachmentQueue { PhotoAttachmentQueue(db, remoteStorage) : super( db: db, remoteStorage: remoteStorage, onDownloadError: onDownloadError); @override init() async { if (FFAppConstants.supabaseStorageBucket.isEmpty) { log.info( 'No Supabase bucket configured, skip setting up PhotoAttachmentQueue watches'); return; } await super.init(); } @override Future saveFile(String fileId, int size, {mediaType = 'image/jpeg'}) async { String filename = '$fileId.jpg'; Attachment photoAttachment = Attachment( id: fileId, filename: filename, state: AttachmentState.queuedUpload.index, mediaType: mediaType, localUri: getLocalFilePathSuffix(filename), size: size, ); return attachmentsService.saveAttachment(photoAttachment); } @override Future deleteFile(String fileId) async { String filename = '$fileId.jpg'; Attachment photoAttachment = Attachment( id: fileId, filename: filename, state: AttachmentState.queuedDelete.index); return attachmentsService.saveAttachment(photoAttachment); } @override StreamSubscription watchIds({String fileExtension = 'jpg'}) { log.info('Watching photos in lists table...'); return db.watch(''' SELECT photo_id FROM lists WHERE photo_id IS NOT NULL ''').map((results) { return results.map((row) => row['photo_id'] as String).toList(); }).listen((ids) async { List idsInQueue = await attachmentsService.getAttachmentIds(); List relevantIds = ids.where((element) => !idsInQueue.contains(element)).toList(); syncingService.processIds(relevantIds, fileExtension); }); } } Future _initializeAttachmentQueue(powersync.PowerSyncDatabase db) async { final queue = attachmentQueue = PhotoAttachmentQueue(db, _remoteStorage); await queue.init(); } ``` 4. Click "Save Action". ## Add Final Actions to your `main.dart` We need to call `initializePowerSync` from the Library to create the PowerSync database, and then call `setUpAttachments` to create the attachments queue. These actions need to happen in this specific order since `setUpAttachments` depends on having the database ready. 1. Still under **Custom Code**, select `main.dart`. Under **File Settings -> Final Actions**, click the plus icon. 2. Select `initializePowerSync`. 3. Click the plus icon again, and select `setUpAttachments`.

4. Save your changes. **Continue by using Local Run** Due to a known FlutterFlow limitation, web test mode will crash when both Supabase integration is enabled and actions are added to `main.dart`. Please continue by using Local Run to test your app. ## Create `resolveItemPicture` Custom Action (downloads) This action handles downloads by taking an attachment ID and returning an `UploadedFile`, which is FLutterFlow's representation of an in-memory file asset. This action calls `attachmentQueue.getLocalUri()` and reads contents from the underlying file. 1. Create another Custom Action and name it `resolveItemPicture`. 2. Add the following code: ```dart // DO NOT REMOVE OR MODIFY THE CODE ABOVE! import 'dart:io'; import 'set_up_attachments.dart'; Future resolveItemPicture(String? id) async { if (id == null) { return null; } final name = '$id.jpg'; final path = await attachmentQueue?.getLocalUri(name); if (path == null) { return null; } final file = File(path); if (!await file.exists()) { return null; } return FFUploadedFile( name: name, bytes: await file.readAsBytes(), ); } ``` 3. Under **Action Settings -> Define Arguments** on the right, click "Add Arguments". 1. Set the "Name" to `id`. 4. Click "Save Action". 5. Click "Yes" when prompted about parameters in the settings not matching parameters in the code editor. ## Create `setItemPicture` Custom Action (uploads) This action handles uploads by passing the `UploadedFile` to local storage and then to the upload queue. 1. Create another Custom Action and name it `setItemPicture`. 2. Add the following code: In the below code, `power_sync_b0w5r9` is the project ID of the PowerSync library. Update it if it changes. ```dart // DO NOT REMOVE OR MODIFY THE CODE ABOVE! import 'package:power_sync_b0w5r9/custom_code/actions/initialize_power_sync.dart' show db; import 'package:powersync/powersync.dart' as powersync; import 'set_up_attachments.dart' show attachmentQueue; Future setItemPicture( FFUploadedFile? picture, Future Function(String? photoId) applyToDatabase, ) async { if (picture == null) { await applyToDatabase(null); return; } final queue = attachmentQueue; if (queue == null) { return; } String photoId = powersync.uuid.v4(); final storageDirectory = await queue.getStorageDirectory(); await queue.localStorage .saveFile('$storageDirectory/$photoId.jpg', picture.bytes!); queue.saveFile(photoId, picture.bytes!.length); await applyToDatabase(photoId); } ``` 3. Under **Action Settings -> Define Arguments** on the right, click "Add Arguments". 1. Set the "Name" to `picture`. 2. Under "Type" select "UploadedFile". 4. Click "Add Arguments" again. 1. Set the "Name" to `applyToDatabase`. 2. Under "Type" select "Action". 3. Add an Action Parameter. 4. Set the "Name" to `photoId`. 5. Set its "Type" to "String". 5. Click "Save Action". 6. Click "Yes" when prompted about parameters in the settings not matching parameters in the code editor. 7. Check the Custom Actions for any errors.

**Compilation errors:** If, at this stage, you receive errors for any of the custom actions, test your app and ensure there are no errors in your Device Logs. FlutterFlow does occasionally show false compilation errors which can safely be ignored. ## Create a Custom Component to display and upload photos Next, we'll create a custom component that displays an image and includes a button to upload or replace the image file. You can use this component throughout your app wherever you need to display and update images. ### Create the UI widgets of the component 1. Under the **"Page Selector"**, click "Add Page, Component, or Flow".

2. Select the "New Component" tab. 3. Select "Create Blank" and call the component `ListImage`. 4. Under the **"Widget Tree"**, click on "Add a child to this widget".

1. Add the "Image" widget. 2. Expand the width of the image to fill the available space.

5. Click on "Add a child to this widget" for the `ListImage` again. 1. Add the "Button" widget. 2. Select "Wrap in Column" when prompted. ### Set component parameters and state variables 1. Still under the **"Widget Tree"**, select the `ListImage` component. 1. At the top right under "Component Parameters" click "Add Parameters". 2. Click "Add Parameter". 3. Set its "Name" to `listId`. 4. Set its "Type" to `String`. 5. Click "Confirm". 2. In the same panel, add Local Component State Variables: 1. Define a variable to store the image file: 1. Click "Add Field". 2. Set its "Field Name" to `image`. 3. Set its "Type" to `Uploaded File`. 2. Define a variable that stores the ID of the image: 1. Click "Add Field" again. 2. Set its "Field Name" to `photoId`. 3. Set its "Type" to `String`. 4. Check "Nullable. 3. Define a variable that indicates whether an image is loaded or not. We'll use this to set conditional visibility of the component: 1. Click "Add Field" again. 2. Set its "Field Name" to `imageLoaded`. 3. Set its "Type" to `Boolean`. 4. Toggle "Initial Field Value" on and off (click it twice) to set it to false. 4. Click "Confirm".

### Set conditional visibility and state 1. Back under the **"Widget Tree"**, select the `Image` widget. 1. In the **"Properties"** panel on the right, enable "Conditional" under "Visibility". 1. Click on "Unset". 2. Select the "Component State" -> `imageLoaded` state variable. 3. Click "Confirm". 2. Further down in the **"Properties"** panel, set the "Image Type" to "Uploaded File". 1. Select the "Component State" -> `image` state variable. 2. Click "Confirm". ### Define the Image widget logic 1. Under the **"Widget Tree"**, select the "Column" component within your `ListImage` component. 1. Click "Add a child to this widget". 2. Add the "Container" widget. 3. In the **"Properties"** panel on the right, set its "Width" and "Height" to 0 respectively. This container can be hidden. 4. Back under the **"Widget Tree"**, click "Add a child to this widget" for the "Container". 5. Select the "Select the "Components and custom widgets imported from library projects" panel, and select the `PowerSyncStateUpdater` component.

6. In the **"Properties"** panel on the right, under the "Component Properties" section: 1. Under the "sql" section, add the SQL query to set the photo: `select * from lists where id = :id;` 2. Under the "parameters" section, set the `id` parameter we're using the above query: 3. Click on "UNSET". 4. Select "Create Map (JSON)" as the variable. 5. Under "Add Map Entries", click "Add Key Value Pair". 6. Set the "Key" to `id`. 7. Set the Value to "Component Parameters" -> `listId`. 8. Click "Confirm". 9. Check "watch \[Boolean]". This ensures that the query auto-updates. 10. Configure the "onData" action: 1. Open the "Action Flow Editor". 2. Select the "Callback" trigger type. 3. Click "Add Action". 1. Search for "update com" and select "Update Component State". 2. Click "Add Field". 3. Select your `photoId` state variable. 4. Set "Select Update Type" to "Set Value". 5. Set "Value to set" to "Callback Parameters" -> `rows`. 6. Under "Available Options", select "Item at Index". 7. Under "List Index Options" select "First". 8. Under "Available Options" select "JSON Path". 9. Set "JSON Path" to `$.photo_id`. 10. Click "Confirm".

11. Set "Update Type" to "No Rebuild". 4. Chain another action and select the `resolveItemPicture` custom action. 1. Under "Set Action Arguments", click on the settings icon next to "Value". 2. Select "Callback Parameters" -> `rows`. 3. Under "Available Options", select "Item at Index". 4. Under "List Index Options" select "First". 5. Under "Available Options" select "JSON Path". 6. Set "JSON Path" to `$.photo_id`. 7. Click "Confirm". 8. Set "Action Output Variable Name" to `picture`. 5. Chain another action, search for "update com" and select "Update Component State". 1. Click on "Add Field". 2. Select the "image - Uploaded File" state variable. 3. Under "Select Update Type", select "Set Value". 4. Set the "Value to set" to the "Action Outputs" -> `picture` variable. 5. Click "Confirm". 6. Click on "Add Field" again. 7. Select the "imageLoaded" state variable. 8. Under "Select Update Type", select "Set Value". 9. Click on the settings icon next to "Value to set" and select "Code Expression". 10. Select "Code Expression". 11. Click on "Add argument". 12. Select the "var1" placeholder argument. 13. Set its "Name" to `photoId`. 14. Check "Nullable". 15. Set the "Value" to the "Component State" -> `photoId` state variable. 16. Set the "Expression" to `photoId != null && photoId != 'null'`. 17. Ensure there are no errors. 18. Click "Confirm".

6. Close the Action Flow Editor. ### Define the Button widget logic 1. Under the **"Widget Tree"**, select the "Button" widget. 2. In the **"Properties"** panel on the right, under "Button Text", update the text to `Add/replace image`. 3. Switch to the **"Actions"** panel and open the **"Action Flow Editor"**. 4. Select the "On Tap" trigger type. 5. Add an action, search for "media" and select "Upload/Save Media". 6. Under "Upload Type" select "Local Upload (Widget State). 7. Chain another action and select the `setItemPicture` custom action. 8. Under "Set Action Arguments", under the "picture" argument, set the "Value", to the "Widget State" -> "Uploaded Local File" variable. 9. Click "Confirm". 10. Under the "applyToDatabase" argument, add an action and under "Custom Action" -> "PowerSync", select "powersyncWrite". 11. Under the "Set Action Arguments" -> "sql" section, add the SQL query to update the photo. 1. Paste the following into the "Value" field: `update lists set photo_id = :photo where id = :id;` 2. Under the "parameters" section, set the `photo` parameter and `id` parameters we're using the above query: 3. Click on "UNSET". 4. Select "Create Map (JSON)" as the variable. 5. Under "Add Map Entries", click "Add Key Value Pair". 6. Set the "Key" to `photo`. 7. Set the "Value" to "Action Parameter" -> `photoId`. 8. Click "Confirm". 9. Add another Key Value Pair. 10. Set the "Key" to `id`. 11. Set the Value to "Component Parameters" -> `listId`. 12. Click "Confirm". ## Add the `ListImage` Custom Component to your page 1. Under the **"Page Selector"**, select the `Todos` page. 2. Under the **"Widget Tree"**, right-click on the `PowerSyncStateUpdater` library component. 1. Select "Wrap Widget". 2. Select the "Container" widget. 3. In the **"Properties"** panel on the right, set the Container's "Width" and "Height" to 0 respectively. This container can be hidden. 3. Back under the **"Widget Tree"**, add a child to the "Column" widget. 1. Select the "Components and custom widgets defined in this project" panel, and select the `ListImage` component.

2. In the `ListImage` **"Properties"** panel on the right, under "Component Parameters", click on the settings icons next to "listId \[String]". 3. Select the "Page Parameter" -> `id` variable. 4. Click "Confirm". **Test your app:** You should now be able to test your app, select a list item and add or replace an image on the next page:

In Supabase, notice how the image is uploaded to your bucket in Supabase Storage, and the corresponding list has the `photo_id` column set with a reference to the file. # FlutterFlow + PowerSync Legacy Guide Source: https://docs.powersync.com/integration-guides/flutterflow-+-powersync/powersync-+-flutterflow-legacy Legacy integration guide for creating local-first apps with FlutterFlow and PowerSync with Supabase as the backend. This guide demonstrates our previous FlutterFlow integration approach that uses custom actions. For a simpler and more robust solution, we recommend following our [updated guide](/integration-guides/flutterflow-+-powersync) which leverages the official PowerSync FlutterFlow library.