Over the weekend I had what at first appeared to be a small challenge: send out a few hundreds e-mails for a non-profit's outreach campaign. MailChimp and other mailings lists were not a good fit, as these messages were of the cold-call variety, and a formal mailing list felt too spammy. Initially I wrote a utility in .NET, but ended up solving with Node.js instead due to timeouts experienced with SmtpClient.
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.
Time to turn that Node.js test green. In Part 2, I succeeded in publishing a message to RabbitMQ using Node.js. However, my automated test failed: the .Net test runner could not handle the generated message. Three key elements were missing, which are required for the MassTransit .Net library to interpret the message correctly:
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.
And now, I finally get back to blogging about the ASP.Net Web API code that I wrote for this head-to-head comparison of REST service and message bus integration. The official tutorials were my guide for Web API, and as with the test runner in part 1, I used MassTransit as a convenient library for publishing from .Net code to RabbitMQ. Owin was my solution for self-hosting the web application.
Many social websites, and web-based applications, have a notification process where the server sends a signal back to the browser, informing that particular user that there is a message. "You've got mail," as America On-Line used to say it. Consider the picture below, from Twitter, which shows that I have one new notification. That number increments automatically when a new notification arrives, without having to reload the full page. How does that work? Well, this blog post doesn't try to answer that directly. In fact, it is simply a collection of notes pointing out how to use Microsoft's SignalR technology to achieve this.
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.
This is part two in a series. Part 1.
Let's start with Node.js. I already let you in on the fact that formatting a message for .Net to pick it up is tricky, and I won't get into the detail of that yet. For now, let's concentrate on setting up node.js and communicating with RabbitMQ. We'll get the finer points of interacting with .Net later.
Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ. Naturally, such a test does nothing to prove that one framework is generally faster than the other, but it is a fun exercise nonetheless.
Thus the challenge is this: accept a string message via POST, forward it to the
service bus, and return HTTP Status Code 202 (Accepted) along with an
acknowledgment that repeats the original message. Both REST services should be
self-hosted; free from additional cruft like error-handling*; and should utilize
an url like http://localhost:port/Message/mymessage, where "mymessage" is the
string to be sent across the bus.
Basic was the first language I learned. Well, partially, in 8th grade. On Apple IIe at school and a Packard Bell 386 PC at home. A few years later, JavaScript came out and it became the first "modern" language I used. As an undergraduate physics major, I found it useful for quickly generating sample data or running some numerical approximations (simpler than Mathematica). Then I wrote a few web minor pages with DOM manipulation, before any of the modern frameworks had come out. I went to work, used it occasionally, but never had any excuses in work or home life to do more than dabble. The revolution was passing me by.
Windows Communication Foundation (WCF) is a great tool for building client/server applications in the .Net environment. It is one of those technologies that can be challenging to dig into when services are just one of many tools needed to assemble a business application, as opposed to being an end in itself. With some of my co-workers in mind, here are some of the lessons I have learned in using WCF for internal, line-of-business, applications. These notes, which will be published in several parts, assume a basic understanding of WCF and contracts.
I have set myself the goal of learning how to develop a Windows user interface with a moderately complex workflow, one that implies a Wizard-like set of screens to guide the user through a set of steps. The demonstration project's architecture will utilize the Model-View-ViewModel (MVVM) pattern, with the help of Caliburn.Micro (CM). The solution will utilize the Application Controller pattern and CM's Conductors.
This is a technical blog, right? Why would I mention this virtue? In Management 3.0, Jurgen Appelo suggests in "Do-It-Yourself Team Values" that the various Agile, Lean, XP, etc. principles are, quite simply, virtues. Teams should pick a small number and focus on them. "Kindness" is not among the 50 virtues he suggests thinking about, but it should not come as a surprise that that my rationale for "kindness" will overlap that of many other virtues, such as "helpfulness," "mindfulness," "tactfulness," and "service." Each of these single words offers a slightly different window into an ineffable world of human goodness, and I choose "kindness" for this theory. First, a minor digression.
