Meteor, MEAN, and LAMP oh my

For the techies out there…
Meteor

Most of you are familiar with LAMP — Linux Apache MySql PHP.
Of more recent vintage is MEAN – MongoDB Express Angular Node.

Each represents a technology stack that focuses on a set of tools to deliver web applications. Some significant difference between the 2 stacks would be:

  • LAMP is focused on Linux as an operating system for the stack, (though WAMP would certainly be another option)
  • MEAN obviates the operating system and Apache by using Node as the built in web-server stack that doesn’t care about OS
  • MEAN also does away with separate programming languages for the front-end (JavaScript) and the back-end (PHP), and uses JavaScript everywhere
  • MEAN is focused on the single page app (SPA), while LAMP development “could” be done that way, it’s more traditional heritage is associated with a multi-page approach

Certainly, there are SPA’s being developed out there on LAMP with jQuery being a leading player in dynamic page loading from the server. But that’s not really my focus here. It’s really to point out this historical bridge from the multi-page oriented LAMP stack to the SPA approach of MEAN.

So where does Meteor fit in? Meteor is the realization of the SPA toolset into a complete package. Rather than putting the parts together in the MEAN stack, Meteor’s encapsulates everything into their framework. Here are the coolest things I like about using Meteor:

  • Full Stack Reactivity — no code needed to have pages auto-update themselves as underlying data in the database changes…very nice
  • Database Everywhere — A mini-Mongo database is maintained on the client with Collections that are tailored to that user. This is an important component leading to…
  • Latency Compensation — traditionally when a data change is made by the user, they must wait for the server conversation to take place before the page is “updated” with that change. Latency compensation allows that change to appear immediately (via the “database everywhere” component), and then confirmed (or backed out) when the server conversation is completed

You’ll find articles out there that pooh-pooh Meteor as a toy, or only useful for prototyping. But be sure to look at the dates on those posts. Meteor only went 1.0 this last Fall, and by that time, had built-in or resolved a lot of the things that people were concerned about.

As long-time developers in the NoSQL world, we (WFS) are quite familiar with the advantages and pitfalls of NoSQL development. As we progressively live in a post-Domino world, from a database perspective MongoDB (and CouchDB) hold a lot of attraction for those looking to move data from Lotus Domino databases. At this point, most of the easy migrations of applications to other platforms have occurred. A document library or discussion db easily maps to Sharepoint for example. What tends to be left over are the hard-core, business logic intensive, Lotus Notes applications.

Recently, I’ve been exposed to the platform the guys at LDC have put together with LDCVIA. It’s based on the MEAN stack. The focus of their tools (as I interpret it) is to migrate the data to MongoDb and provide the same security model to access the data via a web browser (via the MEAN stack). This would be valuable to many people, especially those looking to turn off the Domino servers and provide an archival type access to existing applications. Perhaps, it also serves as a gateway to re-developing app functionality for ongoing use within the MEAN stack. Certainly the guys at LDC are more than capable of producing those kinds of results…brilliant lot.

My interest has been more along the lines of reproducing the app capabilities (or tweaking them to current needs) via browser and mobile interface. From that perspective, the additional “glue” that Meteor provides out of the box is appealing. Currently we have a couple of projects underway that explore those capabilities. I’m looking forward to fleshing them out more fully, but at the moment, I’m very pleased with how it’s going. Some of the areas where I anticipated some difficulty (like Security) have proved to be a no-brainer. For those who only have a passing familiarity with Meteor, be sure to fully look at the publish/subscribe and allow/deny model for how Collections are handled.

In the near future, I’ll throw some Meteor examples out there to highlight some of the areas that excite me.