[Tech Hướng Dẫn] Tạo API GraphQL không máy chủ với AWS AppSync, Lambda & DynamoDB.
AppSync như bồi bàn nhận request GraphQL
Lambda là "nhà bếp" xử lý logic
DynamoDB là kho lưu trữ dữ liệu
Chức năng chính:
• Tạo todo mới
• Lấy todo bằng ID
• Liệt kê toàn bộ todo
Lợi ích:
🗸 Hoàn toàn serverless - AWS tự động scale
🗸 Chỉ trả phí khi sử dụng
🗸 Kiến trúc rõ ràng, dễ bảo trì
Ứng dụng cho:
📱 Backend mobile/web
⚡ Ứng dụng real-time
🌐 Kiến trúc microservice
AppSync subscriptions: waiting for start_ack can still result in missing events
It seems like that when AppSync returns a `start_ack` message in response to a subscription `start` it won't necessarily mean that all future events will be delivered.
Subscriptions are the mechanism to deliver real-time events from AppSync. It is based on WebSockets and its protocol is documented [here](https://docs.aws.amazon.com/appsync/latest/devguide/real-time-websocket-client.html).
In the protocol, a client needs to send a `start` message with the GraphQL query to start receiving updates. Then AppSync responds with a `start_ack` if everything is OK and then sends `data` events whenever an update happens.
Reading the documentation my impression was that `start_ack` is the moment when the subscription is live and all future events will be delivered. But what I'm seeing is that **it's not the case**. Even when the event is strictly triggered after the `start_ack` is received sometimes it is not delivered to the client.
Why is it a problem?
A common pattern for APIs with real-time updates is to subscribe to updates first then query the current state. This way there is no "temporal dead zone" when updates are lost. But that requires a definitive *point in time* when the subscription is live. Without that, it's only best-effort and messages will be lost every now and then especially in cases when the subscription is made just before the event, common in tests and some async workflows.
Real-time updates, especially in AppSync, is a complex topic and it's easy to get wrong. I've [written about it before](https://advancedweb.hu/shorts/apollos-subscribetomore-is-the-wrong-abstraction/), it has a [separate section in my book](https://www.graphql-on-aws-appsync-book.com/client-side/implementing-subscriptions/), and I even [made a library](https://github.com/sashee/appsync-subscription-observable) because I wasn't particularly happy with the AWS-provided one.
I noticed tests using subscriptions timeouting for a long time now, but i wrote it off as "something complex is happening" and added some retries to handle it. A message is published to IoT Core that triggers a Lambda, that writes to DynamoDB then it triggers the subscription. A lot can go wrong so it's realistic that the 10-ish seconds sometimes pass.
But I then started working on a simpler setup and still noticed that some events seemingly never arrive. This time I could pinpoint the issue because if a parallel subscription is opened before then the event is delivered there. So the problem must be that the subscription is not live even though AppSync says it is.
Hopefully, it will get fixed soon.
Bug report opened [in the AppSync repo](https://github.com/aws/aws-appsync-community/issues/405).
Originally published [on my blog](https://advancedweb.hu/shorts/appsync-subscriptions-waiting-for-start_ack-can-still-result-in-missing-events/)
AppSync Event API を使用したリアルタイム文字起こしをブラウザに表示させてみた！
https://qiita.com/hirota_kodai/items/9b2c846d8c7b4bc7bc95?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
Windows 11 riceverà una funzione Handoff simile a macOS
#Aggiornamento #AppSync #Continuità #CrossDeviceResume #Microsoft #Multidispositivo #Notizie #Novità #NuoveFunzioni #Produttività #SistemaOperativo #Software #Sviluppo #TechNews #Tecnologia #Windows11
https://www.ceotech.it/windows-11-ricevera-una-funzione-handoff-simile-a-macos/
GraphQL tip: Have the subscription types contain all filterable fields on the top-level.
For example, a Todo event that should allow filtering by user, group, severity, and id, should have these as well as the item itself:
```graphql
type TodoEvent {
userId: ID!
groupId: ID!
todoId: ID!
severity: Severity!
todo: Todo
}
```
Originally, it was the only way for filtering in AppSync, but that changed when it [started supporting filters on nested fields](https://docs.aws.amazon.com/appsync/latest/devguide/aws-appsync-real-time-enhanced-filtering.html#aws-appsync-real-time-enhanced-filters-nested-schema-fields.title). So, why it's still a best practice?
The primary reason is deletion: this structure makes it easy to support sending an event when the item is deleted and all the filters will work.
Then an additional benefit is when there is a filter that is not present in the entity itself. For example, if a Todo item's `userId` can be changed it is useful to notify the original owner. In that case, a `prevUserId` field can be added to the subscription allowing users to subscribe to events when an item is removed from them.
Originally published [on my blog](https://advancedweb.hu/shorts/graphql-tip-have-the-subscription-types-contain-all-filterable-fields-on-the-top-level/)
GraphQL tip: Only make fields required if they are present for all users
In GraphQL it's possible to mark a field as required with the `!`. For example, a `User` always have a `Project` according to this schema:
```graphql
type User {
name: String!
email: String!
project: Project!
}
```
Marking fields required is a powerful tool in the GraphQL toolbox as clients won't need handle the case when the field is null. But it can also lead to a cascading null effect.
For example, let's say the Project has a `client` field that also can't be null:
```graphql
type User {
name: String!
email: String!
project: Project!
tickets: [Ticket!]!
}
type Project {
name: String!
description: String!
client: String!
}
// + Ticket
```
Let's say the `Project.client` is considered sensitive information and will be removed for non-admin users.
Then a query that gets the `User`, its `Project`, and and then the `client` field will fail to return any data:
```graphql
query {
user(id: "user1") {
name
email
project {
name
description
client
}
tickets: {
id
}
}
}
```
The result:
```json
{
"data": null,
"errors": ...
}
```
Because of this, be mindful which fields you mark as required. If a field can be null for some users during normal operations, such as when you have different access levels, it should be optional. A field should be marked as mandatory only when it returns a value in every case.
Originally published [on my blog](https://advancedweb.hu/shorts/graphql-tip-only-make-fields-required-if-they-are-present-for-all-users/)
AppSync footgun: util.error does not work if called with non-string arguments
The `util.error` function terminates the current resolver with the error provided in the argument, similar to how an exception would work. Its signature is:
```
util.error(String, String?, Object?, Object?)
```
But what happens when the provided arguments don't match this signature?
Consider this code:
```js
if (ctx.result.statusCode < 200 || ctx.result.statusCode >= 300) {
util.error(ctx.result.statusCode);
}
return JSON.parse(ctx.result.body);
```
The expectation here is that if the `statusCode` is outside the 2xx range then it will result in an error.
But what happens instead is that the `util.error` is silently ignored. There is no error, no warning, it behaves as it was never called.
All these lines are no-ops:
```js
util.error(25);
util.error(true);
util.error("abc", 25);
```
Issue opened at [https://github.com/aws/aws-appsync-community/issues/384](https://github.com/aws/aws-appsync-community/issues/384).
Originally published [on my blog](https://advancedweb.hu/shorts/appsync-footgun-util-error-does-not-work-if-called-with-non-string-arguments/)
In case anyone is interested, after discussing the AWS product roadmap with them, it is clear that DataStore is on the way out. Recommend that no one use it for any new development and anyone currently using it begin making plans to rearchitect. #Amplify #AppSync
There does not seem to be any first party offline-first for mobile data sync service in AWS anymore. Looking into third party services next.
New AWS::AppSync::ChannelNamespace
Use the AWS::AppSync::ChannelNamespace resource to creates a channel namespace associated with an Api.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsyc-channelnamespace.html #appsync #cloudformation
New AWS::AppSync::Api
Use the AWS::AppSync::Api resource to create an AWS AppSync API that you can use for an AWS AppSync API with your preferred configuration,.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsync-api.html #appsync #cloudformation
The main problem I'm working through is my primary key can change, so I'm trying to make sure I can still update it in the future by having a static guid as an attribute in the tables.
I'm amazed there's no nice way for #AppSync to query a table with multiple IDs. The get batch item support isn't great as it requires the table name to be hard coded in the resolved, which you can't do if you want dev and prod envs.
Updated AWS::AppSync::GraphQLApi
Updated LogConfig property.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsync-graphqlapi.html #appsync #cloudformation
If anyone out there has created a GraphQL API using AWS AppSync with multiple services and implemented the root "node" field as defined in the spec, I could really use some help.
I cannot figure out how to direct AppSync to the right lambda resolver for the actual type. I tried a pipeline resolver, but that only works when the type is resolved by the last function in the pipeline - if it's an earlier service, the returned value gets lost.
Please boost for reach! 🙇♀️
#AWS just revealed that Amazon EventBridge Event Bus supports AWS AppSync as an Event Bus's target.
Developers can now stream real-time updates like sports scores from their apps to frontend applications, whether on mobile or desktop: https://bit.ly/3HtzZo0
#InfoQ #EventBridge #AppSync #CloudComputing #EventDrivenArchitecture
Leveraging AppSync and Step Functions to improve your user’s form experiences via CloudFormation. https://medium.com/ready-set-code/leveraging-appsync-and-step-functions-to-improve-your-users-form-experiences-via-cloudformation-8ad5db7cd7ba #appsync #aws #stepfunctions #ux #webdev #webdevelopment #programming #dev #developer #Coding #softwaredev
Issue #244 of Off-by-none is out! This week, #AppSync kills VTL, @HashiCorp makes a bunch of friends, and #serverless opinions get summarized. Plus, we recognize Hiroko Nishimura as our ⭐️ of the week! #offbynone https://offbynone.io/issues/244/
