3 ms·

I read somewhere that they're trying to add realtime support to GraphQL, but the problem which GraphQL solves is only an issue if you use HTTP as a transport.

I read somewhere that they're trying to add realtime support to GraphQL, but the problem which GraphQL solves is only an issue if you use HTTP as a transport. If you use a pub/sub realtime layer on the frontend, you don't need all the complexity which GraphQL introduces - You can make each component bind itself to a pub/sub channel which publishes changes to the resource which that component is interested in. It's a lot simpler and more direct.

possibleNoob 11y ago
This is interesting. Do you have an example or perhaps a library i can look more into? Would this work with phoenix channels?
- jondubois 11y ago
  I made this sample using SocketCluster (I'm the main author): https://github.com/socketcluster/sc-sample-inventory https://github.com/socketcluster/sc-sample-inventory - I wrote a basic realtime CRUD module/layer using SC's internal in-memory storage: https://github.com/SocketCluster/sc-sample-inventory/blob/master/sc_modules/realtime-rest.js https://github.com/SocketCluster/sc-sample-inventory/blob/ma.... That was just for experimenting, now I'm working on a proper version using RethinkDB with a better realtime CRUD interface. My solution doesn't rely on RethinkDB's changefeed feature though, so you should be able to implement a similar binding for any database. WORK IN PROGRESS: https://github.com/SocketCluster/sc-crud-rethink https://github.com/SocketCluster/sc-crud-rethink Basically, the realtime pub/sub layer sits directly on top of the database such that any change made to the database must pass through that layer (The pub/sub layer is responsible for notifying relevant subscribers - Not the database).
hinkley 11y ago
I always figured that a pub/sub implementation at the database (instead of the application layer) would shine brightest in infrastructure and reporting situations. Yes, there are a million ways to arrange for my landing page to 'listen' for every time I make an account change. But getting auditing and analytics and read replicas all working properly has always been a very big drain on developer resources, and if done wrong can create site-wide performance problems. I can't tell you how many times someone has demanded a handful of reporting indexes on the highest (write) traffic tables and then doesn't understand how the whole app got so slow. "I want to know every second how much money we're making today and I don't care if I drive away 10% of our income to get it" sigh What I've wanted every time I've done persistence work in the last 15 years is to be able to have one database that's a partial clone of my 'real' data but with different indexes and lifetimes, without having to re-invent the wheel to get it. I have my fingers crossed that RethinkDB will become that product.

possibleNoob 11y ago

This is interesting. Do you have an example or perhaps a library i can look more into? Would this work with phoenix channels?

jondubois 11y ago
I made this sample using SocketCluster (I'm the main author): https://github.com/socketcluster/sc-sample-inventory https://github.com/socketcluster/sc-sample-inventory - I wrote a basic realtime CRUD module/layer using SC's internal in-memory storage: https://github.com/SocketCluster/sc-sample-inventory/blob/master/sc_modules/realtime-rest.js https://github.com/SocketCluster/sc-sample-inventory/blob/ma.... That was just for experimenting, now I'm working on a proper version using RethinkDB with a better realtime CRUD interface. My solution doesn't rely on RethinkDB's changefeed feature though, so you should be able to implement a similar binding for any database. WORK IN PROGRESS: https://github.com/SocketCluster/sc-crud-rethink https://github.com/SocketCluster/sc-crud-rethink Basically, the realtime pub/sub layer sits directly on top of the database such that any change made to the database must pass through that layer (The pub/sub layer is responsible for notifying relevant subscribers - Not the database).

hinkley 11y ago

I always figured that a pub/sub implementation at the database (instead of the application layer) would shine brightest in infrastructure and reporting situations. Yes, there are a million ways to arrange for my landing page to 'listen' for every time I make an account change. But getting auditing and analytics and read replicas all working properly has always been a very big drain on developer resources, and if done wrong can create site-wide performance problems. I can't tell you how many times someone has demanded a handful of reporting indexes on the highest (write) traffic tables and then doesn't understand how the whole app got so slow. "I want to know every second how much money we're making today and I don't care if I drive away 10% of our income to get it" sigh What I've wanted every time I've done persistence work in the last 15 years is to be able to have one database that's a partial clone of my 'real' data but with different indexes and lifetimes, without having to re-invent the wheel to get it. I have my fingers crossed that RethinkDB will become that product.