Building Isomorphic JavaScript Apps

Chapter 9. Creating Common Abstractions

Jason Strimpel

In this chapter we will create two abstractions that are frequently needed by isomorphic JavaScript applications:

1. Getting and setting cookies

2. Redirecting requests

These abstractions provide a consistent API across the client and server by encapsulating environment-specific implementation details. Throughout Part II there have been numerous warnings about the dangers of abstraction, (including Coplien’s abstraction is evil). Given these warnings, and the fact that this entire chapter is about creating abstractions, let’s take a moment to discuss when and why to abstract.

When and Why to Use Abstraction

Abstraction is not really evil, but rather frequently misused, prematurely obfuscating important details that provide context to code. These misguided abstractions are usually rooted in a valiant effort to make people’s lives better. For example, a module that sets up project scaffolding is useful, but not if it hides details in submodules that cannot be easily inspected, extended, configured, or modified. It is this misuse that is often perceived as evil, and all abstraction is then labeled evil by association. However, if properly applied, abstraction is an invaluable design tool for helping to create an intuitive interface.

In my experience, I have used abstraction to normalize APIs across environments in cases where the environmental differences would have burdened the users with implementation details beyond what ...