he very idea of distributed timers is complex. Conceptually is full of race conditions and edge cases. Skyring for Node.js boils the problems space down to a simple to use library and API for building scalable service that need to perform time sensitive, actions. That is a mouthful - Think An email gateway, a web-hook service, auto-dialers for telephony systems. Or in the most practical sense, anytime you might need functionality like setTImeout but needs to survive restarts / crashes; Or are using a language that doesn't support non-blocking timers. Skyring fills that gap, and it is easy to use. We can get something going in less that 20 lines of code.

To start, we just install the skyring

ver the years I have had a handful of times where I have had the need for Multicasting. It usually comes about in service or node ( application ) discovery. Or if you are lucky enough, the dreaded distributed setTimeout / clearTimeout. Every time find a need for it, I spend hours in the documentation trying to remember how to use it, remembering the Node.js Docs for dgram - which are virtually void of any useful explanation or examples. Finally resorting to finding googling around for the 1 or two examples of multi casting out there and hack something together. It shouldn't like that. It is actually really easy to do with Node.js. Let's give it a shot.

Let's say

eroMQ has its fair share of quirks and oddities. It manages everything in a global state, requires things be manually grouped into Contexts, allocates a thread per context (making it not thread-save) , transports are baked into the library, and so on. It can be a bit clunky to work with at times. As a result, one of the original developers on the ZMQ project, Martin Sustrik, started a new project that evolved into a complete re-write / re-realization of the ZMQ project, called nanomsg.

Nanomsg aims to resolve many of the underlying short comings of the zeromq library, but remain compliant with the ZMTP spec. It provides many of the messaging patterns ( which are refereed to as scalability patterns ) as

omains have been the red-headed step child of error handling in Node.js It is a library that has been deprecated since v0.12 and has been awaiting a suitable replacement ever since ( we are at v6.5 at the time of writing ). Until one has been implemented by the Node Core team, it is still de-facto way to deal with error propagation. As Node.js supports more and more ES6 features, I have been upgrading my open source projects where it seem appropriate. In my command line tool package, seeli, I was doing some updates and came across some exceptionally odd behavior around ES6 Promises and implicit Domain binding. In a nutshell - It's broke.

ˈməNGkē paCH -v,

ne of the more tricky and debated topics in API circles is how to handle relational data. How deep into your data tree should it go, how to accept it from the client and how much to return to the client. One could choose to treat each resource as a silo and force the client to individually create each object and piece all of the relations together. However, that is not a great user experience. It also leads to a very large number of requests and data transfer, which has been a blemish on the idea of a REST API for a while. The emergence of modern mobile devices which limited bandwidth and performance profiles need a more streamlined

icroservices are becoming the de-facto way of building out large applications. If you haven't worked on a project that has migrated monoliths to micro-services, you are most likely working on a microservice of some flavor or another. And as you might imagine, Docker / containers are the preferred way of delivering these services. Managing all of these containers and services is no easy task and has lead to the rise of private PAaS projects, operating systems, and orchestration framewoks like Dies, Mesos, Kubernetes - A new one is popping up every month.

Choosing a framework, or a stack is, in it of itself, no simple task. Personally, I have been following CoreOS, both the company and the operating system as

ne of the major components of a tastypie resource is the data preparation cycle, or hydration cycle. The hydration cycle is the aspect of a resource that is responsible for massaging raw user input into data objects suitable for saving to a data source, and vice versa.

The hydration cycle also encompasses the serialization machinery of the resource which is responsible for converting data object into standard data formats ( JSON, xml, etc ) and vice versa.

Serializtion Cycle

Each Tastypie resource has a Serializer instance which it uses internally to convert data between well formatted string and javascript objects. This behavior is defined in the serialize and deserialize resource methods A serializer class defines how
data is converted to and

cess control is apart of virtually every application. Certain users should be able to see / do X, but never be able to do Y. Usually these kind of requirements are expressed in overly simple terms, such as:

Admin users should see that button but regular users should not.
--Every Product Manager. Ever

With traditional RDBM Systems, the direct approach is to set up a Many-To-Many relation ship between Users and Roles Where roles are basically like tags. Subsequently code paths are created to check if a user has a role named admin . Which gets very ugly as these sorts of simple checks quickly have to cover increasingly complex logic for users with multiple roles and for roles that

e have been taking a look at how to use Tastypie to easily create robust, feature rich REST APIs. Our focus has been on CRUD operations, mainly because they are the ones that ship with tastypie. However, we are not restricted to CRUD with tastypie. You can define any number of endpoints to do whatever you want. To create a custom set of endpoints there are three basic things you need to do:

• Define a route
• Define a handler
• Define Method Access

Last time we wrote a very simple resource that allowed use to just return simple objects. We are going to continue with that example by adding some custom routes to it. If you are joining in late,

ast time we took a look at setting up a pretty full featured REST api centered around Mongoose. However, sometimes simple is better. Maybe you don't want and/or need all of the extra things that the MongoResource in Tastypie provides. Sometimes you just want to get something, anything working and dump out some data. We don't need paging, caching, filtering, validation, etc. Luckily, Tastypie gives you a dead simple way to do this by simply defining the methods you want to support. Resource methods are defined as <HTTPVERB>_<ACTION>. So a dumb crud resource would look like this:

The Simple Resource

var Resource = require('tastypie').Resource;

var Simple = Resource.extend({  
    get_list: function( bundle