https://github.com/vic/verily
Demo application for APW subscriptions via websockets
https://github.com/vic/verily
absinthe-graphql apollo-phoenix-websocket
Last synced: 8 months ago
JSON representation
Demo application for APW subscriptions via websockets
- Host: GitHub
- URL: https://github.com/vic/verily
- Owner: vic
- Created: 2017-07-22T00:59:26.000Z (almost 9 years ago)
- Default Branch: master
- Last Pushed: 2017-10-18T08:21:26.000Z (over 8 years ago)
- Last Synced: 2025-04-07T09:51:34.532Z (about 1 year ago)
- Topics: absinthe-graphql, apollo-phoenix-websocket
- Language: Elixir
- Homepage: https://github.com/vic/apollo-phoenix-websocket
- Size: 69.3 KB
- Stars: 10
- Watchers: 1
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Verily
This is a demo application to serve as an example of how to use [Apollo Phoenix Websocket](https://github.com/vic/apollo-phoenix-websocket) with Absinthe subscriptions.
Verily implements a mail authentication app, akin to Facebook AccountKit. That is, the user enters
their email and clicks on `Login`, then the application awaits (via gql subscription) for the user
to verify via a link on their inbox. The app receives the subscription data and logins the user automatically.
### Installation
```shell
$ git clone https://github.com/vic/verily.git
$ cd verily
$ mix deps.get
$ yarn install
$ mix phoenix.server
$ open http://localhost:4000/
```
### Code
The backend code is just a simple plug application that exposes a tiny GQL API with Absinthe.
Of these the most interesting one is the `viewer` subscription. It takes a `device_token` as topic
(in my example, every client, eg mobile device or browser must generate a unique device token for
its viewer subscription to work)
Verification is made via an `email_login` mutation that basically generates a random verification
token (that will be sent via email) and starts a tiny process using an Elixir Registry. These
veirfier processes live just five minutes, so that if no one confirms the email, the process
automatically dies and the token becomes invalid. When the user cliks on the link with the token,
the backend terminates the verifier process and sends the original email to the client via the
GraphQL websocket subscription.
The client code is at `web/static/js` and most of it has nothing to do with
Apollo Phoenix Websocket, haha, the apollo client configuration
is made at `apollo.js` which also prefers to convert promises and observers into xstreams
(as I just wanted to use them for this example) the api is defined at `api.js`, the `app.js` is
where views and logic is bound together.