AWS: Insights into Appsync subscriptions- Part 2
The major reason for trying out Appsync was to understand the benefits of Appsync realtime updates. In the previous article, we explore the Appsync AWS configurations in detail.
Background
We have already learned how to set up a subscription function which subscribes to updateVehicleLocation call. This subscription function accepts a particular ID and subscribes to the mutation happening(via updateVehicleLocation) to that ID.
State Subscription ( Query + Subscribe)
To subscribe to a state change, you need to make two calls in your web/mobile app.
- Query: To fetch the current/persisted state
- Subscribe: To get updates about the latest state changes.
Appsync + Amplify
They work well together. Amplify provides a functionality called offline sync. So data from Appsync can be cached locally for offline usage. When you are back online, only the delta changes are fetched from the Appsync.
Subscription Protocol (then vs now)
Previously Appsync used to expose Subscribe via MQTT (with an MQTT payload limit of 124kb). Now, they use pure WS (248kb payload limit). They still support MQTT in the AWS side to ensure backwards compatibility. With the latest Amplify SDKs, the default protocol is WS based.
WS + HTTP Endpoints
To see the different endpoint used by Amplify internally, you can run the below CLI command to fetch the configuration of Appsync
In case, you are wondering, where can we get the API-Key of appsync, please refer below.
When amplify is used in a web app, you see that the WS endpoint being used for the realtime connection.
Conclusion
This was a short article about the subscription feature of Appsync. The Subscription feature is also available in Apollo GraphQL via WS. In the next tutorial, we will be developing an Angular 7 Appsync app using Amplify.
Found it Interesting?
Please show your support by 👏.
