You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: migration-guides/mongodb-atlas.mdx
+32-32Lines changed: 32 additions & 32 deletions
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,7 @@ Here is a quick overview of the resulting PowerSync architecture:
48
48
***PowerSync Client SDKs** use **SQLite** under the hood. Even though MongoDB is a “NoSQL” document database, PowerSync’s use of SQLite works well with MongoDB, since the [PowerSync protocol](/architecture/powersync-protocol) is schemaless (it syncs schemaless JSON data) and we dynamically apply a [client-side schema](/installation/client-side-setup/define-your-schema) to the data in SQLite using SQLite views. Client-side queries can be written in SQL or you can make use of an ORM (we provide a few [ORM integrations](https://www.powersync.com/blog/using-orms-with-powersync))
49
49
***Reads vs Writes**: PowerSync handles syncing of reads differently from writes.
50
50
***Reads**: The PowerSync Service connects to your MongoDB database and replicates data in real-time to PowerSync clients. Reads are configured using PowerSync’s [“Sync Rules”](/usage/sync-rules/). Sync Rules are more flexible than MongoDB Realm Flexible Sync, but are defined on the server-side, not on the client-side.
51
-
***Writes**: 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 sequentially to the backend.
51
+
***Writes**: 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 sequentially to the backend.
52
52
***Authorization**: Authorization is controlled separately for reads vs. writes.
53
53
***Reads**: The [Sync Rules](/usage/sync-rules/) control which users can access which data.
54
54
***Writes**: The backend controls authorization for how users can modify data.
@@ -59,41 +59,41 @@ Here is a quick overview of the resulting PowerSync architecture:
59
59
60
60
## Migration Steps
61
61
62
-
Follow the steps below to migrate a MongoDB Atlas Device Sync app to PowerSync.
62
+
Follow the steps below to migrate a MongoDB Atlas Device Sync app to PowerSync.
63
63
64
64
### 1. Remove Realm
65
65
66
66
Before adding PowerSync, remove MongoDB Realm from your project. This includes uninstalling the Realm SDK and deleting all Realm-related code and dependencies. It is also possible to initially run Realm and PowerSync in parallel, and remove Realm later.
67
67
68
68
### 2. Create PowerSync account and instance
69
69
70
-
To get started quickly with PowerSync, sign up for a free PowerSync Cloud account [here](https://accounts.journeyapps.com/portal/powersync-signup?s=mongodb-migration-guide).
70
+
To get started quickly with PowerSync, sign up for a free PowerSync Cloud account [here](https://accounts.journeyapps.com/portal/powersync-signup?s=mongodb-migration-guide).
71
71
72
72
It is also possible to self-host PowerSync. An end-to-end demo app using Docker Compose is available [here](https://github.com/powersync-ja/self-host-demo/tree/main/demos/nodejs-mongodb).
73
73
74
74
### 3. Connect PowerSync to MongoDB
75
75
76
-
Once your account is set up, [create a new PowerSync instance](/installation/database-connection#create-a-powersync-cloud-instance) and configure the instance to connect to your source [MongoDB database](/installation/database-connection#mongodb-beta-specifics).
76
+
Once your account is set up, [create a new PowerSync instance](/installation/database-connection#create-a-powersync-cloud-instance) and configure the instance to connect to your source [MongoDB database](/installation/database-connection#mongodb-beta-specifics).
77
77
78
78
### 4. Define Sync Rules
79
79
80
80
Sync Rules allow you to control which data gets synced to which users/devices. Each PowerSync Service instance has a Sync Rules definition that consists of SQL-like queries in a YAML file.
81
81
82
82
To get a good understanding of how Sync Rules operate, have a look at our blog post: [Sync Rules from First Principles: Partial Replication to SQLite](https://www.powersync.com/blog/sync-rules-from-first-principles-partial-replication-to-sqlite).
83
83
84
-
If you have a PowerSync Service instance set up and connected, open the `sync-rules.yaml` file associated with your PowerSync project and edit the SQL-like queries based on your database schema. Below is a simple Sync Rules example using a simple database schema. Sync Rules involve organizing data into ["buckets"](/usage/sync-rules/organize-data-into-buckets) (a bucket is a grouping of data). The example below uses a ["global bucket"](/usage/sync-rules/example-global-data) as a simple starting point — data in a "global bucket" will be synced to all users.
84
+
If you have a PowerSync Service instance set up and connected, open the `sync-rules.yaml` file associated with your PowerSync project and edit the SQL-like queries based on your database schema. Below is a simple Sync Rules example using a simple database schema. Sync Rules involve organizing data into ["buckets"](/usage/sync-rules/organize-data-into-buckets) (a bucket is a grouping of data). The example below uses a ["global bucket"](/usage/sync-rules/example-global-data) as a simple starting point — data in a "global bucket" will be synced to all users.
85
85
86
86
<Info>Note that MongoDB uses “_id” as the name of the ID field in collections whereas PowerSync uses “id” in its client-side database. This is why `SELECT _id as id` should always be used in the data queries when pairing PowerSync with MongoDB.</Info>
87
87
88
88
```yaml
89
89
bucket_definitions:
90
90
# This is the name of the bucket, in this case the global bucket synced to all users.
91
-
global:
91
+
global:
92
92
# This is the query used to determine the data in each bucket
93
-
data:
93
+
data:
94
94
# Note that we select the MongoDB _id field as id
95
-
- SELECT _id as id, * FROM lists
96
-
- SELECT _id as id, * FROM todos
95
+
- SELECT _id as id, * FROM lists
96
+
- SELECT _id as id, * FROM todos
97
97
```
98
98
99
99
To filter data based on the user and other more advanced use cases, refer to the [Sync Rules documentation](/usage/sync-rules).
@@ -109,13 +109,13 @@ Add PowerSync to your app project by following the instructions for the relevant
109
109
110
110
The PowerSync client-side schema represents a “view” of the data synced from the PowerSync Service to the client app. No migrations are required — the schema is applied directly when the local PowerSync SQLite database is constructed.
111
111
112
-
To make this step easy for you, the [PowerSync Dashboard](/usage/tools/powersync-dashboard) allows automatically generating the client-side schema based on the Sync Rules defined for a PowerSync instance. To generate the schema, go to the [dashboard](https://powersync.journeyapps.com/), right-click on the instance, and select “Generate Client Schema”. Alternatively you can use the PowerSync [CLI](/usage/tools/cli) to generate the schema.
112
+
To make this step easy for you, the [PowerSync Dashboard](/usage/tools/powersync-dashboard) allows automatically generating the client-side schema based on the Sync Rules defined for a PowerSync instance. To generate the schema, go to the [dashboard](https://powersync.journeyapps.com/), right-click on the instance, and select “Generate Client Schema”. Alternatively you can use the PowerSync [CLI](/usage/tools/cli) to generate the schema.
113
113
114
114
Here is an example of a client-side schema for PowerSync using a simple `todos` table:
115
115
116
116
<CodeGroup>
117
117
118
-
```typescript TypeScript - React Native
118
+
```typescript TypeScript - React Native
119
119
import { column, Schema, Table } from '@powersync/react-native';
120
120
121
121
const todos = new Table(
@@ -127,14 +127,14 @@ Here is an example of a client-side schema for PowerSync using a simple `todos`
127
127
created_by: column.text,
128
128
completed_by: column.text,
129
129
completed: column.integer
130
-
},
130
+
},
131
131
{ indexes: { list: ['list_id'] } }
132
132
);
133
133
134
134
export const AppSchema = new Schema({
135
135
todos
136
136
});
137
-
```
137
+
```
138
138
139
139
```typescript TypeScript - Web
140
140
import { column, Schema, Table } from '@powersync/web';
@@ -212,7 +212,7 @@ Here is an example of a client-side schema for PowerSync using a simple `todos`
212
212
let AppSchema = Schema(todos)
213
213
```
214
214
215
-
```dart Flutter
215
+
```dart Flutter
216
216
import 'package:powersync/powersync.dart';
217
217
218
218
const schema = Schema(([
@@ -235,7 +235,7 @@ Here is an example of a client-side schema for PowerSync using a simple `todos`
235
235
236
236
A few things to note regarding the PowerSync client-side schema:
237
237
238
-
* The schema does not explicitly specify an `id` column, since the PowerSync automatically creates an `id` column of type `text`.
238
+
* The schema does not explicitly specify an `id` column, since the PowerSync automatically creates an `id` column of type `text`.
239
239
* SQLite has very simple data types which are [used by](/usage/sync-rules/types#types) PowerSync.
240
240
* For MongoDB specific data types, refer to [MongoDB Type Mapping](/usage/sync-rules/types#mongodb-beta-type-mapping).
241
241
* PowerSync also supports [syncing attachments or files](/usage/use-case-examples/attachments-files#attachments-files) using helper packages.
@@ -247,7 +247,7 @@ Now that we have our Sync Rules and client-side schema defined, we can instantia
247
247
248
248
<CodeGroup>
249
249
250
-
```typescript TypeScript - React Native
250
+
```typescript TypeScript - React Native
251
251
import { PowerSyncDatabase } from '@powersync/react-native';
252
252
import { Connector } from './Connector';
253
253
import { AppSchema } from './Schema';
@@ -263,7 +263,7 @@ Now that we have our Sync Rules and client-side schema defined, we can instantia
263
263
const connector = new Connector();
264
264
db.connect(connector);
265
265
};
266
-
```
266
+
```
267
267
268
268
```typescript TypeScript - Web
269
269
import { PowerSyncDatabase } from '@powersync/web';
@@ -322,7 +322,7 @@ Now that we have our Sync Rules and client-side schema defined, we can instantia
await db.execute('INSERT INTO todos (id, created_at, list_id, description) VALUES (uuid(), date(), ?, ?)', [listId, description]);
400
400
}
401
-
```
401
+
```
402
402
403
403
```java Kotlin
404
404
// Writing Data
@@ -422,7 +422,7 @@ The same applies to writing data: `INSERT`, `UPDATE` and `DELETE` statements are
422
422
}
423
423
```
424
424
425
-
```dart Flutter
425
+
```dart Flutter
426
426
/// Writing Data
427
427
await db.execute(
428
428
'INSERT INTO todos (id, created_at, list_id, description) VALUES (uuid(), date(), ?, ?)',
@@ -452,7 +452,7 @@ There are two options:
452
452
453
453
#### Using PowerSync’s serverless cloud functions
454
454
455
-
PowerSync provides serverless cloud functions for backend functionality, with a template available for MongoDB. See the [step-by-step instructions](/usage/tools/cloudcode) on how to use the template. The template can be customized, or it can be used as-is.
455
+
PowerSync provides serverless cloud functions for backend functionality, with a template available for MongoDB. See the [step-by-step instructions](/usage/tools/cloudcode) on how to use the template. The template can be customized, or it can be used as-is.
456
456
457
457
The template provides [turnkey conflict resolution](https://www.powersync.com/blog/turnkey-backend-functionality-conflict-resolution-for-powersync#turnkey-conflict-resolution) which roughly matches the built-in conflict resolution behavior provided by MongoDB Atlas Device Sync.
458
458
@@ -465,7 +465,7 @@ For more information, see our blog post: [Turnkey Backend Functionality & Confli
465
465
466
466
This option gives you complete control over the backend. The simplest backend implementation is to simply apply writes to MongoDB as they are received, which results in a last-write-wins conflict resolution strategy (same as the “turnkey backend functionality” option above). See [Writing Client Changes](/installation/app-backend-setup/writing-client-changes) for more details.
467
467
468
-
On the client-side, you need to wire up the `uploadData()` function in the “backend connector” to use your own backend API. The [App Backend Setup](/installation/app-backend-setup) section of our docs provides step-by-step instructions for this.
468
+
On the client-side, you need to wire up the `uploadData()` function in the “backend connector” to use your own backend API. The [App Backend Setup](/installation/app-backend-setup) section of our docs provides step-by-step instructions for this.
469
469
470
470
Also see the section on [how to set up a simple backend API](https://www.powersync.com/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync#backend-api-setup) in our practical MongoDB migration [example](https://www.powersync.com/blog/migrating-a-mongodb-atlas-device-sync-app-to-powersync) on our blog.
471
471
@@ -474,4 +474,4 @@ We also have [example backend implementations](/resources/demo-apps-example-proj
474
474
475
475
## Questions? Need help?
476
476
477
-
[Get in touch](https://www.powersync.com/contact) with us.
477
+
[Get in touch](https://www.powersync.com/contact) with us.
0 commit comments