Writing Express Middleware to Modify the Response

I recently had a need for some Express middleware that would track any change to a variable, and send the details of any changes in the response, but only if the response is JSON data. This turned out to be rather more interesting delve into ExpressJS than I expected, and I thought the details of it were worth a post detailing how to do it, and my findings.

The first thing you notice when writing Express middleware functions is that they take three arguments (I’m skipping error-handling middleware deliberately), the request, the response and a next() function that triggers the next step in the processing chain. The next function doesn’t typically take any arguments, instead you’re expected to modify the request and response objects to expose or capture any changes you want.

This post will show you how to capture any changes to a variable (we’re going to pretend all our users are playing a game and we have a leader-board), we want to track any changes that happen during the request and report both the changes and the current state of the variable in every response. I’m going to assume some other middleware has injected a user property onto the request. First off, this is what the code will look like:

const leaderboard = require('./leaderboard');
function leaderboardTracking(req, resp, next) {
  const user = req.user;
  const startingPosition = leaderboard.getUserPosition(user);
  const json_ = resp.json; // capture the default resp.json implementation

  resp.json = function(object) {
    const endPosition = leaderboard.getUserPosition(user);
    object['leaderboard_info'] = {
      'delta':    endPosition - startPosition,
      'position': endPosition,
      'score':    user.score
    };

    json_.call(resp, object);
  };

  next();
}

So in this example we swap out the json function with our own delegate implementation, but you’ll notice we leave the send function alone. The send function will delegate to the json function if it’s given a plain JavaScript object, and json in-turn uses send after stringifying the object.

You’ll also notice that the code doesn’t just invoke the captured json_ function, it uses the call function and specifies the response as this. The json function in Express expects to be invoked within the context of the response object, so we need to keep it that way.

That’s it really, it’s not a terribly complicated pattern, but it can be extremely powerful because it bounds the request / response cycle end-to-end.

Advertisements

EoD SQL Applied – Part 5 / 5 (GWT Applications)

The Dreaded “Not Serializable” Problem

GWT turns all of your Java code into JavaScript, but it also obfuscates everything. With this in mind, it makes serialization a bit more complex than usual. GWT generates a serializer and deserializer for each class that could be transported across the wire to an RPC service. The difficulty comes in knowing which types had code generated, and which didn’t. GWT solves this problem for itself with the Serialization Policy file, where the compiler lists all of the classes that the client code will know how to deserialize.

This however leads to another problem: what happens when something unexpected gets in the way. Hibernate is the most used, and thus most complained about when it comes to Serialization problems. Hibernate turns any Collection object into a special “lazy” implementation that will only load your data when you ask for it. All very fine and well for a server bound application, but a GWT application needs all that data up front for serialization. When GWT comes to sending that List<Message> to the client, it chokes. It knows how to serialize an ArrayList, and LinkedList (since you worked with them on the client side), but a Hibernate List or PersistentCollection is a totally unknown type, so it’s not in the Serialization Policy, so the server side throws an Exception at you.

So how does EoD SQL help with these problems? Read on to find out! 😉 Read the rest of this entry »

EoD SQL Applied – Part 4 / 5 (JavaScript)

JavaScript vs. Web Applications

So far in this series we’ve discussed using DataSets for Swing applications and DataIterators for web-applications. Why would I now bring in JavaScript as something outside of “web-application”? JavaScript applications have very different requirements to a normal web-application. Where a normal web-application has little ability to do things like preload data (like the next page), a JavaScript application may (for example) download the entire data-set and then display it in pages. This next section is about binding to JSON for JavaScript applications.

First thing to remember here is that an EoD SQL DataSet is a List and thus compatible with the Collections API. For this example we’re going to be working with the outstanding GSON API from our friends at Google. Our objective here is to minimize the amount of time spent between the Database and pushing the data to the client. Because GSON doesn’t appear to support Iterable object out-of-the-box, we’re going to start off using a DataSet.
Read the rest of this entry »

EoD SQL Applied – Part 3 / 5 (JSP / Servlets)

Static Data Display

