Talk Ideas

_README.md

Just some ideas for talks... :)

• Using Yeoman At Your Company
• NERF: Nighthawk, Express, React & Flux
• Writing Node Apps At A Startup
• Websockets without SockeIO

Architecting Node Apps At A Startup.md

Architecting Node Apps At A Startup

Startups move fast. To keep up it is important to start with a good foundation. This talk will go through some of the mistakes we made at StreamMe, and what we have learned. Hopefully getting everyone to a place where they feel like they could start a new project on Node that will last for more than a month at a startup.

SOA

New features will happen, and development of them should not be hindered legacy code and practices. Writing your apps in a service oriented architecture can help with this. It means that when you start a new feature you can choose new tools and updated versions of tools and libraries.

Build your apps without dependencies

As your application grows there will be infrastructure pieces and configuration that changes, often based on the server environment (dev, pre-production, production). Build your integrations to these in such a way that they are eaisly de-couppled.

Also, try to make sure that they do not have any environment or external dependencies during development. That means all development configuration should be bundled into the source code repository. That also means your persistence layers and infrastructure should be either optional, or eaisly run separatly for development.

Setup a local NPM

There will come a point where you have some code shared between your applications. Probably on day 2. In the past this, there was a hard decision to make, should you setup and maintain your own internal NPM. I say in the past because now it is easy to setup and run because of NPM Inc's NPM On-Site.

This also solves a large security issue that was recently publicized with the left-pad package issue. Because you are running a local copy you reduce your risk of falling victim to malicious packages. A local NPM in combination with npm shrinkwrap means that you can rely on reproducable builds and secure code.

NERF: Nighthawk, Express, React & Flux.md

NERF: Nighthawk, Express, React & Flux

The NERF stack is what I have named our front-end application architecture at StreamMe. It is a midly opinionated way to build isomorphic React applications. Its main goals are to not introduce complicated tooling and methodologies, but to build off of pre-existing best practices.

Nighthawk

Nighthawk is a front-end router for building single page apps. Instead of implementing its own routing algorithms, it uses the Express Router. In Express 5.0 the router is pulled out as a stand-alone module, which is browser compatible.

Nighthawk is a small wrapper around this that watches for link clicks and other route-changing behaviors, then uses the History api to modify the url. Since Nighthawk is built on top of the Express router, it uses a traditional middleware approach to composing funcionality.

Express

Because the goal of NERF is to keep things simple and NOT introduce many new concepts, it uses the community standard for Node server frameworks. All the things you already know and love about Express are reccomended best practices in a NERF application.

React

We use React because its story for building isomorphic applications is so great. While the rest of the React community seems to be going crazy about the "Next New Thing", I think there is a more grounded approach. This is the approach NERF reccomends when writing applications.

Flux

This is where NERF is only partially oppinionated. We reccomend using an implementation of Flux, but we leave the style up to you. At StreamMe we have a custom implementation built on tools we were already using. Our implementation follows closely with Redux, and for people who don't already have the tools in place choosing Redux is great.

Other tools and practices

NERF gets its name from the four main libraries/ideologies, but there are a bunch of other things that a real application needs. I will also breifly go through these things to illustrate some of the best practices they show.

Using Yeoman At Your Company.md

Using Yeoman At Your Company

This talk would cover a breif intro to Yeoman, then move into creating your own generator. Once we understand the tool, it would move on to how we use Yeoman at StreamMe.

What is Yeoman

Yeoman is a tool for scaffolding applications. It provides a simple toolset for writing our templates based on user input. Yeoman provides a way to compose generators so that parts of your workflow that are shared can re-use the generator logic.

How does StreamMe use Yeoman

We have two generators we use, one for a new application, and one for a new module. Our company uses SOA to build features, so when we have a new section of the site, we make a whole new application to house the features. We use the app generator to scaffold this out. Shared functionality goes into a module which we scaffold out using the second generator.

$ yo streamme:app
$ yo streamme:module

WebSockets without SockeIO.md

WebSockets without SockeIO

In the Node community, Websockets are usually synonymous with SocketIO. We built our original chat system on top of SocketIO at StreamMe. Unfortunatly as we have scalled the application and its feature set, we have found that we have out-grown it. This talk would center around how to build a bespoke Webscoket based application using lower level packages from NPM.

The ws package

This packge provides the low level tools you need to build out your won bespoke websocket server protocol. It is super simple to use:

var http = require('http');
var WebSocketServer = require('ws').Server;

var server = http.createServer();
var wss = new WebSocketServer();
wss.on('connection', function (ws) {
  ws.on('message', function (msg) {
    console.log(msg);
  });
  ws.send('connected');
});

server.listen(8080);

WebSockets in the browser

WebSockets in the browser are simarliarly easy:

var socket = new WebSocket('wss://localhost:8080');
socket.onmessage = function (msg) {
  console.log(msg);
};
socket.send('Hello');

Falling back when WebSocket's dont work

By using SSL you can be fairly certian that if the browser supports WebSockets then you will get a connection. But for clients that don't support it, or when something else fails in the connection process, you might want to provide a fallback. It is also relativly easy to provide a long poll fallback for your sockets.