realtime-app | serverless realtime app built on AWS Lambda | Serverless library

Answer from the author of the git repo.

The example I created here was pretty bare bones but below are a few bullet points that I hope will explain how you could expand on it.

• Add a User model and Thread model to the Rails app
• When a User is created, generate a public UID for the user (you can use Ruby's built-in SecureRandom.uuid to generate the id) and save that to the DB. This would become the ID for that user that you would expose in your javascript to allow for communications between users. All users would have a UID.
• When a Thread is Created, generated a thread UID this would become the unique id for the conversation taking place
• Add a Users_Threads has_and_belongs_to_many relationship so that you can eventually track the users that are subscribed to which threads
• When React app loads, use an Ajax request to get a list of the current User's friends (returns list of user details + their uid) and a request to get all threads for current User
• So let's say for example a User named Fred clicked on a User named Bob and wanted to send Bob a message but they do not currently have a thread. Fred types the message, clicks Submit and you send an Ajax request containing the message text, from_uid (Fred) and to_uid (Bob) with thread_uid as null (since there is no existing convo and no existing thread).
• Your Rails app then receives that requests at a controller and sees that Fred is trying to send Bob a message and the thread ID is null, so the controller create a new thread (with its own UID) and then add two entries to users_threads one for the new thread_uid and bob's uid and another for the new thread_uid and Fred's uid. After that, you'd create a Message with that thread_uid and the participant details.

You'd also probably want users to see that they are part of a new thread without having to reload the page so you'd I think you'd want a Pusher channel subscription just for notifying users of a new thread. So I'd say in the UserThreads model after create a new thread you could send something like Pusher.trigger('threads_channel', user_secret_uid, { thread: new_thread_uid }). You'd also need to make sure in the react app that each user subscribes to the threads_channel for their user_secret_uid. For security, i'd make sure this is a different uid than the messaging otherwise people could subscribe to a list of a different users threads.

GraphQL itself purposefully does not specify a transport layer in the specification. Therfore the answer depends on the implementation that you are using but for the implementations it makes sense to have only one connection. In Apollo you can use apollo-link-ws to connect to the server. This link then creates (an keeps alive) a single socket to the server using subscriptions-transport-ws. It can also handle all GraphQL methods (not only subscriptions) using the web socket.