Live updates

[mxstbr]

In #8 we decided to add adapter.subscribe to allow to subscribe to changes in the database. We need to somehow implement a live API endpoint to allow UIs to show realtime data! (websockets?)

[mxstbr]

We should land this before landing database adapters to make sure they all support this functionality. @relekang do you want to dive into this?

[relekang]

Should we land full functionality or just the implementation of the adapter?

I can look into it :v:

What do you think about adding adapter.subscribe as observables like we discussed earlier and websockets to push it out with the websocket library?

[mxstbr]

Should we land full functionality or just the implementation of the adapter?

The former, I think. How else are we going to test it?

What do you think about adding adapter.subscribe as observables like we discussed earlier and websockets to push it out with the websocket library?

Sounds great to me! This is what I imagine the usage of adapter.subscribe looks like:

const subscription = adapter.subscribe('/hello')({
  next(val) {/* Send new value */},
  error(err) {/* Send error */},
  complete() {/* Cleanup after unsubscription */},
})

See #21

[luisrudge]

why not an event based approach that will work if we want to add different events in the future?

db.on('put', () => { doSomething(); })

[sean-roberts]

I'd go EventSource with this right? Not sure that we are looking to set up a two way channel?

[relekang]

EventSource sounds like a good option if we are okay with the browser support. Edit: I guess this can be solved with polyfills

I have started to look into this, but have not used observables before so trying to figure out the best way to implement it in the adapters. Any suggestions, do we want to use rxjs or something similar?

[luisrudge]

EventSource !== Server Side Events

[relekang]

@luisrudge The link goes to #feat=eventsource, is that wrong?

Anyhow, do you mean that eventsource is a subset or that it has nothing to do with server side events?

[luisrudge]

Ok. I'm wrong. I didn't read the spec at all. It's just I come from the event sourcing world in .NET and thought we had some confusion about the naming. It turns out that we actually have EventSource in the spec: https://html.spec.whatwg.org/multipage/comms.html#eventsource Sorry about that, folks!

[mxstbr]

Any suggestions, do we want to use rxjs or something similar?

RxJS is huge afaik, not sure we need all of that power. I'd much rather go with something like zen-observable, which seems to be a polyfill for the spec? (have never worked with observables either though)

[mxstbr]

The choice between websockets and EventSource is interesting, since one will require a library (websockets) and one a polyfill. (EventSource) I'm inclined to go with EventSource as it doesn't make any difference for the size of the webpage and it's a standard that fulfills our exact needs.

We can use https://www.npmjs.com/package/eventsource on the backend as well as recommending it as a polyfill.

What do you think?

[luisrudge]

Why would you go with the least supported feature?

[relekang]

RxJS is huge afaik, not sure we need all of that power. I'd much rather go with something like zen-observable, which seems to be a polyfill for the spec? (have never worked with observables either though)

Sounds good 👍

We can use https://www.npmjs.com/package/eventsource on the backend as well as recommending it as a polyfill.

What do you think?

This also sounds good to me.

I hope to get a PR up tonight.

[sean-roberts]

it falls back really easily with ajax because ajax and event source are http based. not to mention ws is a pretty bloated solution for server sent events

[sean-roberts]

in addition, browser support isn't quite a micro analytics problem here but rather it's the end-client consuming this api's problem. In which case it's "easy" to have polyfilled.

[mxstbr]

Why would you go with the least supported feature?

Did you read my above comment?

WebSockets need a library, EventSource a polyfill. What's the difference? In both cases the user has to ship a random JS file.

In fact, socket.io-client the slim version (!) is 51kb minified (!!!), whereas the EventSource polyfill is 10kb. Why would we force users to use a 51kb library over a 10kb polyfill?

[luisrudge]

Yes. I read your comment, but you don't need a lib to use WS. I think WS is more future proof, since we could add two-way communication if we ever need/want to. With SSE, you're stuck with sending ajax requests if you ever want to send data from the client to the server.

[mxstbr]

Interesting thought, what usecase would we have for two-way communication?

[luisrudge]

None that I can think right now. 😛

[sean-roberts]

Yeah, not sure what need there would ever be to have a real-time log viewer be able to add metrics too. 👍

[relekang]

I am currently a bit to busy to get anywhere with this. Will check back next week if anyone has not picked it up by then.

[relekang]

Closing this now, it was released in 2.0.0 :v:

[mxstbr]

:tada: