One of the biggest challenges in web and mobile development is syncing data across devices and performing offline operations. Ideally, when the device is offline, your customers should be able to continue to use your application not only to access data, but also to create and modify it. When the device comes back online, the app must reconnect to the backend, sync data, and resolve conflicts, if any. A lot of undifferentiated code is required to properly handle all edge cases, even when using the AWS AppSync SDK cache on a device with offline mutations and delta sync.
Amplify DataStore provides persistent on-device storage for writing, reading and observing data changes when connected to the Internet or offline, and allows you to easily sync data to the cloud and across devices.
Amplify DataStore allows developers to write applications using distributed data without writing additional code for offline or online scripting.
You can use Amplify DataStore for standalone use in local-only mode without an AWS account, or expose the entire backend using AWS AppSync and Amazon DynamoDB.
The DataStore includes Delta Sync using your GraphQL backend and several conflict resolution strategies.
Comparing AWS Amplify with Redux, MobX is not correct, since AWS Amplify is not only a state manager, but also a client-server, so in the client-server class we will compare it with Apollo and Relay.
I don't think that a business can be considered serious if its mobile application does not have subscription events implemented on web sockets technology. How many applications run on web sockets these days? I think not, due to the fact that real time is additional work of developers on the back-end and front-end. For us, [fullStack serverless] (https://react-native-village.github.io/docs/amplify-01) developers on AWS Amplify, real time comes out of the box, both on the front and back, and we don't it is necessary to write implementation code for integrating websockets for each model, since it is generated automatically, as well as writing documentation for all our generated code, implemented into our project based on the GraphQL schema instruction. In order not to scare you with loud words, I will show you an example, from [the last lesson] (https://react-native-village.github.io/docs/amplify-03), how the Store is defined in AWS Amplify:
This defines the model in the store, not only for the frontend, but also for the backend. One source of truth for front-end and back-end. Yes, yes, I see that I will repeat this more than once in my life, since this is a killer feature and punch line vs Redux, MobX, Apollo, Relay.
It is precisely this architecture different from Redux, MobX, Apollo that blurs the line between the backend and the frontend. And puts AWS Amplify DataStore above all
Everything!!! If you are from the backend, then you no longer need to write resolvers to the database and drag subscriptions to each data model.
Serverless is when the time has come for backend developers to teach the frontend, since their services are needed exclusively for legacy projects that do not keep pace with the times, from which they do not live in real time.
What is code generation you can read without me on Wikipedia, unless of course you know its meaning, which in this punch reminds us of itself. Old school boy? Using fetch or axios? By sending requests to the dense forest of API, which we also write in conjunction with Redux, MobX, Apollo, Relay. So here's another news of the day for you! You no longer need to write these API requests, you only need to call them. This means that you no longer need to create this rather large folder with the server request code, since in AWS Amplify DataStore they are also generated in your project based on your store, which is defined by the same GraphQL schema of their first item. And this is done with one command:
As a result, we get the models folder with the generated code.
There is no need to write additional code to send a request to the server after the application is online. Sometimes you find yourself in a precarious situation, but you'd better wait longer than clearly fail the operation. Apollo has apollo-link-retry which provides exponential rollback and requests to the server between retries by default. True, it (currently) does not handle repetitions for GraphQL errors in the response, only for network errors. Redux, MobX, of course, does not have this solution under the hood, since they are not clients and they have to touch the middleware, because REST is like a grandfather in retirement with the support of any grandchildren. A detailed breakdown of [GraphQL vs REST] (https://react-native-village.github.io/docs/amplify-02). AWS Amplify DataStore has not only an analogue of apollo-link-retry, but also a built-in and customizable familiar programming model with automatic version control, conflict detection and resolution in the cloud.
Of the cons of AWS Amplify, I want to name the fact that the Apollo hooks with its loading and error out of the box reduce the amount of written code on the front, so I wrote open source [library] (https://github.com/react-native-village/aws-amplify -react-hooks), which resolves this misunderstanding.
With AWS Amplify DataStore, you pay only for what you use, no minimum fees or mandatory use of services. You are billed separately for requesting and modifying data, and for updating your data in real time. This provides transparency and low cost no matter what type of workload, because you only pay for the specific AWS AppSync features you use.
Query operations allow your application to receive data and cache it locally. Data change operations allow your application to create, update, and delete data.
$ 4.00 per million requests and data modification operations *
At the end of this tutorial, we will put together this mobile application with you using Amplify DataStore:
This lesson is a continuation of the lesson on [authentication] (https://react-native-village.github.io/docs/auth1-00), since work with the DataStore will be performed by an authenticated user. Therefore, if you have not passed it, then go back one step.
AWS Amplify Support Chat: Telegram
The final code for this part can be found at Github.
If you are continuing the last lesson, you can skip directly to step 5
Go to the project folder
Step for those who are not yet registered on AWS Register according to [this] (https://aws-amplify.github.io/docs/) instructions 📃 and check all 5 steps from the video tutorial 📺.
You will need a bank card 💳, where there must be more than 1 \ $ 💵
We look there and set Amplify Command Line Interface (CLI)
In the root directory of the React Native project, we initialize our AWS Amplify project
We answer the questions:
The project was initialized 🚀
Now that the application is in the cloud, you can add some functionality, such as allowing users to register with our application and sign in.
we connect the authentication function. We select the default configuration. This adds auth resource configurations locally to your directory ampify/backend/auth
Submitting changes to the cloud 💭
✔ All resources are updated in the cloud
Putting together the project and checking the authentication functionality.
Detailed installation here
If you have React Native Cli, then
And if you are using React Native> 0.50 then run the following command for iOS:
If you connected it in the last lesson, then skip this step. If not, then connect the API plugin
After the selected items, a GraphQL schema will open in
amplify / backend / api / <datasourcename> / schema.graphql where we insert this model:
More about her here
Вам не нужна учетная запись AWS для ее запуска и локального использования DataStore, однако, если вы хотите синхронизироваться с облаком, рекомендуется установить и настроить Amplify CLI как в прошлом уроке.
Since we described the scheme in the last lesson, now we just need to run the command
and get the generated model in the src/models folder
Enabling DataStore for the entire API
Submitting changes to the cloud 💭
✔ All resources are updated in the cloud
Create a screen JobsMain src/screens/Jobs/JobsMain.js
On this screen, we will make a Query query, with the pagination option, where the number is through the useQuery hook and it will return an array to us, which we will send to Flatlist.
To reveal the details of the vacancy, create a screen JobDetail src/screens/Jobs/JobDetail.js
Create a screen JobAdd src/screens/Jobs/JobAdd.js , where we perform functions CREATE UPDATE DELETE
and in screens/Jobs/index.js exporting screens
Add import of Jobs screens and connect them to StackNavigator
Editing the User screen in screens/Authenticator/User/index.js
Putting the application together and testing