docs: WebSocket subscriptions for AppSync

[quetzalliwrites]

Added documentation for WebSocket subscriptions in AWS AppSync using LocalStack, including setup instructions and message types.

Preview URL:
https://9150cac2.localstack-docs.pages.dev/aws/services/appsync/#websocket-subscriptions

[cloudflare-workers-and-pages]

Deploying localstack-docs with    Cloudflare Pages

Latest commit:	3dcbddb
Status:	✅  Deploy successful!
Preview URL:	https://4588a77d.localstack-docs.pages.dev
Branch Preview URL:	https://docs-websocket-subscriptions.localstack-docs.pages.dev

View logs

[cloutierMat]

🚀 Lots of great work there! Thank you.

As we discussed, I am still unsure of the overall structure.

Possible change:

• GraphQL API
  • Getting Started
  • GraphQL resolvers
  • Subscriptions (this could have the intro paragraph and the supported message types
  • Subscription Example (not too sure of the name
  • Configuring GraphQL endpoints
  • GraphQL Resource Browser

It is not ideal either 🫤 WDYT?

[quetzalliwrites]

Possible change:
GraphQL API
Getting Started
GraphQL resolvers
Subscriptions (this could have the intro paragraph and the supported message types
Subscription Example (not too sure of the name
Configuring GraphQL endpoints
GraphQL Resource Browser

Ok, so having supported message types in the intro deviates from the current order & outline we observe in this doc which has individual endpoint headings. I don't think that part makes sense crammed into the intro.

That said, I've made some adjustments in line with some of your suggestion above!

Do you think the WebSocket Subscriptions should be h2, same level as GraphQL and Events API? Or do you think it should be h3?

Preview URL: https://4d703999.localstack-docs.pages.dev/aws/services/appsync/

cc @cloutierMat

[cloutierMat]

Thanks @quetzalliwrites for addressing the previous comments! I think we are getting close, but I do have more suggestions that could improve the flow of the docs 😄

I personally think it should be H3, as it is a subset of GraphQl Apis. I don't think we should put that much emphasis on GraphQl WebSockets.

I also think that we shouldn't have both Configuring WebSocket Subscription endpoints and Configuring GraphQL endpoints as the WebSocket endpoint is just part of GraphQl APIs.

• GraphQL API
  • Getting Started
  • GraphQL resolvers
  • WebSocket Subscriptions
  • Supported WebSocket Message Type
  • Configuring GraphQL endpoints (including WS endpoint)
  • GraphQL Resource Browser

I think this hierarchy gives the user quick links to get where they need to. Having 2 h3 for WebSockets inside of GraphQl API seems plenty to me. And both endpoint style should fall in the same category, since they both answer the same question from a user.

Let me know if you have a good argument for keeping WebSocket Subscriptions as H2. But If we do, we should bring Configuring GraphQL endpoints and GraphQL Resource Browser in GraphQL API, which might make the flow a bit more bouncy?

[cloutierMat]

🚀 Awesome! Thanks for the good back and forth! This looks great!