<p>I've been researching this for a few days now and I'm interested to see if anyone else has some findings they'd be able to share about this.</p>
<p>I'm wanting to build an API in golang preferably using only websockets and move away from the REST (ajax) based system's I've been building for so long. I'm using react on the front end and reflux as my data communication layer. </p>
<p>I've used Meteor for a few projects and really enjoy the reactivity and simplicity of it, however I'd like some more control over when updates are pushed down the wire to clients and also the ability to use a database of my choice (RethinkDB). </p>
<p>Some things I'm trying to figure out in the Golang ecosystem:</p>
<ul>
<li><p>Are there any production tested frameworks for websockets that include fallback (xhr, etc)? I've seen Socks.js for Golang but I'm not sure if it's xhr polling actually works in some older browsers (not as far back as IE8, but ones that don't support full blown websockets)</p></li>
<li><p>Is there a standard methodology for requesting data from a golang websocket server and receiving it back in the same (re)flux store? IE: Would I need to build a router type system for incoming socket messages on the server? Or is the normal way to simply send a specific event to the server, and have a handler setup already listening for the response?</p></li>
</ul>
<p>Basically I'm wanting to build a web app that fully utilizes websockets for all CRUD operations using golang, react and reflux while being able to use RethinkDB changefeeds for certain aspects of the system. So are there any strategies in react for opportunistic style updates and reverting back if said operation fails or is that something that I would need to build manually?</p>
<hr/>**评论：**<br/><br/>vishnuv: <pre><p>You can have a look at mattermost <a href="https://github.com/mattermost/platform">https://github.com/mattermost/platform</a>. It is a slack alternative. It is built with golang and react. Instead of the rethinkdb, they use mysql or postgres.</p></pre>Incisiv3: <pre><p>Thanks, that is a good resource to take a peek at to see how they handled various things.</p></pre>bear1728: <pre><p>While it's not techincally specific to Go, there was a <a href="http://sagemath.blogspot.com/2015/08/react-flux-rethinkdb-and-sagemathcloud.html" rel="nofollow">blog post</a> by the founder of <a href="https://cloud.sagemath.com/" rel="nofollow">Sage Math Cloud</a> about rethinkDB+react. I've contributed to the project and I know the server is written in Node. However William (the founder) built structures called "tables" which are a way of synchronizing data across server and clients. The code is <a href="https://github.com/sagemathinc/smc" rel="nofollow">open source</a>. I don't know how they work but they seem like a way to deal with the data transfer you mentioned.</p>
<p>Where have you searched for websocket go libraries? You should also consider just emailing the authors if you have questions about the libraries. The Go community is very friendly I've found!</p>
<p>Your last question sounds more react+flux specific and less about Go. Have you looked for Go+React projects like <a href="https://github.com/olebedev/go-starter-kit" rel="nofollow">this one</a>. Personally I would suggest <a href="https://github.com/rackt/redux" rel="nofollow">redux</a> over <a href="https://github.com/acdlite/flummox" rel="nofollow">flummox</a> though.</p></pre>Incisiv3: <pre><p>Thanks for that, very interesting about how they implemented rethinkDB.</p>
<p>I've only found a few on github: <a href="https://github.com/igm/sockjs-go/" rel="nofollow">SockJS-Go</a>, <a href="https://github.com/googollee/go-socket.io" rel="nofollow">Go-Socket.io</a> and also the Gorilla toolkit which seems to only support websockets.</p>
<p>I've been using reflux, but Redux does look interesting, i'll check it out!</p></pre>djherbis: <pre><p>Just as a heads up there's some bugs with Go-Socket.io (namespaces don't work, it has race conditions which means anything can go wrong). <a href="https://github.com/googollee/go-socket.io/issues" rel="nofollow">https://github.com/googollee/go-socket.io/issues</a></p>
<p>I wanted to use it awhile back, but there's no sign of fixes for these issues.</p>
<p>I'm currently working on my own socket.io library for Go, but its a hobby project at the moment so dev is slow. (I will support polling when its done though).
I've also written <a href="https://github.com/djherbis/socket" rel="nofollow">https://github.com/djherbis/socket</a>, but its websocket only and I've only used it for small projects.</p></pre>Incisiv3: <pre><p>Thanks for the heads up, I have noticed some issues and I'm actually switching to the gorilla socket package on the project that was using the go-socket.io library.</p></pre>MEAT_FIST: <pre><p>What you're talking about is exactly the thing I'd like to do! If you have a blog or a github that I can read your work, that'd be awesome. I think websockets + react is pretty awesome. I've also wanted to get out of Node and into Go for along time.</p></pre>brilliantdick: <pre><p>You might also look at <a href="https://github.com/gorilla/websocket" rel="nofollow">https://github.com/gorilla/websocket</a></p></pre>FZambia: <pre><p>There is also <a href="https://github.com/centrifugal/centrifugo" rel="nofollow">Centrifugo</a> which is not exactly what you are asking for but it covers many of keywords in this topic - i.e. server to build real-time applications supporting Websocket or SockJS-fallback connections. It's standalone and application must communicate with Centrifugo via provided API to deliver messages to clients.</p></pre>Tikiatua: <pre><p>Hi there,</p>
<p>I actually implemented something like this and have been using it for a smaller application (i.e. 2-3 concurrent users) since a few weeks.</p>
<p>Websockets: I use gorilla/websocket as server library and initially used socket.io as a layer on websockets for automatic reconnection. It is however not to hard to implement your custom re-connection and back-off algorithm in javascript. <a href="https://github.com/labstack/echo" rel="nofollow">Echo</a> is also a nice little library that provides socket handlers in go.</p>
<p>Client Side Handling: React with <a href="http://christianalfoni.com/cerebral/" rel="nofollow">Cerebral</a> is absolutely awesome to manage the client side. Cerebral is similar to Redux but adds some opinionated concepts to make your life as developer way easier (including a reactive-router). All data is managed in one big store (similar to Om) and actions are combined using signals. This makes the data-flow of the application very clear and it is super easy to record your actions and playback – or revert it if necesarry. Handling of asynchronous pathways is also included and you can easily create an optimistic update on the client and revert it later if the server cannot handle the change.</p>
<p>RethinkDb: Using golang channels it is very easy to send updates from a RethinkDb changefeed via the websocket connection to the client and trigger a specific signal. In addition I store all signals as audit trail in a separate table.</p>
<p>Hope this is of some use for you.</p></pre>postman_: <pre><p>I made a similar system and it's a really shitty idea. Most of the time you'll find yourself reimplementing HTTP.</p></pre>Bromlife: <pre><p>Why is it a really shitty idea?</p></pre>postman_: <pre><p>For example, websocket CRUD idea doesn't play well with cookies. You can easily include new cookies/delete old in your HTTP responses, but doing so over websockets would require making them accessible to javascript (a potential vulnerability).
Websockets still tend to be blocked by some proxy servers from my experience (but it could be connected to the fact that I use 8080 as the port for connections).</p></pre>Incisiv3: <pre><p>Yeah the connection blocking issue may be related to port. I would always try to use standard http ports (80, 443) whenever possible.</p></pre>postman_: <pre><p>I forgot to mention one of the most serious downsides: SEO optimization. Without a failback method of requesting data search engines will see just a blank page.</p></pre>captainju: <pre><p>Please explain.
I'd like to know why.</p></pre>postman_: <pre><p>Because all CRUD operations have request/response semantics, so you'll have to implement it in websockets. Basically you will be reimplementing HTTP, but simpler (I hope), over the same TCP connection.</p></pre>Brasilikum: <pre><p>As you might already know the "REST for Websockets" meteor is using to communicate with the client is called <a href="https://www.meteor.com/ddp" rel="nofollow">DDP</a>.
There is at leas on <a href="https://github.com/meteorhacks/goddp" rel="nofollow">implementation in go</a>, unfortunately long abandoned :(</p>
<p>Every communication between server and client is either a static file or DDP.</p>
<p>So a go server with DDP could be used as a drop-in replacement in many cases.</p></pre>Incisiv3: <pre><p>Yeah I found that library a while back when I first started with meteor, but was disappointed that it wasn't really being actively worked on any more.</p>
<p>I'm excited about where meteor is going, but it's just not at the point where I need it yet! A golang library that implements the DDP protocol would be pretty awesome.</p></pre>
