Alex Bevilacqua

Product Manager, Developer Experience

Though developers have always been capable of manually writing complex queries to interact with a database, this approach can be tedious and error-prone. [Object-Relational Mappers](https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping) (or ORMs) improve the developer experience, as they accomplish multiple meaningful tasks:

* Facilitating interactions between the database and an application by abstracting away the need to write raw SQL or database query language.
* Managing serialization/deserialization of data to objects.
* Enforcement of schema.

So, while it’s true that MongoDB offers [Drivers](https://www.mongodb.com/pt-br/docs/drivers/) with idiomatic APIs and helpers for most  programming languages, sometimes a higher level abstraction is desirable. Developers are used to interacting with data in a more declarative fashion (LINQ for C#, ActiveRecord for Ruby, etc.) and an ORM facilitates code maintainability and reuse by allowing developers to interact with data as objects.

MongoDB provides a number of ORM-like libraries, and our [community](https://www.mongodb.com/pt-br/docs/drivers/community-supported-drivers/) and partners have as well! These are sometimes referred to as ODMs (Object Document Mappers), as MongoDB is not a relational database management system. However, they exist to solve the same problem as ORMs do and the terminology can be used interchangeably.

The following are some examples of the best MongoDB ORM or ODM libraries for a number of programming languages, including Ruby, Python, Java, Node.js, and PHP.

## Beanie

Beanie is an Asynchronous Python object-document mapper (ODM) for MongoDB, based on [Motor](https://www.mongodb.com/pt-br/docs/drivers/motor/) (an asynchronous MongoDB driver) and [Pydantic](https://pydantic-docs.helpmanual.io/).

When using Beanie, each database collection has a corresponding document that is used to interact with that collection. In addition to retrieving data, Beanie allows you to add, update, and delete documents from the collection. Beanie saves you time by removing boilerplate code, and it helps you focus on the parts of your app that actually matter.

See the [Beanie documentation](https://beanie-odm.dev/) for more information.

## Doctrine

Doctrine is a PHP MongoDB ORM, even though it’s referred to as an ODM. This library provides PHP object mapping functionality and transparent persistence for PHP objects to MongoDB, as well as a mechanism to map embedded or referenced documents. It can also create references between PHP documents in different databases and work with GridFS buckets.

See the [Doctrine MongoDB ODM documentation](https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/latest/index.html) for more information.

## Mongoid

Most Ruby-based applications are built using the [Ruby on Rails](https://rubyonrails.org/) framework. As a result, Rails’ [Active Record](https://guides.rubyonrails.org/active_record_basics.html) implementation, conventions, CRUD API, and callback mechanisms are second nature to Ruby developers. So, as far as a MongoDB ORM for Ruby, the Mongoid ODM provides API parity wherever possible to ensure developers working with a Rails application and using MongoDB can do so using methods and mechanics they’re already familiar with.

See the [Mongoid documentation](https://www.mongodb.com/pt-br/docs/mongoid/current/) for more information.

## Mongoose

If you’re seeking an ORM for NodeJS and MongoDB, look no further than Mongoose. This Node.js-based Object Data Modeling (ODM) library for MongoDB is akin to an Object Relational Mapper (ORM) such as [SQLAlchemy](https://www.sqlalchemy.org/). The problem that Mongoose aims to solve is allowing developers to enforce a specific schema at the application layer. In addition to enforcing a schema, Mongoose also offers a variety of hooks, model validation, and other features aimed at making it easier to work with MongoDB.

See the [Mongoose documentation](https://mongoosejs.com/) or [MongoDB & Mongoose: Compatibility and Comparison](https://www.mongodb.com/pt-br/developer/languages/javascript/mongoose-versus-nodejs-driver/) for more information.

## MongoEngine

MongoEngine is a Python ORM for MongoDB. Branded as a Document-Object Mapper, it uses a simple declarative API, similar to the Django ORM.

It was first released in 2015 as an open-source project, and the current version is built on top of [PyMongo](https://www.mongodb.com/pt-br/docs/drivers/pymongo/), the official Python Driver by MongoDB.

See the [MongoEngine documentation](http://mongoengine.org/) for more information.

## Prisma

Prisma is a [new kind of ORM](https://www.prisma.io/docs/concepts/overview/prisma-in-your-stack/is-prisma-an-orm) for Node.js and Typescript that fundamentally differs from traditional ORMs. With Prisma, you define your models in the declarative [Prisma schema](https://www.prisma.io/docs/concepts/components/prisma-schema), which serves as the single source of truth for your database schema and the models in your programming language. The Prisma Client will read and write data to your database in a type-safe manner, without the overhead of managing complex model instances. This makes the process of querying data a lot more natural as well as more predictable since Prisma Client always returns plain JavaScript objects.

Support for MongoDB was one of the most requested features since the initial release of the Prisma ORM, and was added in version 3.12.

See [Prisma & MongoDB](https://www.prisma.io/mongodb) for more information.

## Spring Data MongoDB

If you’re seeking a Java ORM for MongoDB, Spring Data for MongoDB is the most popular choice for Java developers. The [Spring Data](https://spring.io/projects/spring-data) project provides a familiar and consistent Spring-based programming model for new datastores while retaining store-specific features and capabilities.

Key functional areas of Spring Data MongoDB that Java developers will benefit from are a POJO centric model for interacting with a MongoDB DBCollection and easily writing a repository-style data access layer.

See the [Spring Data MongoDB documentation](https://spring.io/projects/spring-data-mongodb) or the [Spring Boot Integration with MongoDB Tutorial](https://www.mongodb.com/compatibility/spring-boot) for more information.

## Go Build Something Awesome!

Though not an exhaustive list of the available MongoDB ORM and ODM libraries available right now, the entries above should allow you to get started using MongoDB in your language of choice more naturally and efficiently.

If you’re looking for assistance or have any feedback don’t hesitate to engage on our [Community Forums](https://www.mongodb.com/community/forums/).

MongoDB has ORMs, ODMs, and Libraries to simplify interactions between your app and cluster. Use the best database for Ruby, Python, Java, Node.js, PHP.

MongoDB ORMs, ODMs, and Libraries

[TableCheck](https://tablecheck.com/) is the world’s premiere booking and guest platform. Headquartered in Tokyo, they empower restaurants with tools to elevate their guest experience and create guests for life with features like booking forms, surveys, marketing automation tools and an ecosystem of powerful solutions for restaurants to take their business forward.

## Architectural overview of TableCheck

Launched in 2013, TableCheck began life as a [Ruby on Rails](https://rubyonrails.org/) monolith. Over time, the solution has been expanded to include satellite microservices. However, one constant that has remained throughout this journey was MongoDB.

Originally, TableCheck managed their own MongoDB Enterprise clusters. However, once MongoDB Atlas became available, they migrated their data to a managed replica set running in AWS.

According to CTO Johnny Shields, MongoDB was selected initially as the database of choice for TableCheck as it was _"love at first sight"_. Though MongoDB was a much different solution in 2013, even in the database product’s infancy, it fit perfectly with their development workflow and allowed them to work with their data easily and quickly while building out their APIs and application.

## Ruby on Rails + MongoDB

Any developer familiar with Ruby on Rails knows that the [ORM](https://en.wikipedia.org/wiki/Object-relational_mapping) layer (via [Active Record](https://guides.rubyonrails.org/active_record_basics.html)) was designed to support relational databases. MongoDB’s [Mongoid ODM](https://www.mongodb.com/pt-br/docs/mongoid/current/) acts as a veritable "drop-in" replacement for existing Active Record adapters so that MongoDB can be used seamlessly with Rails. The CRUD API is familiar to Ruby on Rails developers and makes working with MongoDB extremely easy.

When asked if MongoDB and Ruby were a good fit, Johnny Shields replied:
> _"Yes, I’d add the combo of MongoDB + Ruby + Rails + Mongoid is a match made in heaven. Particularly with the Mongoid ORM library, it is easy to get MongoDB data represented in native Ruby data structures, e.g. as nested arrays and objects"._

This has allowed TableCheck to ensure MongoDB remains the "golden-source" of data for the entire platform. They currently replicate a subset of data to Elasticsearch for deep multi-field search functionality. However, given the rising popularity and utility of [Atlas Search](https://www.mongodb.com/pt-br/docs/atlas/atlas-search/), this part of the stack may be further simplified.
 
As MongoDB data changes within the TableCheck platform, these changes are broadcast over [Apache Kafka](https://kafka.apache.org/) via the [MongoDB Kafka Connector](https://www.mongodb.com/pt-br/docs/kafka-connector/current/) to enable downstream services to consume it. Several of their microservices are built in [Elixir](https://elixir-lang.org/), including a data analytics application. PostgreSQL is being used for these data analytics use cases as the only MongoDB Drivers for Elixir and managed by the community (such as [`elixir-mongo/mongodb`](https://github.com/elixir-mongo/mongodb) or [`zookzook/elixir-mongodb-driver`](https://github.com/zookzook/elixir-mongodb-driver)). However, should an official Driver surface, this decision may change.

## Benefits of the Mongoid ODM for Ruby on Rails development

The "killer feature" for new users discovering Ruby on Rails is [Active Record Migrations](https://guides.rubyonrails.org/active_record_migrations.html). This feature of Active Record provides a DSL that enables developers to manage their relational database’s schema without having to write a single line of SQL. Because MongoDB is a NoSQL database, migrations and schema management are unnecessary!

Johnny Shields shares the following based on his experience working with MongoDB and Ruby on Rails:
> _"You can add or remove data fields without any need to migrate your database. This alone is a "killer-feature" reason to choose MongoDB. You do still need to consider database indexes however, but MongoDB Atlas has a profiler which will monitor for slow queries and auto-suggest if any index is needed."_

As the Mongoid ODM supports large portions of the Active Record API, another powerful productivity feature TableCheck was able to leverage is the use of [Associations](https://www.mongodb.com/pt-br/docs/mongoid/current/reference/associations/). Cross-collection referenced associations are available. However, unlike relational databases, [embedded associations](https://www.mongodb.com/pt-br/docs/mongoid/current/reference/associations/#embedded-associations) can be used to simplify the data model.

## Open source and community strong

Both [`mongodb/mongoid`](https://github.com/mongodb/mongoid) and [`mongodb/mongo-ruby-driver`](https://github.com/mongodb/mongo-ruby-driver) are licensed under OSI approved licenses and MongoDB encourages the community to contribute feedback, issues, and pull requests!

Since 2013, the TableCheck team has contributed nearly 150 PRs to both projects. The majority tend to be quality-of-life improvements and bug fixes related to edge-case combinations of various methods/options. They’ve also helped improve the accuracy of documentation in many places, and have even helped the MongoDB Ruby team setup Github Actions so that it would be easier for outsiders to contribute. 

With so many contributions under their team’s belt, and clearly able to extend the Driver and ODM to fit any use case the MongoDB team may not have envisioned, when asked if there were any use-cases MongoDB couldn’t satisfy within a Ruby on Rails application, the feedback was:
> _"I have not encountered any use case where I’ve felt SQL would be a fundamentally better solution than MongoDB. On the contrary, we have several microservices which we’ve started in SQL and are moving to MongoDB now wherever we can."_

The TableCheck team are vocal advocates for things like better changelogs and more discipline in following semantic versioning best practices. These have benefited the community greatly, and Johnny and team continue to advocate for things like adopting static code analysis (ex: via [Rubocop](https://github.com/rubocop/rubocop)) to improve overall code quality and consistency.

## Overall thoughts on working with MongoDB and Ruby on Rails

TableCheck has been a long-time user of MongoDB via the Ruby driver and Mongoid ODM, and as a result has experienced some growing pains as the data platform matured. When asked about any challenges his team faced working with MongoDB over the years, Johnny replied: 
> _"The biggest challenge was that in earlier MongoDB versions (3.x) there were a few random deadlock-type bugs in the server that bit us. These seemed to have gone away in newer versions (4.0+). MongoDB has clearly made an investment in core stability which we have benefitted from first-hand. Early on we were maintaining our own cluster, and from a few years ago we moved to Atlas and MongoDB now does much of the maintenance for us"._

We at MongoDB continue to be impressed by the scope and scale of the solutions our users and customers like TableCheck continue to build. Ruby on Rails continues to be a viable framework for enterprise and best-in-class applications, and our team will continue to grow the product to meet the needs of the next generation of Ruby application developers.

Johnny presented at [MongoDB Day Singapore](https://www.mongodb.com/events/mongodb-days-apac-2022/singapore) on November 23, 2022 ([view presentation](https://vimeo.com/780220683)). His talk covered a number of topics, including his experiences working with MongoDB and Ruby.

TableCheck's CTO Johnny Shields shares their experience with the MongoDB Ruby ODM (mongoid) and how they streamline their development processes.

TableCheck: Empowering Restaurants With Best-in-Class Booking Tools Powered by MongoDB

Before discovering Ruby and Ruby on Rails, I was a .NET developer. At that time, I'd make ad-hoc changes to my development database, export my table/function/stored procedure/view definitions to text files, and check them into source control with any code changes. Using `diff` functionality, I'd compare the schema changes that the DBAs needed to apply to production and we'd script that out separately.

I'm sure better tools existed (and I eventually started using some of [RedGate's tools](https://www.red-gate.com/solutions/role/development)), but I was looking for a change. At that time, the real magic of Ruby on Rails for me was the [Active Record Migrations](https://guides.rubyonrails.org/active_record_migrations.html) which made working with my database fit with my programming workflow. Schema management became less of a chore and there were `rake` tasks for anything I needed (applying migrations, rolling back changes, seeding a test database).

Schema versioning and management with Rails was leaps and bounds better than what I was used to, and I didn't think this could get any better — but then I found MongoDB. 

When working with MongoDB, there's no need to `CREATE TABLE foo (id integer, bar varchar(255), ...)`; if a collection (or associated database) doesn't exist, inserting a new document will automatically create it for you. This means Active Record migrations are no longer needed as this level of schema change management was no longer necessary.
 
Having the flexibility to define my data model directly within the code without needing to resort to the intermediary management that Active Record had facilitated just sort of made sense to me. I could now persist object state to my database directly, embed related model details, and easily form queries around these structures to quickly retrieve my data.

## Flexible schema

Data in MongoDB has a flexible schema as [collections](https://www.mongodb.com/pt-br/docs/manual/reference/glossary/#std-term-collection) do not enforce a strict [document](https://www.mongodb.com/pt-br/docs/manual/reference/glossary/#std-term-document) structure or schema by default. This flexibility gives you data-modeling choices to match your application and its performance requirements, which aligns perfectly with Ruby's focus on simplicity and productivity.

## Let's try it out

We can easily demonstrate how to quickly get started using the [MongoDB Ruby Driver](https://www.mongodb.com/pt-br/docs/ruby-driver/master/) using the following simple Ruby script that will connect to a cluster, insert a document, and read it back:
 
```ruby
require 'bundler/inline'
 
gemfile do
  source 'https://rubygems.org'
  gem 'mongo'
end
 
client = Mongo::Client.new('mongodb+srv://username:password@mycluster.mongodb.net/test')
collection = client[:foo]
collection.insert_one({ bar: "baz" })
 
puts collection.find.first 
# => {"_id"=>BSON::ObjectId('62d83d9dceb023b20aff228a'), "bar"=>"baz"}
```
 
When the document above is inserted, an `_id` value of `BSON::ObjectId('62d83d9dceb023b20aff228a')` is created. All documents must have an [`_id` field](https://www.mongodb.com/pt-br/docs/manual/core/document/#the-_id-field). However, if not provided, a default `_id` of type [`ObjectId`](https://www.mongodb.com/pt-br/docs/manual/reference/bson-types/#std-label-objectid) will be generated. When running the above, you will get a different value for `_id`, or you may choose to explicitly set it to any value you like!
 
Feel free to give the above example a spin using your existing MongoDB cluster or [MongoDB Atlas](https://www.mongodb.com/atlas) cluster. If you don't have a MongoDB Atlas cluster, [sign up for an always free tier](https://www.mongodb.com/cloud/atlas/signup) cluster to get started.
 
## Installation
 
The MongoDB Ruby Driver is hosted at [RubyGems](https://rubygems.org/gems/mongo), or if you'd like to explore the source code, it can be found on [GitHub](https://github.com/mongodb/mongo-ruby-driver).
 
To simplify the example above, we used `bundler/inline` to provide a [single-file solution using Bundler](https://bundler.io/guides/bundler_in_a_single_file_ruby_script.html). However, the `mongo` gem can be just as easily added to an existing `Gemfile` or installed via [`gem install mongo`](https://guides.rubygems.org/rubygems-basics/#installing-gems).
 
## Basic CRUD operations
 
Our sample above demonstrated how to quickly create and read a document. Updating and deleting documents are just as painless as shown below:
 
```ruby
# set a new field 'counter' to 1
collection.update_one({ _id: BSON::ObjectId('62d83d9dceb023b20aff228a')}, :"$set" => { counter: 1 })
 
puts collection.find.first 
# => {"_id"=>BSON::ObjectId('62d83d9dceb023b20aff228a'), "bar"=>"baz", "counter"=>1}
 
# increment the field 'counter' by one
collection.update_one({ _id: BSON::ObjectId('62d83d9dceb023b20aff228a')}, :"$inc" => { counter: 1 })
 
puts collection.find.first 
# => {"_id"=>BSON::ObjectId('62d83d9dceb023b20aff228a'), "bar"=>"baz", "counter"=>2}
 
# remove the test document
collection.delete_one({ _id: BSON::ObjectId('62d83d9dceb023b20aff228a') })
```
 
## Object document mapper
 
Though all interaction with your Atlas cluster can be done directly using the MongoDB Ruby Driver, most developers prefer a layer of abstraction such as an [ORM or ODM](https://medium.com/spidernitt/orm-and-odm-a-brief-introduction-369046ec57eb). Ruby developers can use the [Mongoid ODM](https://www.mongodb.com/pt-br/docs/mongoid/current/) to easily model MongoDB collections in their code and simplify interaction using a fluid API akin to [Active Record's Query Interface](https://guides.rubyonrails.org/active_record_querying.html).
 
The following example adapts the previous example to use Mongoid:
```ruby
require 'bundler/inline'
 
gemfile do
  source 'https://rubygems.org'
 
  gem 'mongoid'
end
 
Mongoid.configure do |config|
  config.clients.default = { uri: "mongodb+srv://username:password@mycluster.mongodb.net/test" }
end
 
class Foo
  include Mongoid::Document
 
  field :bar, type: String
  field :counter, type: Integer, default: 1
end
 
# create a new instance of 'Foo', which will assign a default value of 1 to the 'counter' field
foo = Foo.create bar: "baz"
 
puts foo.inspect 
# => <Foo _id: 62d84be3ceb023b76a48df90, bar: "baz", counter: 1>
 
# interact with the instance variable 'foo' and modify fields programmatically
foo.counter += 1
 
# save the instance of the model, persisting changes back to MongoDB
foo.save!
 
puts foo.inspect 
# => <Foo _id: 62d84be3ceb023b76a48df90, bar: "baz", counter: 2>
```
 
## Summary
 
Whether you're using Ruby/Rails to build a script/automation tool, a new web application, or even the next [Coinbase](https://blog.coinbase.com/scaling-connections-with-ruby-and-mongodb-99204dbf8857), MongoDB has you covered with both a Driver that simplifies interaction with your data or an ODM that seamlessly integrates your data model with your application code.
 
## Conclusion

Interacting with your MongoDB data via Ruby — either using the Driver or the ODM — is straightforward, but you can also directly interface with your data from MongoDB Atlas using the built in [Data Explorer](https://www.mongodb.com/pt-br/docs/atlas/atlas-ui/). Depending on your preferences though, there are options:
 
* [MongoDB for Visual Studio Code](https://www.mongodb.com/products/vs-code) allows you to connect to your MongoDB instance and enables you to interact in a way that fits into your native workflow and development tools. You can navigate and browse your MongoDB databases and collections, and prototype queries and aggregations for use in your applications.

* [MongoDB Compass](https://www.mongodb.com/products/compass) is an interactive tool for querying, optimizing, and analyzing your MongoDB data. Get key insights, drag and drop to build pipelines, and more.

* [Studio 3T](https://studio3t.com/) is an extremely easy to use 3rd party GUI for interacting with your MongoDB data.

* [MongoDB Atlas Data API](https://www.mongodb.com/pt-br/docs/atlas/api/data-api/) lets you read and write data in Atlas with standard HTTPS requests. To use the Data API, all you need is an HTTPS client and a valid API key.
  
Ruby was recently added as a [language export option to both MongoDB Compass and the MongoDB VS Code Extension](https://www.mongodb.com/blog/post/ruby-added-mongodb-export-language-compass-vs-code). Using this integration you can easily convert an [aggregation pipeline](https://www.mongodb.com/pt-br/docs/manual/core/aggregation-pipeline/) from either tool into code you can copy/paste into your Ruby application.

Find out what makes MongoDB a great fit for your next Ruby on Rails application! 

Alex Bevilacqua

Conteúdo de Alex Bevilacqua

ORMs, ODMs e bibliotecas do MongoDB

TableCheck: restaurantes habilitados com as melhores ferramentas de reserva da classe, desenvolvido pela MongoDB

Por que usar o MongoDB com Ruby?