In the previous post I gave you an overview of why I’m spending my spare time developing in NodeJs. In this post I’m going to dive a little deeper and look at value objects and entities.

Isomorphic Value Objects

The idea of having for example a date object that is the same on the backend and the front end of an app with the same API is perfect for RAD development. Taking the great moment.js library:

moment().format('MMMM Do YYYY, h:mm:ss a');

This has some great benefits:

  1. No conversion of values passed between front and back-end
  2. 1 API to memorize
  3. Reduced code base size

Isomorphic Entities

Take a PHP app as an example with a Users model. On the backend you will have some form of ORM controlling it, with a custom method here and their formatting “full name”, “full address” etc. Then when the client needs it you pass a JSON version of its attributes to the client. You may (or may not) convert this to some form of JavaScript User model, or just access the attributes directly from the JSON object.

What happens to the “full name” custom property when the client updates the first name? Well you need to either do a post back to update the model and get a fresh copy, or replicate the same functionality in the JavaScript model you wrapped the raw data in. Usually the later is prefered which means your coding the same thing twice, and this is just a simple model property!

This to me also cries out for the Data Mapper Pattern over the standard Active Record setup. If we can decouple the models from the database and server for use across both that’s a huge step forward.

Why not just use the active record model on the server and browser?

No, No, No. This is where I don’t agree with certain NodeJs frameworks around right now. We should be able to share the model with the server and browser yes, but coupling the model with updates bi directionally to me just doesn’t provide enough separation of concerns and pollutes the browser with stuff it really doesn’t need leading to larger js requests and easier routes to coding badly. This is why in my initial post I referenced what most people coin “code reuse” not as a feature.

If used in the correct context yes its great, but its a doubled edged sword.

Here’s some example code:

NodeJs and WebSockets

My gripe about bi directional updates leads me nicely onto Websockets. A new-ish communication method that’s right at home in JavaScript. This is a real feature of NodeJs which isn’t so easy in PHP. Laravel does a great job and has a really nice interface for it with the event system and broadcasting, but it’s still a bit of a workaround which either needs you to manage a separate Node process and Redis, or buy into a paid SAAS service.

Incidentally I have a kind of polyfill package for Laravel which negates both those issues, it does so by use long polling and saving the events in the database for consumption, but it’s still a work around for something NodeJs offers pretty much “out of the box”.

The usage of Websockets is still in its early phases, and I don’t think anyone has it quite right yet.

Personally I don’t like the idea of application updates going through it, as REST is well-defined, cacheable, concise, scalable and doesn’t need bloated payloads to fetch response codes, content negotiation, etc.

But I can see it being useful for updating Flux stores, and sending notifications (pretty sure that’s what it was created for). How that end up looking is anyones guess, but I suspect there will be many options to choose from in the coming years of NodeJs development.