About two years ago, Jeff Cross and I created an obscure open source project called deployd. A framework for rapidly building REST APIs for HTML5 and mobile apps. We didn’t realize it at the time, but it was our tiny contribution to kickstarting the “noBackend” movement. Our goal was to empower front end developers to become full stack JavaScript developers by closing the gap between client-side and server-side development.

In this post, we’ll go over how projects and services like deployd came to be, the issues they currently have and how they compare to LoopBack, a new open source project that attempts to solve these problems.


Almost all “noBackend” platforms depend heavily on MongoDB. Two features these platforms need are schemaless JSON storage and ad hoc or dynamic queries. This allows the backend to flex to the requirements and data provided by the client. Clients do not need to specify the data they want to store up front. They do not need to pre-define queries ahead of time or the relationships between tables. This gives the client and front end developer a lot of control.

MongoDB is built specifically to provide these two features. It was originally designed to back a platform similar to Google app engine.

“10gen launched as an open source platform-as-a-service play offering the MongoDB object database as well as an application server and file system”

Matthew Aslett, 2009

MongoDB is essentially a database designed for a backend service platform. It shouldn’t be much of a surprise that pretty much every notable platform depends on it:

Backend platforms using MongoDB

What is wrong with MongoDB?

Combined, the platforms above have hundreds of thousands if not millions of applications depending on MongoDB. So what is the issue? The issue is not MongoDB, as some would probably argue. Its using the wrong tool for the job. Even though MongoDB was designed for these type of backend platforms, it was not designed to support any type of application. Some applications require a relational schema, transactions, referential integrity, ACID compliance, and other features not available in MongoDB or other databases.

At StrongLoop we ran with this idea and created the open source project called LoopBack. We made sure to not have any dependencies on MongoDB from the beginning. We wanted to provide the same features you expect from a backend platform, while also having the option to choose which database best suites your requirements.

What makes LoopBack different?

It’s hard to build a noBackend platform that supports multiple databases. That’s most likely why most backend platforms only support MongoDB. LoopBack’s promise is that you can have all the benefits of a backend platform and also choose the database your application requires.

LoopBack was designed from the beginning to be suitable for any production environment. It allows you to choose how and where to run it. Your own local dev box, a cloud provider like Amazon, your own data center, continuous integration servers, heroku, etc.

Migrating to LoopBack

LoopBack supports a set of features that closely matches other backend platforms. Take a look at an example migrating from deployd to LoopBack. The same general process should apply to other platforms.


LoopBack has several advantages over other backend platforms. Being tightly coupled to MongoDB means you don’t have options. This makes it really difficult to integrate with existing systems. Since LoopBack supports similar features, migrating from a legacy backend platform is painless.

Next Steps

  • Install the StrongLoop command line tool
  • Check out some example LoopBack apps: 
    Access Control and FoodMe
  • Read the LoopBack docs
  • Get started with LoopBack
  • Check out the Project on GitHub