GraphQL-server websocket support

[DxCx]

TODO:

• Update CHANGELOG.md with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

Closes #222
Closes #272

[stubailo]

I think this could be really cool! Could you maybe write up a bit of a design about what this is doing and how it changes some of the core packages?

I saw some of the discussion on #272 but I think it would be great if there was a concise description here of what the transport looks like, how this affects people using the HTTP implementation, etc.

[DxCx]

Well @stubailo, i did a short overview in the cast we had, thats why i tought you got it.
Anyway, i do plan writing at least one blog post (or probably more) to help people adopt.

The base protocol is also documented mostly on the issue atm but as you can see i am inteding to format it abit more information and at least add .md under protocol package (adding some basic explanation on apollo docs site, pointing to this md, for those who wants to dig deeper - can be pretty neat)

Btw,
The protocol should be supported by the existing subscription transport ws

[stubailo]

Yeah my thought was more about the implementation design - I understand the concepts of what it's trying to achieve. Basically it's hard to review the code if there isn't a description of what it's trying to do on an implementation level.

For example, I see that we are including an observable polyfill rather than using RxJS - would it be better to use RxJS instead? It would be interesting to hear about some of the design decisions.

[DxCx]

Well, IMO it is worth to use rxjs instead of observable polyfill, it will make code much more readable, however, ive been requested by helfer to support observable the exact same way apollo client does which is with polyfills.

So my hope is that in the future observables will become part of es7 and we can eventually remove all polyfills at least.

Anyway, the ticket was open for discussion for around 2 weeks before i started the implementation, if there are gaps there please write in the issue all the gaps so i can feel them for you and hopefully for everyone else in the future..

[stubailo]

Yes I agree completely with everything presented in the issue - the only thing I'm saying is that I'd like to review this but it's over 2000 lines of code. So it would be good to have some help about where to start and what to look at. The issue mostly goes over how it will be used and the protocol, which is great!

[DxCx]

Alright, But the cool thing is that its splitted into packages So i would not start with a diff but rather with the final branch, reviewing the new packages, and then look at the small modifications of the existing files IMO, this should be the order: 1. Observable 2. Reactive-core 3. Reactive-protocol 4. Websocket

…

On Thu, 23 Feb 2017 at 22:56 Sashko Stubailo ***@***.***> wrote: Yes I agree completely with everything presented in the issue - the only thing I'm saying is that I'd like to review this but it's over 2000 lines of code. So it would be good to have some help about where to start and what to look at. The issue mostly goes over how it will be used and the protocol, which is great! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#308 (comment)>, or mute the thread </~https://github.com/notifications/unsubscribe-auth/ABB8WyERbOp4gjiRcNyHlGeaqveWJPVmks5rfgCCgaJpZM4MEcov> .

[JustinElst]

Is there any way we can progress this pull request? From a quick look it looks good!

[DxCx]

Thanks @MrGekko,
Atm we are in CR phase, waiting for @stubailo to give review notes.
hold on a bit i believe this will be merged soon then i'll start work on client side as well.

[DxCx]

Replaced by the work done on apollographql/subscriptions-transport-ws#108