6 ms·

It is built on top of express to keep all of the good things, but it adds basic middleware and some more advanced functionality like websockets through socket.i

It is built on top of express to keep all of the good things, but it adds basic middleware and some more advanced functionality like websockets through socket.io and security through helmet by default. It is designed to work perfectly with Promises and async/await, the new ES7 features that makes asynchronous code awesome. Also, I put a lot of work into making the documentation extensive and clear and I'll keep working on that for the future while preparing for the 1.1. Edit, release notes: https://medium.com/server-for-node-js/server-js-1-0-released-12a419ab187a https://medium.com/server-for-node-js/server-js-1-0-released...

picardo 9y ago
I like the design of the API, but I don't understand what you mean by "built on top of express?" I see you have express in a plugin module, but I'm not sure how it's being used.
- franciscop 9y ago
  It is being used underneath to connect all of the moving parts.
- niix 9y ago
  In the package.json you can see its a dependency of the project. So it seems like its more of an abstraction of Express than an alternative.
josephorjoe 9y ago
Looks interesting -- will check it out. I've definitely found the batteries-not-included nature of express to be annoying at times.
josephg 9y ago
Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets
- Can_Not 9y ago
  Socket.io adds rooms/namespaces as a feature, automatically reconnects with effort to not have all clients reconnect at the same time, covers compatibility edgecases, heartbeat, timeouts, custom events, multiple transport methods, server side implementations in multiple languages, supports non-ws fallback for reasons that might not be browser compatibility, and a good API.
- aphextron 9y ago
  >Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? The real reasoning is browser support. Socket.io supports automatic fallback to AJAX long polling if the client doesn't support websockets. It also standardizes the interface across clients. It's essentially to websockets what jQuery is to the DOM.
- always_good 9y ago
  For one, it has message_id ackbacks so that you can have a request/response rpc style system. A basic feature for any websocket-heavy application. socket.send('login', [uname, pass], (err) => ...) And there are socket-io clients for most languages that can interop with a socket-io server, once again supporting message_id callbacks. Reconciling my own message_id + reconnect buffer system is not something I want to build on the client + server every time I build an application. People talk shit about socket.io and then never recommend an alternative that implements this fundamental feature. Without message_ids, I get flashbacks to working with IMAP.

picardo 9y ago

I like the design of the API, but I don't understand what you mean by "built on top of express?" I see you have express in a plugin module, but I'm not sure how it's being used.

franciscop 9y ago
It is being used underneath to connect all of the moving parts.
niix 9y ago
In the package.json you can see its a dependency of the project. So it seems like its more of an abstraction of Express than an alternative.

josephorjoe 9y ago

Looks interesting -- will check it out. I've definitely found the batteries-not-included nature of express to be annoying at times.

josephg 9y ago

Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets

Can_Not 9y ago
Socket.io adds rooms/namespaces as a feature, automatically reconnects with effort to not have all clients reconnect at the same time, covers compatibility edgecases, heartbeat, timeouts, custom events, multiple transport methods, server side implementations in multiple languages, supports non-ws fallback for reasons that might not be browser compatibility, and a good API.
aphextron 9y ago
>Why socket.io instead of just plain websockets? Socket.io adds a lot of complexity in the client and the server. What commensurate benefit does it provide? The real reasoning is browser support. Socket.io supports automatic fallback to AJAX long polling if the client doesn't support websockets. It also standardizes the interface across clients. It's essentially to websockets what jQuery is to the DOM.
always_good 9y ago
For one, it has message_id ackbacks so that you can have a request/response rpc style system. A basic feature for any websocket-heavy application. socket.send('login', [uname, pass], (err) => ...) And there are socket-io clients for most languages that can interop with a socket-io server, once again supporting message_id callbacks. Reconciling my own message_id + reconnect buffer system is not something I want to build on the client + server every time I build an application. People talk shit about socket.io and then never recommend an alternative that implements this fundamental feature. Without message_ids, I get flashbacks to working with IMAP.