Integrating Meteor Applications with Legacy Software

There’s no doubt that this is the age of apps.  The two biggest vendors of mobile applications, Apple and Google Play, are showing an annualized consumer spending of around $25 billion, with some 75 billion apps downloaded over the past year.  Both of these major players have special channels set up to enable enterprise-scale downloads for businesses looking to take advantage of the app revolution.  Many of these businesses are opting to create custom apps, allowing for a more secure, personalized way for customers and employees alike to access the information they need to get the job, or sale, done.  A number of platforms are available for developing these apps, and we’ve worked with several of them.  One of our favorites is the Meteor platform for its easy integration with other platforms, its scalability, and its general ease of use.  

Why we like Meteor

Meteor has a number of benefits that we’ve found work well for our clients.  It’s a very intuitive platform that utilizes some predictive code packages that can help to eliminate thousands of lines of code and cut out hours of code-writing.  It also uses a single language (Javascript) across browsers, eliminating the need to create a whole new code set for every type of device clients or employees may be using.  This not only saves a ton of time, it makes updates and revisions much easier to deploy to all of an app’s users on all of their devices at once.

We also like Meteor ’s ability to integrate with other platforms.  Many of our clients have spent years, in some cases decades, building their systems with software like Lotus Notes and Active Directory.  Because Meteor uses a Distributed Data Protocol (DDP), integrating with these legacy systems is much more easily automated, saving even more development time and increasing efficiency.  

Helping Meteor communicate with other platforms

There are a couple of ways to connect apps built on Meteor with programs and information on existing platforms.  

DDP

Meteor’s DDP works sort of like the babel fish from Hitchhiker’s Guide to the Galaxy.

The first is to call into the Meteor application directly using the platform’s DDP and invoke Meteor’s own, fairly straightforward integration methods.  The DDP works sort of like the babel fish from Hitchhiker’s Guide to the Galaxy.  Once the fish is in the user’s ear, everything sounds like their native language, without the need for translation time, etc. With a DDP, when the Meteor client talks to Meteor servers, it doesn’t necessarily know that it’s specifically talking to a Meteor server, just that it’s speaking DDP, and the Meteor server doesn’t care that it’s talking to a Meteor client, for the same reason.  So a mobile client written, for example, in pure Objective C, with no Meteor code whatsoever, can connect to a Meteor server (say, by using the ObjectiveDDP library), and the server doesn’t see it (or listen to it) any differently than it would a Meteor client. Likewise, a pure Meteor client could call on DDP.connect to connect to a DDP service written in Java with no Meteor code.  Simply put, DDP just provides a standard set of names for the messages that most any websocket-using application would recognize.

For practical purposes, this is basically involves writing an API (Application Program Interface) in your Meteor application, and then using one of many DDP implementations  (Java, Javascript, C#, .NET, Python) to talk to that API.  This is especially useful in an integration (as opposed to a migration) scenario. Think about situations where you have a 3rd party system in which data is constantly changing and needs to be made available through a client-facing app.  With the Meteor DDP, you could set up a monitor process that triggers DDP calls to Meteor to automatically perform updates on the Meteor client data, making it available through the app.

MongoDB

The second approach is to bypass the Meteor client and enable your existing platform to talk directly to the MongoDB underlying the Meteor application.  For this, there are several MongoDB driver packages implemented in different languages that have been around for some time.  We’ll say more about this a little further down.

These approaches can be used in a huge variety of migration or integration scenarios with other applications and databases.  Here’s one.

A Lotus Notes example

For a recent legacy Lotus Notes/ Meteor application integration, we used a little of both methods mentioned above to provide a client with a solution that would enable customers to access information through a Meteor application while remaining outside the client’s firewall.   

IBM/Lotus Notes stores data records much like MongoDB (i.e. in a NOSQL like structure).  For the initial data migration, then, we wrote an IBM/Lotus Notes application with a Java agent that utilizes the MongoDB Java driver to connect the IBM Domino server where Lotus Notes lives directly to the MongoDB server that a customer-facing app could draw on.  For each Notes document, the integration code we wrote converts the data to a MongoDB document record that the Meteor app can read.  Having a long historical association with Notes, we were able to write an additional, stand-alone application that would choose what documents and fields to migrate, and then handle special cases for Reader, Author, Editor, Rich Text and file attachments.  As a bonus, that app can now be used for any Notes migration project.

Since the Notes application was for internal use only and was not being discontinued, we needed to maintain and mirror the data for the Meteor application, which served an external community.  For this, we utilized the DDP toolset.  With the two apps above, we could now monitor for document changes and trigger code.  For this last step, our code was again written in Java, but instead of interacting directly with Mongo, it now interacts with Meteor via DDP.  In the underlying MongoDB documents created with the first app, a UNID property was maintained from Notes, providing a key for the Meteor DDP to look up and update any data that has changed in the Notes document.  It can then mirror those changes in the outward-facing app.

Another approach would have been to use Web Services, either REST or SOAP, within Meteor (there is a nice SOAP package for Meteor  that we’ve tested, and it works well).  However, our architecture requirement for this specific project was to have Notes inside the firewall and the Meteor app in a DMZ so that Meteor wouldn’t be allowed to reach inside the network, as it would have had to with a SOAP client.  Consequently, monitoring for changes inside the network and using DDP to push updated data out to the DMZ seemed like the way to go.

Some combination of these approaches can be used to take advantage of the modern, easy-to-use Meteor platform while maintaining data in any number of legacy systems.  At Workflow, we specialize in integrations and migrations with IBM and Microsoft software, so we’re fortunate to have a lot of the code on hand to make the integration that much easier.  

Have a Meteor integration project?    Give us a call at 214.660.5353.  We’d love to help.