#appsync — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #appsync, aggregated by home.social.
-
【AWS AppSync】Amplify Gen 2 の裏側で動く「スマートな中継機能」を理解する
https://qiita.com/jus1730/items/a55d79f16dbfe7a805e3?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items -
【AWS AppSync】Amplify Gen 2 の裏側で動く「スマートな中継機能」を理解する
https://qiita.com/jus1730/items/a55d79f16dbfe7a805e3?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items -
AgentCore 上の Claude Code の出力を AppSync Event API でリアルタイムにブラウザへ流す
https://qiita.com/Kota__Sasaki/items/a5008e550de8fa01dc61?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items -
AgentCore 上の Claude Code の出力を AppSync Event API でリアルタイムにブラウザへ流す
https://qiita.com/Kota__Sasaki/items/a5008e550de8fa01dc61?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items -
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 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 -
AppSync Event API を使用したリアルタイム文字起こしをブラウザに表示させてみた！
https://qiita.com/hirota_kodai/items/9b2c846d8c7b4bc7bc95?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items -
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: 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/)
-
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/)
-
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/)
-
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::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::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::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::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 -
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 -
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 -
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 -
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.
-
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.
-
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.
-
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.
-
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 -
Updated AWS::AppSync::GraphQLApi
Updated LogConfig property.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsync-graphqlapi.html #appsync #cloudformation -
Updated AWS::AppSync::GraphQLApi
Updated LogConfig property.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsync-graphqlapi.html #appsync #cloudformation -
Updated AWS::AppSync::GraphQLApi
Updated LogConfig property.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsync-graphqlapi.html #appsync #cloudformation -
Updated AWS::AppSync::GraphQLApi
Updated LogConfig property.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-appsync-graphqlapi.html #appsync #cloudformation -
AppSync supports long running events with asynchronous Lambda function invocations
https://aws.amazon.com/about-aws/whats-new/2024/05/aws-appsync-events-asynchronous-lambda-function-invocations/
Previously, customers could only invoke Lambda functions synchronously from AppSync, which meant that the GraphQL API would wait for the Lambda function to complete before returning a response. With support for Event mode, AppSync can now trigger Lambda functions asynchronously, decoupling the API response from the Lambda execution.
#AWS #AppSync -
#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
-
#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
-
#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
-
#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