In a Swing application with a direct connection to a database, it makes sense to leave the database to do much of the heavy lifting. The Swing client can keep a minimum amount of data in memory, while holding a scrollable Result Set open on the database (fetching more of the data as required). In a web application on the other hand, things are a little more complex. For one thing, your database isn’t exposed to the any part of the network; for another: your clients have no ability to keep Result Sets open; and finally: you generally are working with much higher loads than a Swing application.

EoD SQL has many different approaches to loading data from the database. We’ve already looked at DataSet objects, which remain connected to the database and work well with scrollable, cursor backed, Result Sets. DataSets are (in a way) a leftover from the origional EoD API from Java6-beta (where they were the only way to fetch objects from the database). In this post we’ll take a look at an EoD SQL idea: DataIterators.

Read the rest of this entry »

Eod SQL Applied – Part 1/5 (Introduction)

Introduction

This is the first part of a series of posts, dedicated to how best to apply EoD SQL in different types of applications. Each post in this series will cover a specific type of application, and the different parts of EoD SQL that generally work best within those applications. The articles may dive fairly deep into the workings of the API, but at the end you’ll have a much better idea of where things fit in, and how they fit together.

EoD SQL well understands that (a) people like to do things differently and (b) one solution is not right for everything. While under the hood: any one part of EoD SQL works much the same way as any other part, as you climb the structural ladder, things begin to behave very differently. These behaviors have a massive performance and memory impact on your application and how you will be treating the underlying database drivers.

What we’ll be covering

  1. Swing Applications
  2. JSP / Servlets and “Related Technologies”
  3. JavaScript / JSON Applications
  4. GWT Applications

Although you could go with the “one size fits all” route (and EoD SQL would still perform wonderfully), the objective of these posts is to expose you to the different flavors of EoD SQL data structures and get you thinking about how you can mix and match them in your application to produce different results.

Why TraceMonkey is maybe the wrong way

With Firefox 3.5 finally out the door and in use I thought it was time to write something about it that’s been bugging me for a while. TraceMonkey (the new FF JavaScript engine) employs a semi-Hotspot approach to JavaScript compilation. Although the approach is quite different under-the-hood, the basic principal is the same: interpret the code until you know what to optimize. This makes abundant sense to me: why go through the expense of native compiling a method that only ever gets run once? However: there is a hidden expense to doing things this way: your compilation unit is often much smaller. Smaller compilation-units means more compiled code that needs to go back and forth to interpreted code. It also means you can’t optimize as heavily (although that optimization has it’s own massive expense).

Where am I heading with this? I think the TraceMonkey approach adds huge value to a language like Java where an application consists of hundreds and / or thousands of classes (both those in the application and all of it’s dependent APIs), in this case: you’re loading time would be abysmal if you pre-loaded all the possibly used code and native compiled it on start-up. However in the JavaScript world we are limited by the connection, and JavaScript applications (even really huge ones like those written with GWT) are relatively small. In this case it makes more sense to me to either compile everything up front; or run everything interpreted and run a massive compilation in the background (hot-swapping the implementations when you’re finished the compile).

It’s just a thought. Maybe FF should adopt v8 and see what happens?

Simple Credit Card Fraud Checks

Credit Card Fraud is one of the hardest problems to deal with as an online business, in many cases it comes down to a human check to ensure that the credit-card in valid before accepting it. Using automatic scoring services certainly helps, but doesn’t by any means eliminate the problem (since they can sometimes be horribly inaccurate).

Here are a few additional checks you can do from inside your system:

  • Blacklist card-numbers
    Some people have real plastic fake card and will re-use the number again and again. Blacklisting the number eliminates the need for a human check later down the line.
  • Blacklist email addresses
    If you have an email address verification (you may require a valid email address to distribute your product) you can easily blacklist an email address. It’s not 100% effective because people can get free email addresses, but most of these sorts of fraud transactions are done by hand, and it often takes some time for the person to figure out whats gone wrong.
  • Score based on previous transactions
    If you can identify the user (by name, email, or some other means) you can see how reliable they have been in the past.
  • Address Verification
    There are several services out there that will provide you with the billing address registered with the bank for a card-number. This will also determine whether such a card even exists.
  • Human Verification
    At the end of the day, there is no substitute for calling the person up and talking to them (and maybe getting a photo of the card faxed to you). However, this is costly and should only be done with the most suspect cards.