Custom Transports For Skyring

2017 May29
S

kyring is a distributed system for managing timers. When a timer lapses, a message is delivered to destination that you have defined. *How* that message is delivered is configurable. Out of the box, Skyring comes with an `HTTP` transport, and there is an official package enabling tcp delivery of messages with connection pooling. They are pretty easy to write, and you can use any of the tools you are currently used to using.

STDOUT Transport

To illustrate the process, we're going to make a simple transport handler to write the data to stdout. Basically, speaking a transport is just a node.js module that exports a named function

Module [ˈmäjo͞ol] -n., --noun

any of a number of distinct

Read More
filed under:  zmq skyring timers node.js

Summer Of Sockets Part 4: Multi-Part Messages With Node.js & ZeroMQ

2015 Jan22
I

n previous installments of Summer Of Sockets, we took a look at the basic messaging socket types in [ZeroMQ](http://zeromq.org), **PUSH**/**PULL**, **PUB**/**SUB** and **REQ**/**REP**. Each of these types provides different patterns of messaging between their connected peers. Up to now, we have been passing simple message around to illustrate the patterns. In larger, more complicated applications, the message will need to carry more information.

In JavaScript, that typically means constructing, passing and parsing JSON objects, as well as accounting for missing fields, and event embedding message types and meta data about usage into object. This quickly becomes messy and overly complicated.

JSON is a fine data format, but ZeroMQ provides a very handy facility

Read More
filed under:  zmq summer of sockets node.js

Rebuilding The Codedependant Blog

2015 Jan12
I

t has been about 3 years since I launched my blog. At the time the tech was pretty interesting. It was a Django project on mongrel2 app server backed by ZeroMQ and xapian as the search engine. I built out a modular Web UI with a WYSIWYG editor using mootools. But it was rather clunky in how it actually generated HTML and usually required some manual tweaking.

Out With The Old

The WYSIWYG Editor was probably the biggest problem. It took serious liberties in cleaning the HTML and usually resulted in me editing the code by hand in the end. Interesting code blocks with highlighting was a 3 step process and was almost always formatted wrong.

Managing Images was

Read More

Summer of Sockets part 3: Pub Sub With ZeroMQ

2014 Sep13
S

o far we have looked at PUSH/PULL and REQ/REP. One of the more interested socket combinations in ZeroMQ is PUB/SUB. PUB/SUB has multitude of real world applications in distributed systems, Ranging from remote Work Queues, Push notifications for real time web applications, inter-application communications, etc. Like other socket types found in ZeroMQ either each the pub and sub socket types can either bind or connect to an endpoint. It is really a matter of your applications use case. In general, the part of the application that will have the greatest up time would bind to a port and all others would connect.

There are two primary difference with the PUB/SUB sockets over the previously

Read More

Summer of Sockets Part 2: Request and Response With ZeroMQ

2013 Dec29
Z

eroMQ makes it incredibly easy to connect and communicate between individual applications in distinctive patterns. Last time we took a look at the simple PUSH / PULL socket types. The next types we'll take a look at are the Request / Reply ( REQ / REP ) sockets. You can [download](https://bitbucket.org/esatterwhite/summer-of-sockets/src) the source code for the following examples if you would like to follow along.

Request & Reply sockets are probably the most familiar and easiest to reason about for web developers. This most obvious use case with REQ and REQ sockets, is a web server. A client ( REQ ) makes a request to the server ( REP ) and it waits until a response comes back. Unlike the PUSH  socket,

Read More

Summer of Sockets Part 1: Playing With ZeroMQ and NodeJS

2013 Sep03
T

he last few months I've spent working distributed systems for web and tel-com systems. Web applications are notorious for being monolithic, tightly coupled pieces of software under a single code base. This just fine when you application really just needs to work within itself. When your application need to share data with other applications, possibly written in different languages, frameworks, or even off load long running tasks, things can quickly become a challenge. To rectify such problems, most developers reach for a central message queue like RabbitMQ. Now, RabbitMQ is a great piece of technology, as the tag line says, `It Just Works`. However, it posses a couple of interesting problems that has turned me off to it.

Single

Read More