As you might know, MongoDB is a NoSQL database that provides high productivity and scalability. As other document-oriented databases, MongoDB was designed to address the challenges SQL databases aren’t able to cope with, including:

  • Large volumes of rapidly changing structured, semi-structured, and unstructured data;
  • Agile sprints, quick schema iteration, and frequent code pushes;
  • Object-oriented programming that is easy to use and flexible;
  • Geographically distributed scale-out architecture instead of expensive, monolithic architecture.

Now, there are plenty of flavors of NoSQL out there; Redi, Amazon DynamoDB, and CouchDB are great examples. But for this tutorial, I chose to focus on MongoDB, a high-performing and well-recognized open-source NoSQL option.

If you’re considering or already using MongoDB, you may need a fast way to build apps on top of it to read and write MongoDB documents. That’s what you’ll learn how to do in this article using the MongoDB connector available on the OutSystems Forge.

For the long version of this MongoDB connector tutorial, take a look at the video below where my colleague Andrew Duthie shows you step-by-step how to build an app on top of MondoDB. For the 3-minute version, keep on reading.

 

Building an App on Top of MongoDB with OutSystems

MongoDB allows you to build your data models in an agile fashion. OutSystems, on the other hand, helps you build mobile and web apps with speed.

These apps can be built on top of MongoDB and you can change them quickly to accommodate any changes happening on the underlying data structures in MongoDB. This way, by combining this noSQL database with OutSystems, you’re able to reap the speed and agility benefits of both.

So, how do you do that? By following this MongoDB connector tutorial.

Requirements

For this tutorial, you’ll need:

For this demo, I’ll show you how to build a directory app on top of MongoDB. Let’s get started!

Step 1: The Extension

Developers may deploy MongoDB databases as standalone web services using any number of REST libraries that provide full exposure to the underlying NoSQL database. Examples include Eve, RESTHeart, and Crest. For this exercise, I chose the C# Driver approach to demonstrate how to extend the OutSystems platform.

OutSystems extension manager 

The OutSystems extension manager allows you to create C# code and expose its methods to the platform. For this MongoDB extension, I needed some form of connection, collection management, and document CRUD & find. In Microsoft Visual Studio, I just needed to grab the MongoDB libraries and build a wrapper around them.

Microsoft Visual Studio MongoDB library

I published the extension and referenced my dependencies. Now, I was ready to start.

Step 2: The Core

Typically in these situations, we want to create some sort of abstraction layer. This core module implements a set of public methods that allow our applications to manage the database, the collection, and the documents therein. I’ve also included a set of private methods, DocumentHelpers, which hides some of the complexity.

DocumentHelpers

Step 3: My Demo Application

Using the module, we can define the database documents with standard OutSystems structures and data types. In this example, I’ve created a Person; document with a handful of attributes, one of which, Contacts, is a list of contact structures. This one-to-one data mapping allows us to work with MongoDB entries as if they were standard database elements, which reduces the learning curve significantly.

Structure Attribute

Step 4: Data Load

Being an OutSystems demo, it wouldn't be complete without a proper data load. I used an Excel file with people and their respective contact information stored in a tabular format. To populate the initial database, I created a Boot_DB method, which parses the data into JSON and then creates an entry in my MongoDB Person collection.

Creating entry to MongoDB Person collection

Step 5: List Screen

The next step was to build a typical list screen with OutSystems. I started by creating a local variable (Person list) that I populate during preparation and refresh on pagination. To recover each Person, I created PersonList, a generic method that accepts details like filter, sort, starting list index, and so on to help narrow the results and improve the user experience.

Creating PersonList method

Step 6: Edit Screen

For a typical edit screen, I needed another helper method that could locate a document by its identifier and serialize the output directly into an OutSystems structure. I also created respective delete and save methods. The save method (PersonCreateOrUpdate) pulls the document data from an OutSystems structure, serializes it into JSON, and sends it to MongoDB.

Pulling data from an OutSystems structure, serialize it into JSON, and send it to MongoDB

Step 7: Changing the Data Model

Changing the model is trivial thanks to the fact that NoSQL does not have a formal document structure. I added a date-time to the Person structure, and it did not break MongoDB. The database was perfectly happy to assign date-times to some documents, and nothing of the sort to the remainder. This leaves our applications responsible for updating and maintaining the document structure.

A quick note about dates: MongoDB treats dates internally as epoch unix time, so remember to configure your serialize accordingly.

Configure dates

See It in Action

I’ve published this demo and the MongoDB component in the OutSystems Forge. For more details, make sure you watch (and subscribe) our Decoded Labs series. In the first episode, my colleague Andrew Duthie put this component into action and built a self-service portal for employees to provide status of the equipment they’re using for working from home. Take a look!