Writing Client Changes

This could be:

1. A single endpoint accepting a batch of changes from the client, with minimal client-side processing.
2. Separate endpoints based on the types of changes.
3. A combination of the above.

​

Changes recorded on the client

The change queue on the client stores three types of operations:

1. PUT / Create new row — contains the value for each non-null column. Generated by INSERT statements.
2. PATCH / Update existing row — contains the id, and value of each changed column. Generated by UPDATE statements.
3. DELETE / Delete existing row — contains the id. Generated by DELETE statements.

​

Recommendations

The PowerSync Client SDKs do not prescribe any specific request / response format. Custom client-side code is used to communicate with your app backend, and can use any format.

We do recommend:

1. Use a batch endpoint to handle high volumes of changes.
2. Use an error response (5xx) only when the changes cannot be applied due to a temporary error (e.g. database not available).
3. For validation errors or write conflicts, acknowledge and discard the change. If an error is returned for this, it will block the PowerSync client’s upload queue.

To propagate validation or write error messages back to the client, use:

1. A 2xx response, with details in the response.
2. Write the errors back in a separate table that is synced back to the client.

For details on approaches, see:

For details on handling write conflicts, see:

​

Example implementations

We have some example backend implementations that you can use as a guide for your implementation:

​

NodeJS

​

Django