graphql-subscriptions VS amplify-js

graphql-yoga is built on other packages that provide functionality required for building a GraphQL server such as web server frameworks like express and apollo-server, GraphQL subscriptions with graphql-subscriptions and subscriptions-transport-ws, GraphQL engine & schema helpers including graphql.js and graphql-tools, and an interactive GraphQL IDE with graphql-playground.

The most common used (but not best maintained) library for such a PubSub engine in the GraphQL context is graphql-subscriptions. There are also adapters available for more distributed systems (where all GraphQL API replicas must be notified about the event) e.g. over Redis.

During that work, we created and merged the reference implementation into graphql-js and created two supporting libraries: graphql-subscriptions and subscriptions-transport-ws. Here is a talk with deep dive into all the details.

The Prisma / GraphQL-Yoga comes with Subscriptions, and this was the first thing I came across when my client asked for realtime updates. The implementation was quite difficult - took me a long time. Eventually, it was working locally, and in staging. However, when it came to the production environment, for some reason it just didn't work! This unfortunately ended up with a user losing an auction, which ultimately went to court etc.

There are also other solutions available: https://github.com/apollographql/graphql-subscriptions#pubsub-implementations

First, let's try to understand what PubSub is exactly. Apollo Server uses a publish-subscribe (pub/sub) model to track events that update subscriptions. The graphql-subscriptions library included in all apollo-server packages (including middleware integrations) provides a PubSub class as a basic in-memory event bus.

To add this, I can just expand the basic setup above. To do so, I do actually use a couple of small Apollo modules! Most can be picked and configured independently. For this case, graphql-subscriptions provides a little bit of pubsub logic that works within resolvers, and subscriptions-transport-ws integrates that into Express to handle the websockets themselves. Super helpful

One note of caution, though: Amplify uses a frontend-only Cognito integration that stores long-lived, never-rotating refresh tokens in browser storage, where any XSS vulnerability would have access to them. A more secure approach is to implement a couple of backend API routes to store the refresh tokens in `HttpOnly` cookies instead, which I outlined here (option 1 in your case to support SSO). I'll probably open source a solution to do this early next year so we don't all have to keep reinventing this wheel (probably why AWS calls their conference re:invent).

I'm ramosbugs on GitHub (that comment is mine). If you subscribe to https://github.com/aws-amplify/amplify-js/issues/1218 I'll post a comment there once I release a solution.

Amplify also lets you host a backend, which it runs in Lambda functions. You don't have a lot of control over it, but it works well for its intended audience: People who wouldn't know what to do if they had a lot of control over their Lambda functions. Amplify also lets you consume other AWS services easily, through declarative and easy-to-use libraries. That way, you can consume Cognito or S3 from the frontend without knowing a lot about Cognito or S3. Here's the complete list of libraries for Amplify, and you can check the Readme of the JavaScript one as an example of its features.

Whenever I call Storage.put() inside my React Native (with Expo) application, I get an error of [TypeError: undefined is not a function]. Doing some internet digging, after hours of searching, I found only one other reference to this kind of error, and that is with the DataStore: https://github.com/aws-amplify/amplify-js/issues/10764

Hello! Can you please create a GitHub issue here for us to investigate this further? https://github.com/aws-amplify/amplify-js/issues

Thanks for bringing this up. This discussion on the project's github is equally insightful on the subject.

Amplify GitHub Issue

Bug: There is currently, at the time of writing, a bug in Amplify that does not allow us to use the voiceId “Kevin”, which we selected when creating the backend resources. Selecting the voiceId “Amy” works, so we will use that.