Proposal: Incorporate Websocket to exemplify common modern Real-time App

[somombo]

First of all, I'd like to say that this general project is an amayzing idea. Great work to maintainers!

It may be too late to consider this... but I'd like to propose that in an effort to really cover the basis of modern real-world(TM) apps, some basic websocket feature should be included in the spec and examples.

I believe the basic "Todo" of websockets is chat functionality. So we could showcase how one could use barebones websocket on backend/fronted/mobile to incorporate chat. Other WS implementetion ideas are some other real-time features like collaborative whiteboard or collaboratively doing rich text editing of conduit posts in realtime like google docs (this last one may be too advanced for the exemplary and tutorial nature of this project .. I imagine it using Operational Transforms and such) . Firebase, Meteor, Socket.io, broswerfy, RethinkDB/Horizon, Parse Livequery, featherjs are some hugely popular examples that come to mind when I think of just how much influence websockets (or ”websocket-esk” ) has come to have on the web.

Some technologies covered so far in spec which were deemed sufficiently complex yet exemplary and common place in the real-world(TM) are; REST/HTTP, JWT Auth, CRUD... I'd simply like to add Websockets to that list because I believe it is quite ubiquitous for many web / mobile apps today.

For uniformity, in the spec we could mandate only w3c-compatible websocket APIs/libs be used.

I don't know if this is viable at this point but my hope is that we can have healthy discussion around what form this could take in future and any other ideas.

Perhaps this was all already considered during design phase of this project, if so I'd be curious to here what the thoughts were around excluding it?

Look forward to your thoughts/comments.

[Cameron-C-Chapman]

My initial thought is that websockets is a little beyond the introductory scope of what realworld is trying to do. Websockets are much more common now, especially with mobile apps, but not nearly as common as a basic REST architecture which I think is nice as the default standard for people to learn about a framework. I think a realworld fork that implemented websockets would be great and definitely something we could highlight in the readme and point to for people interested.

Maybe this could be considered in a later version of the spec?

I'm interested to hear everyone else's thoughts but that's my opinion.

[sandeesh]

This is a great suggestion. We see various starter kits on the web for most technologies, although not as detailed or regulated as the realworld project. But finding a starter kit with implementation of websocket is not so easy. So having websocket implementation standardised across multiple codebases would be a real deal breaker. Then again @Cameron-C-Chapman is on point. Websockets are beyond the scope of keeping things simple with the current spec. I'd suggest this for the next version of the spec or as an extra credit feature. Another option would be to maintain a separate fork of the main codebase implementing websocket. Although this would require that we maintain at least one frontend and backend implementing this feature. I'd like to hear others opinion on this as well.

[EricSimons]

Totally agree on all points. Chat is a great idea for the base application, and I think that it would be amazing to (eventually) have an official add-on spec that the current backends can optionally adhere to for enabling WS chat. I actually haven't done a ton of stuff with websockets personally, so I really see the value prop here — would abs love something like this.

I think the right place to start is with some experimentation — fork the node repo and add chat features, then fork rails and add same chat features, etc. Basically create/iterate on examples and through that process we'll eventually hammer down a spec that allows it to be reasonably backend-agnostic. @somombo would you be down to lead that effort? :)

[somombo]

Hi all, thanks for all your feedback.. sorry for my silence, I have actually been experimenting to figure out what is the most minimal thing that can be done that is both representative of reality and portable across several backends..

I have managed to port socket.io's chat example to a php backend and using *only the browser's native Websocket API (I haven't incorporated the rest of realworld.io yet but that should be to hard).. There are somethings i'm still trying to work out however, like how to get it to reconnect automatically when ws connection drops for any reason other than an intentional disconnection (and figuring out whether it's even worthwhile to implement such things for our purpose).. Note I actually code more in nodejs, but I started with php backend because my thinking (perhaps naively) is "if it can be written for php, then it can be written in any other language". My idea is to write out a front end in plain js (no frameworks and no/minimial libs).. and then test that frontend against the same implementation of the backend in different languages. Once that's more stable, the framework-less frontend can then be adapted and refined for the various realworld fronteds/clients.

Another thing I explored was the WAMP websocket protocal, which supports several backend languages out of the box. It supports both pub/sub and RPC based protocol. Seems cool. But after looking closer at its spec and example use cases it seems like overkill.

I will keep you apprised.. @EricSimons when I feel more comfortable with the quirks of library-less browser WS, I should be able to lead the effort. For now still experimenting.

[Cameron-C-Chapman]

@somombo just an fyi there is a front end implementation started using vanilla js, #111. Maybe you could help out with that one?

[jamesbrewerdev]

@somombo Why have you decided not to use a library? In most cases, real world applications will use libraries to avoid having to reinvent the wheel.

[somombo]

@BRWR Since the project is meant to showcase how to do things in different languages/frameworks. So not that I wont completely use any libraries, but I will use library(s) to the extent that they will be flexible enough to standardize our protocol/api for this example use case across several different languages...

So for example, even though in the realworld probably socket.io is the most popular lib for realtime in nodejs ecosystem.. that library is not actually using w3c compliant api, and under the hood uses long-polling http first before trying to use websockets. This is not an approach that will be easily portable to produce the same exact thing for a server backend written in a different language.

[somombo]

@here

Status,

I have php and python backends working.. now working on csharp (dotnet core - command line)... and that will be the last backend i'll work on ... the three should provide enough variety to exemplify how we can go about this.. For clients of course I have browser working.. I also plan to attempt a NaitiveScript client but.... dont hold your breath 😉

edit When I say "working" I mean just barebones, i.e. it's not integrated to the rest of realworld yet e.g. for persisting the messages on a db and for leveraging the jwt auth that's already available in the rest of the project. It's strictly just realtime chat so far

[EricSimons]

@somombo that sounds awesome! I can't wait to see the code once it's ready 🎉 👍