jpillora / velox

Real-time Go struct to JS object synchronisation over SSE and WebSockets

velox

Real-time JS object synchronisation over SSE and WebSockets in Go and JavaScript (Node.js and browser)

Features

• Simple API
• Synchronise any JSON marshallable struct in Go
• Synchronise any JSON stringifiable struct in Node
• Delta updates using JSONPatch (RFC6902)
• Supports Server-Sent Events (EventSource) and WebSockets
• SSE client-side poly-fill to fallback to long-polling in older browsers (IE8+).
• Implement delta queries (return all results, then incrementally return changes)

Quick Usage

Server (Go)

//syncable struct
type Foo struct {
	velox.State
	A, B int
}
foo := &Foo{}
//serve velox.js client library (assets/dist/velox.min.js)
http.Handle("/velox.js", velox.JS)
//serve velox sync endpoint for foo
http.Handle("/sync", velox.SyncHandler(foo))
//make changes
foo.A = 42
foo.B = 21
//push to client
foo.Push()

Server (Node)

//syncable object
let foo = {
  a: 1,
  b: 2
};
//express server
let app = express();
//serve velox.js client library (assets/dist/velox.min.js)
app.get("/velox.js", velox.JS);
//serve velox sync endpoint for foo (adds $push method)
app.get("/sync", velox.handle(foo));
//make changes
foo.a = 42;
foo.b = 21;
//push to client
foo.$push();

Client (Node and Browser)

// load script /velox.js
var foo = {};
var v = velox("/sync", foo);
v.onupdate = function() {
  //foo.A === 42 and foo.B === 21
};

API

Server API (Go)

Server API (Node)

• velox.handle(object) function returns v - Creates a new route handler for use with express
• velox.state(object) function returns state - Creates or restores a velox state from a given object
• state.handle(req, res) function returns Promise - Handle the provided express request/response. Resolves on connection close. Rejects on any error.

Client API (Node and Browser)

• velox(url, object) function returns v - Creates a new SSE velox connection
• velox.sse(url, object) function returns v - Creates a new SSE velox connection
• velox.ws(url, object) function returns v - Creates a new WS velox connection
• v.onupdate(object) function - Called when a server push is received
• v.onerror(err) function - Called when a connection error occurs
• v.onconnect() function - Called when the connection is opened
• v.ondisconnect() function - Called when the connection is closed
• v.onchange(bool) function - Called when the connection is opened or closed
• v.connected bool - Denotes whether the connection is currently open
• v.ws bool - Denotes whether the connection is in web sockets mode
• v.sse bool - Denotes whether the connection is in server-sent events mode

Example

See this simple example/ and view it live here: https://velox.jpillora.com

Here is a screenshot from this example page, showing the messages arriving as either a full replacement of the object or just a delta. The server will send which ever is smaller.

Notes

• JS object properties beginning with $ will be ignored to play nice with Angular.

• JS object with an $apply function will automatically be called on each update to play nice with Angular.

• velox.SyncHandler is just a small wrapper around velox.Sync:

  	```go
  	func SyncHandler(gostruct interface{}) http.Handler {
  		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
  			if conn, err := Sync(gostruct, w, r); err == nil {
  				conn.Wait()
  			}
  		})
  	}
  	```
  

Known issues

• Object synchronization is currently one way (server to client) only.
• Object diff has not been optimized. It is a simple property-by-property comparison.

TODO

• WebRTC support
• Plain http server support in Node
• WebSockets support in Node

MIT License

Copyright © 2018 Jaime Pillora <[email protected]>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

velox's Issues

Allow object to be empty on client side

Hey there,

I came across your project and I really love it!

I recently realized that the Velox constructor on the client side doesn't allow for the obj parameter to be empty. Your examples use global objects like

// load script /velox.js
var foo = {};
var v = velox("/sync", foo);
v.onupdate = function() {
  //foo.A === 42 and foo.B === 21
};

As it can be seen, there are no requirements to the passed object besides being of type object.

However, since the onupdate callback passes this.obj as a parameter anyway, the object containing the received data doesn't need to be global (when using SSE, at least). Right now I'm using

var v = velox("/sync", {});
v.onupdate = function(obj) {
  //obj.A === 42 and obj.B === 21
};

to avoid using global objects, but this still looks a bit ugly. It would be better if the empty object could be omitted and instead be implicitly created by the constructor like velox("/sync").

I would therefore propose a change in the constructor of the Velox class like

obj = obj || {};
if (typeof obj !== "object") {
  throw "Invalid object";
}
this.obj = obj;

to implicitly create an empty object when the parameter obj is omitted instead of throwing an error.

Kindly
bliepp

caching

The way that the data is held on the golang side is a pointer ?
So its a shared memory area, and so i was condering about using it as a cache, because it seems to make sense.
As such, i am thinking that some sort of management channel is needed, so that i can tell clients to drop their cache and reload. The reason i am thinking this is worthwhile is because the cache needs to be dropped and reloaded when upgrades happen etc. Otherwise there is a risk that the clients will think that all data has been dropped and react in inappropriate ways.

i could be wrong here of course, but as i was thinking through use cases of using this on a project, its what hit me.

What do you think ?

thanksn advance.

Link to github code broken on demo site

Just to let you know, this link is broken at velox.jpillora.com:
https://github.com/jpillora/velox/blob/master/example/demo/main.go

How to define a custom event type?

As shown in this screenshot:

All the events are being sent with type "message". Is there a way to change for instance to "chat", "price", "my-type"?

Thanks

Feature: Implement a Go client

This is great.

The patch functionality being used server to server and server to web client is reusable

I have 2 ideas :

1. As the data changes on the client, you want to be able to react to it. This is an interesting challenge. I am thinking a simple switch statement, almost like a reverse router. The programmer simply expressed changes in the strut they subscribe to.
2. East West agnostic. Using this just client server is awesome. But I can see it being useful between golang servers too.