✅ Sign-up for a free cluster at: <a href="https://mdb.link/free-_jDKeOtOiEo" target="_blank" rel="noreferrer">https://mdb.link/free-_jDKeOtOiEo</a>
✅ Get help on our Community Forums: <a href="https://mdb.link/community-_jDKeOtOiEo" target="_blank" rel="noreferrer">https://mdb.link/community-_jDKeOtOiEo</a>

Learn how to write unit tests in Rust with this hands-on video that covers these five topics with examples and real code:

-  The basic types of unit tests
-  The quality of the testing code
-  Testing the not-so-happy-path
-  Testing asynchronous code
-  Testing tools

You can find the code used and produced in this video in the following repo: <a href="https://trymongodb.com/3W6npjj" target="_blank" rel="noreferrer">https://trymongodb.com/3W6npjj</a>

Connect with Jorge:
Twitter: <a href="https://twitter.com/jdortiz" target="_blank" rel="noreferrer">https://twitter.com/jdortiz</a>
Mastodon: <a href="https://fosstodon.org/@jdortiz" target="_blank" rel="noreferrer">https://fosstodon.org/@jdortiz</a>
LinkedIn: <a href="https://www.linkedin.com/in/jorgeortiz/" target="_blank" rel="noreferrer">https://www.linkedin.com/in/jorgeortiz/</a>

⏱️ Timestamps ⏱️
﻿00:00:00 - Intro﻿
00:01:25 - Basic concepts
00:04:43 - Project creation
00:08:38 - Tests module
00:10:24 - Rust snippets for tests
00:14:21 - First unit test return value
00:24:03 - Second unit test state
00:28:46 - Alternative implementation tested
00:32:44 - Third unit test interaction
00:46:50 - Recommended implementation
00:49:09 - Test code quality
00:49:34 - Use constants for literals
00:54:18 - Reduce repetition with setup and teardown
01:08:57 - Share code among test modules
01:13:05 - Why testing the not so happy path
01:13:32 - Test panics
01:18:03 - Use ignore and test results
01:28:02 - Bubble up errors in tests
01:30:34 - Asynchronous code in Rust
01:31:01 - Async tests
01:38:19 - Beyond cargo test 
01:38:46 - rustdoc and doc-tests
01:48:00 - Show test output
01:49:33 - Selecting tests
01:55:55 - Test coverage
02:01:08 - Nextest
02:05:54 - Outro

—
Subscribe to MongoDB ➡️ <a href="https://bit.ly/3bpg1Z1" target="_blank" rel="noreferrer">https://bit.ly/3bpg1Z1</a>

#mongodb #rust #rustunittesting

Rust

Everything You Wanted to Know About Rust Unit Testing (and then some more)

Mark Smith

Senior Developer Advocate

Query, group, and join data in MongoDB using aggregation pipelines with Rust.

Getting Started with Aggregation Pipelines in Rust

Jorge D. Ortiz-Fuentes

Mobile Developer Advocate

Learn to write firmware of a noise sensor with an ESP32 from scratch using Rust. We use the neopixel to inform the user about the status of the device.

Red Mosquitto: Implement a Noise Sensor With an MQTT Client in an ESP32

Rachelle Palmer

Product Lead, Developer Experience

## Description of Application
A quick and easy example application project that creates a demo blog post engine. Very simple UI, ideal for beginners to Rust programming langauge.

##  Technology Stack
This code example utilizes the following technologies:

* MongoDB Atlas
* Rust
* Rocket.rs framework



Check out this quick and easy example application project that creates a demo blog post engine. It's ideal for beginners to the Rust programming language.

Beginner Coding Project: Build a Blog Engine With Rust and MongoDB

So, you've decided to write a Rust application with MongoDB, and you're wondering which of the top web development frameworks to use. Below, we give some suggestions and resources for how to:

1. Use MongoDB with Actix and Rust.
2. Use MongoDB with Rocket.rs and Rust.

The TLDR is that you can use any of the popular Rust frameworks with MongoDB, and we have code examples, tutorials, and other resources to guide you.

### Building MongoDB Rust apps with Actix

[Actix](https://github.com/actix/actix-web) is a powerful and performant web framework for building Rust applications with MongoDB, with a long list of supported features. 

You can [find a working example](https://github.com/actix/examples/tree/master/databases/mongodb) of using MongoDB with Actix in the `databases` directory under Actix's github, but otherwise, if you're looking to build a REST API with Rust and MongoDB, using Actix along the way, [this tutorial](https://dev.to/hackmamba/build-a-rest-api-with-rust-and-mongodb-actix-web-version-ei1) is one of the better ones we've seen.

### Building MongoDB Rust apps with Rocket.rs

Prefer [Rocket](https://rocket.rs/)? Rocket is a fast, secure, and type safe framework that is low on boilerplate. It's easy to build Rust applications with MongoDB and Rocket. There's a [tutorial on Medium we particularly like](https://medium.com/geekculture/build-a-rest-api-with-rust-and-mongodb-rocket-version-7ea90ebd9fe7) on building a REST API with Rust, MongoDB, and Rocket. 

Next, [see a code example on GitHub](https://github.com/TaeyoonKwon/rust-rocket-sample).

Which Rust frameworks work best with MongoDB? Learn how to use Actix or Rocket.rs Rust frameworks with MongoDB.

Using MongoDB With Rust Web Development Framework

Community

Jacob Latonis

Senior Software Engineer, Threat Research @ Proofpoint

A tutorial on how to write a REST API using Rust and Rocket and the MongoDB driver.

Writing an API With MongoDB in Rust

Isabel Atkinson

Software Engineer

## Introduction

This post details new upgrades in the [Rust MongoDB Driver](https://docs.mongodb.com/drivers/rust/) and BSON library to improve our integration with Serde. In the [Rust Quick Start blog post](https://developer.mongodb.com/quickstart/rust-crud-tutorial), we discussed the trickiness of working with BSON, which has a dynamic schema, in Rust, which uses a static type system. The MongoDB Rust driver and BSON library use [Serde](https://serde.rs/) to make the conversion between BSON and Rust structs and enums easier. In the 1.2.0 releases of these two libraries, we've included new Serde integration to make working directly with your own Rust data types more seamless and user-friendly.

## Prerequisites

This post assumes that you have a recent version of the Rust toolchain installed (v1.44+), and that you're comfortable with Rust syntax. It also assumes you're familiar with the Rust [Serde](https://serde.rs/) library.

## Driver Changes

The 1.2.0 Rust driver release introduces a generic type parameter to the [Collection](https://docs.rs/mongodb/1.2.0/mongodb/struct.Collection.html) type. The generic parameter represents the type of data you want to insert into and find from your MongoDB collection. Any Rust data type that derives/implements the Serde [Serialize and Deserialize traits](https://serde.rs/custom-serialization.html) can be used as a type parameter for a Collection.

For example, I'm working with the following struct that defines the schema of the data in my `students` collection:

``` rust
#[derive(Serialize, Deserialize)]
struct Student {
    name: String,
    grade: u32,
    test_scores: Vec<u32>,
}
```

I can create a generic `Collection` by using the [Database::collection_with_type](https://docs.rs/mongodb/1.2.0/mongodb/struct.Database.html#method.collection_with_type) method and specifying `Student` as the data type I'm working with.

``` rust
let students: Collection<Student> = db.collection_with_type("students");
```

Prior to the introduction of the generic `Collection`, the various CRUD `Collection` methods accepted and returned the [Document](https://docs.rs/bson/1.2.0/bson/document/struct.Document.html) type. This meant I would need to serialize my `Student` structs to `Document`s before inserting them into the students collection. Now, I can insert a `Student` directly into my collection:

``` rust
let student = Student {
    name: "Emily".to_string(),
    grade: 10,
    test_scores: vec![98, 87, 100],
};
let result = students.insert_one(student, None).await;
```

I can also find a Student directly from my `Collection`:

``` rust
// student is of type Student
let student = students.find_one(doc! { "name": "Emily" }, None).await?;
```

I may decide that I want to insert a different type of data into the `students` collection at some point. Although my `students` collection is restricted to the `Student` data type, I can easily create a clone of the `students` collection with a new type parameter:

``` rust
let students: Collection<CollegeStudent> = students.clone_with_type();
```

The default generic type for `Collection` is `Document`. This means that any `Collection` created without a generic type will continue to find and return the `Document` type, and any existing code that uses `Collection` will be unaffected by these changes.

## BSON Changes

The 1.2.0 release also includes changes to the Rust BSON library that improve usability when working with Serde.

### Serde Helper Functions

Sometimes you may want to serialize or deserialize data in your structs or enums differently than the default behavior. Serde provides [serialize_with](https://serde.rs/field-attrs.html#serialize_with) and [deserialize_with](https://serde.rs/field-attrs.html#deserialize_with) attributes that allow you to specify functions to use for serialization and deserialization on specific fields and variants.

The BSON library now includes a set of functions that implement common strategies for custom serialization and deserialization when working with BSON. You can use these functions by importing them from the `serde_helpers` module in the `bson-rust` crate and using the `serialize_with` and `deserialize_with` attributes. A few of these functions are detailed below.

Some users prefer to represent the object ID field in their data with a hexidecimal string rather than the BSON library [ObjectId](https://docs.rs/bson/1.2.0/bson/oid/struct.ObjectId.html) type:

``` rust
#[derive(Serialize, Deserialize)]
    struct Item {
    oid: String,
    // rest of fields
}
```

We've introduced a method for serializing a hex string into an `ObjectId` in the `serde_helpers` module called `serialize_hex_string_as_object_id`. I can annotate my `oid` field with this function using `serialize_with`:

``` rust
#[derive(Serialize, Deserialize)]
struct Item {
    #[serde(serialize_with = "serialize_hex_string_as_object_id")]
    oid: String,
    // rest of fields
}
```

Now, if I serialize an instance of the `Item` struct into BSON, the `oid` field will be represented by an `ObjectId` rather than a `string`.

We've also introduced modules that take care of both serialization and deserialization. For instance, I might want to represent binary data using the [Uuid](https://docs.rs/uuid/0.5.1/uuid/struct.Uuid.html) type in the Rust [uuid](https://docs.rs/uuid/0.5.1/uuid/index.html) crate:

``` rust
#[derive(Serialize, Deserialize)]
struct Item {
    uuid: Uuid,
    // rest of fields
}
```

Since BSON doesn't have a specific UUID type, I'll need to convert this data into binary if I want to serialize into BSON. I'll also want to convert back to Uuid when deserializing from BSON. The `uuid_as_binary` module in the `serde_helpers` module can take care of both of these conversions. I'll add the following attribute to use this module:

``` rust
#[derive(Serialize, Deserialize)]
struct Item {
    #[serde(with = "uuid_as_binary")]
    uuid: Uuid,
    // rest of fields
}
```

Now, I can work directly with the Uuid type without needing to worry about how to convert it to and from BSON!

The `serde_helpers` module introduces functions for several other common strategies; you can check out the documentation [here](https://docs.rs/bson/1.2.0/bson/serde_helpers/index.html).

### Unsigned Integers

The BSON specification defines two integer types: a signed 32 bit integer and a signed 64 bit integer. This can prevent challenges when you attempt to insert data with unsigned integers into your collections.

My `Student` struct from the previous example contains unsigned integers in the `grade `and `test_score` fields. Previous versions of the BSON library would return an error if I attempted to serialize an instance of this struct into `Document`, since there isn't always a clear mapping between unsigned and signed integer types. However, many unsigned integers can fit into signed types! For example, I might want to create the following student:

``` rust
let student = Student {
    name: "Alyson".to_string(),
    grade: 11,
    test_scores: vec![89, 92, 99],
};
```

While the numbers in the `grade` and `test_scores` fields are technically unsigned 32 bit integers, they can be converted to signed 32 bit integers without losing any data.

The 1.2.0 release of the BSON library no longer returns an error when attempting to serialize unsigned integers into BSON, and instead tries to perform a lossless conversion into one of the signed integer BSON types. If the unsigned integer cannot be converted to a signed 32 bit or 64 bit integer, serialization will still return an error.

Now, I can convert my student struct into a `Document`:

``` rust
let doc = to_document(&student)?;
```

I can use `println!` to see the following `Document` is returned:

``` rust
Document({
    "name": String("Alyson"),
    "grade": Int32(11),
    "test_scores": Array([Int32(89), Int32(92), Int32(99)])
})
```

## Conclusion

Serde is a powerful tool that provides lots of functionality for customizing the way you convert between different data formats. In the 1.2.0 releases of the Rust driver and BSON library, we've made it even easier to work directly with your Rust data types. If you're interested in more complex mapping capabilities, it's worth reading the Serde documentation on [attributes](https://serde.rs/attributes.html). For more details on working with MongoDB in Rust, you can check out the documentation for the [Rust driver](https://docs.rs/mongodb/1.2.0/mongodb/) and [BSON library](https://docs.rs/bson/1.2.0/bson/enum.Bson.html). We also happily accept contributions in the form of Github pull requests - please see the section in our [README](https://github.com/mongodb/mongo-rust-driver#contributing) for info on how to run our tests.

>If you have questions, please head to our [developer community website](https://community.mongodb.com/) where the MongoDB engineers and the MongoDB community will help you build your next big idea with MongoDB.


New upgrades in the Rust MongoDB driver and BSON library improve integration with Serde.

Structuring Data With Serde in Rust

Learn how to perform CRUD operations using Rust for MongoDB databases.

Get Started with Rust and MongoDB

Partner

Jan Piotrowski

Engineering Manager, Schema Team at Prisma

Prisma ORM (object relational-mapper) [recently released support for MongoDB](https://www.prisma.io/blog/mongodb-general-availability-pixnun6mffmu). This represents the first time Prisma has supported a database outside of the SQL world. Prisma has been known for supporting many relational databases, but how did it end up being able to support the quite different MongoDB?

> 🕴️ I work as the Engineering Manager of Prisma’s Schema team. We are responsible for the schema management parts of Prisma, which most prominently include our migrations and introspection tools, as well as the Prisma schema language and file (and our awesome [Prisma VS Code extension](https://marketplace.visualstudio.com/items?itemName=Prisma.prisma)!).
>
> The other big team working on Prisma object relational-mapper (ORM) is the Client team that builds Prisma Client and the Query Engine. These let users interact with their database to read and manipulate data.
>
> In this blog post, I summarize how our team got Prisma’s schema introspection feature to work for the new MongoDB connector and the interesting challenges we solved along the way.


## Prisma

Prisma is a Node.js database ORM built around the [Prisma schema language and the Prisma schema file](https://www.prisma.io/docs/concepts/components/prisma-schema) containing an abstract representation of a user’s database. When you have tables with columns of certain data types in your database, those are represented as models with fields of a type in your Prisma schema.

Prisma uses that information to generate a fully type-safe [TypeScript/JavaScript Prisma Client](https://www.prisma.io/docs/concepts/components/prisma-client) that makes it easy to interact with the data in your database (meaning it will complain if you try to write a `String` into a `Datetime` field, and make sure you, for example, include information for all the non-nullable columns without a default and similar).

[Prisma Migrate](https://www.prisma.io/docs/concepts/components/prisma-migrate) uses your changes to the Prisma schema to automatically generate the SQL required to migrate your database to reflect that new schema. You don’t need to think about the changes necessary. You just write what you want to achieve, and Prisma then intelligently generates the SQL DDL (Data Definition Language) for that.

For users who want to start using Prisma with their existing database, Prisma has a feature called [Introspection](https://www.prisma.io/docs/concepts/components/introspection). You call the CLI command `prisma db pull` to “pull in” the existing database schema, and Prisma then can create the Prisma schema for you automatically, so your existing database can be used with Prisma in seconds.

This works the same for PostgreSQL, MySQL, MariaDB, SQL Server, CockroachDB, and even SQLite and relies on _relational databases_ being pretty similar, having tables and columns, understanding some dialect of SQL, having foreign keys, and concepts like referential integrity.


## Prisma + MongoDB

One of our most requested features was support for Prisma with MongoDB. The [feature request issue on GitHub for MongoDB support](https://github.com/prisma/prisma/issues/1277) from January 2020 was for a long time by far the most popular one, having gained more than a total of 800 reactions.

![GitHub issue reactions image](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/1_c73f797f9a.png)

MongoDB is known for its flexible schema and the document model, where you can store JSON-like documents. MongoDB takes a different paradigm from relational databases when modeling data – there are no tables, no columns, schemas, or foreign keys to represent relations between tables. Data is often stored grouped in the same document with related data or “denormalized,” which is different from what you would see in a relational database.

So, how could these very different worlds be brought together?


## Prisma and MongoDB: Schema team edition

For our team, this meant figuring out: 

1. How to represent a MongoDB structure and its documents in a Prisma schema.
2. How to migrate said data structures.
3. How to let people introspect their existing MongoDB database to easily be able to start using Prisma.

Fortunately solving 1 and 2 was relatively simple:

1. Where relational databases have tables, columns, and foreign keys that are mapped to Prisma’s models, with their fields and relations, MongoDB has equivalent collections, fields, and [references](https://www.mongodb.com/docs/manual/core/data-modeling-introduction/#references) that could be mapped the same way. Prisma Client can use that information to provide the same type safety and functionality on the Client side.

<table width="100%">
  <tr>
   <td width="33%" align="right">
<strong>Relational database</strong>
   </td>
   <td width="33%" align="center"><strong>Prisma</strong>
   </td>
   <td width="33%" align="left"><strong>MongoDB</strong>
   </td>
  </tr>
  <tr>
   <td align="right">Table →
   </td>
   <td align="center">Model
   </td>
   <td>← Collection
   </td>
  </tr>
  <tr>
   <td align="right">Column →
   </td>
   <td align="center">Field
   </td>
   <td>← Field
   </td>
  </tr>
  <tr>
   <td align="right">Foreign Key →
   </td>
   <td align="center"~~~~>Relation
   </td>
   <td>← Reference
   </td>
  </tr>
</table>

<ol start="2">
<li>With no database-side schema to migrate, creating and updating indexes and constraints was all that was needed for evolving a MongoDB database schema. As there is no SQL to modify the database structure (which is not written down or defined anywhere), Prisma also did not have to create migration files with Data Definition Language (DDL) statements and could just scope it down to allowing `prisma db push` to directly bring the database to the desired end state.</li>
</ol>

A bigger challenge turned out to be the Introspection feature.


## Introspecting a schema with MongoDB

With relational databases with a schema, there is always a way to inquire for the schema. In PostgreSQL, for example, you can query multiple views in a `information_schema` schema to figure out all the details about the structure of the database—to, for example, generate the DDL SQL required to recreate a database, or abstract it into a Prisma schema.

Because MongoDB has a flexible schema (unless schemas are enforced through the schema validation feature), no such information store exists that could be easily queried. That, of course, poses a problem for how to implement introspection for MongoDB in Prisma.

## Research

As any good engineering team would, we started by ... Googling a bit. No need to reinvent the wheel, if someone else solved the problem in the past before. Searches for “MongoDB introspection,” “MongoDB schema reverse engineering,” and (as we learned the native term) “MongoDB infer schema” fortunately brought some interesting and worthwhile results.


### MongoDB Compass

MongoDB’s own database GUI Compass has a [“Schema” tab](https://www.mongodb.com/docs/compass/current/schema/) in a collection that can analyze a collection to “provide an overview of the data type and shape of the fields in a particular collection.”

![MongoDB Compass GUI Schema tab](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/2_f3f060548e.png)

It works by sampling 1000 documents from a collection that has at least 1000 documents in it, analyzing the individual fields and then presenting them to the user.

### `mongodb-schema`

Another resource we found was Lucas Hrabovsky’s [`mongodb-infer` repository](https://github.com/imlucas/mongodb-infer) from 2014. Later that year, it seemed to have merged/been replaced by [`mongodb-schema`](https://github.com/mongodb-js/mongodb-schema), which is updated to this day.

It’s a CLI and library version of the same idea—and indeed, when checking the source code of MongoDB Compass, you see a dependency for `mongodb-schema` that is used under the hood.


## Implementing introspection for MongoDB in Prisma

Usually, finding an open source library with an Apache 2.0 license means you just saved the engineering team a lot of time, and the team can just become a user of the library. But in this case, we wanted to implement our introspection in the same introspection engine we also use for the SQL databases—and that is written in Rust. As there is no `mongodb-schema` for Rust yet, we had to implement this ourselves. Knowing how `mongodb-schema` works, this turned out to be straightforward:

We start by simply getting all collections in a database. The [MongoDB Rust driver](https://github.com/mongodb/mongo-rust-driver) provides a handy [`db.list_collection_names()`](https://github.com/mongodb/mongo-rust-driver#getting-a-handle-to-a-database) that we can call to get all collections—and each collection is turned into a model for Prisma schema. 🥂

To fill in the fields with their type, we get a sample of up to 1000 random records from each collection and loop through them. For each entry, we note which fields exist, and what data type they have. We map the BSON type to our Prisma scalar types (and native type, if necessary). Optimally, all entries have the same fields with the same data type, which is easily and cleanly mappable—and we are done!

Often, not all entries in a collection are that uniform. Missing fields, for example, are expected and equivalent to `NULL` values in a relational database.


### How to present fields with different types

But different types (for example, `String` and `Datetime`) pose a problem: Which type should we put into the Prisma schema?

> 🎓 **Learning 1: Just choosing the most common data type is not a good idea.**
>
> In an early iteration of MongoDB introspection, we defaulted to the most common type, and left a comment with the percentage of the occurrences in the Prisma schema. The idea was that this should work most of the time and give the developer the best development experience—the better the types in your Prisma schema, the more Prisma can help you.
>
> But we quickly figured out when testing this that there was a slight (but logical) problem: Any time the Prisma Client encounters a type that does _not_ match what it has been told via the Prisma schema, it has to throw an error and abort the query. Otherwise, it would return data that does not adhere to its own generated types for that data.
>
> While we were aware this would happen, it was not intuitive to us _how often_ that would cause the Prisma Client to fail. We quickly learned about this when using such a Prisma schema with conflicting types in the underlying database with Prisma Studio, the built-in database GUI that comes with Prisma CLI (just run `npx prisma studio`). By default, it loads 100 entries of a model you view—and when there were ~5% entries with a different type in a database of 1000 entries, it was very common to hit that on the first page already. Prisma Studio (and also an app using these schemas) was essentially unusable for these data sets this way.

Fortunately, _everything_ in MongoDB is a `Document`, which maps to a `Json` type field in Prisma. So, when a field has different data types, we use `Json` instead, output a warning in Prisma CLI, and put a comment above the field in the Prisma schema that we render, which includes information about the data types we found and how common they were.

<figure>
<img src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/3_fd4367364a.png" alt="Output of Prisma CLI on conflicting data types">
<figcaption align = "center">Output of Prisma CLI on conflicting data types</figcaption>
</figure>

<figure>
<img src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/4_8ddf4af2fd.png" alt="Resulting Prisma schema with statistics on conflicting data types">
<figcaption align = "center">Resulting Prisma schema with statistics on conflicting data types</figcaption>
</figure>

### How to iterate on the data to get to a cleaner schema

Using `Json` instead of a specific data type, of course, substantially lowers the benefit you get from Prisma and effectively enables you to write any JSON into the field (making the data even less uniform and harder to handle over time!). But at least you can read all existing data in Prisma Studio or in your app and interact with it.

The preferred way to fix conflicting data types is to read and update them manually with a script, and then run `prisma db pull` again. The new Prisma schema should then show only the one type still present in the collection.

> 🎓 **Learning 2: Output Prisma types in Prisma schema, not MongoDB types.**
>
> Originally, we outputted the raw type information we got from the MongoDB Rust driver, the [BSON types](https://www.mongodb.com/docs/manual/reference/bson-types/), into our CLI warnings and Prisma schema comments to help our users iterate on their data and fix the type. It turned out that while this was technically correct and told the user what type the data was in, using the BSON type names was confusing in a Prisma context. We switched to output the Prisma type names instead and this now feels much more natural to users.

While Prisma recommends everyone to clean up their data and minimize the amount of conflicting types that fall back to `Json`, that is, of course, also a valid choice.


### How to enrich the introspected Prisma schema with relations

By adding relation information to your introspected Prisma schema, you can tell Prisma to handle a specific column like a foreign key and create a relation with the data in it. `user User @relation(fields: [userId], references: [id])` creates a relation to the `User` model via the local `userId` field. So, if you are using MongoDB references to model relations, add `@relation` to them for Prisma to be able to access those in Prisma Client, emulate referential actions, and help with referential integrity to keep data clean.

Right now, Prisma does not offer a way to detect or confirm the potential relations between different collections. We want to learn first how MongoDB users actually use relations, and then help them the optimal way.

## Summary

Implementing a good introspection story for MongoDB was a fun challenge for our team. In the beginning, it felt like two very different worlds were clashing together, but in the end, it was straightforward to find the correct tradeoffs and solutions to get the optimal outcome for our users. We are confident we found a great combination that combines the best of MongoDB with what people want from Prisma.

Try out [Prisma and MongoDB with an existing MongoDB database](https://www.prisma.io/docs/getting-started/setup-prisma/add-to-existing-project/mongodb-typescript-mongodb), or [start from scratch and create one along the way](https://www.prisma.io/docs/getting-started/setup-prisma/start-from-scratch/mongodb-typescript-mongodb).

In this blog, you’ll learn about Prisma and how we interact with MongoDB, plus the next steps after having a schema.

How Prisma Introspects a Schema from a MongoDB Database

We have some exciting news to announce for Rust developers. Our 2.4.1 release of the MongoDB Rust driver brings a raft of new, innovative features for developers building Rust applications. 

## Field Level Encryption for Rust Applications
This one has been a long time coming. The 2.4.1 version of the MongoDB Rust driver contains field level encryption capabilities - both client side field level encryption and queryable encryption. Starting with MongoDB 4.2, client-side field level encryption allows an application to encrypt specific data fields in addition to pre-existing MongoDB encryption features such as Encryption at Rest and TLS/SSL (Transport Encryption).

With field level encryption, applications can encrypt fields in documents prior to transmitting data over the wire to the server. Client-side field level encryption supports workloads where applications must guarantee that unauthorized parties, including server administrators, cannot read the encrypted data.

For more information, see the [Encryption](https://mongodb.github.io/mongo-rust-driver/manual/encryption.html) section of the Rust driver documentation.

## GridFS Rust Support
The 2.4.1 release of the MongoDB Rust driver also (finally!) added support for GridFS, allowing storage and retrieval of files that exceed the BSON document size limit. 


## Tracing Support 
This release had one other noteworthy item in it - the driver now emits tracing events at points of interest. Note that this API is considered unstable as the tracing crate has not reached 1.0 yet; future minor versions of the driver may upgrade the tracing dependency to a new version which is not backwards-compatible with Subscribers that depend on older versions of tracing. You can read more about tracing from the crates.io documentation [here.](https://crates.io/crates/tracing)


## Install the MongoDB Rust Driver
To check out these new features, you'll need to install the MongoDB Rust driver, which is available on crates.io. To use the driver in your application, simply add it to your project's Cargo.toml.

```
[dependencies]
mongodb = "2.4.0-beta"
```

MongoDB now support field level encryption for Rust applications

MongoDB Field Level Encryption is now Available for Rust applications

A multi-paradigm, general-purpose programming language designed for performance and safety.  Rust is a low-level programming language with high performance and can be used to write operating systems, game engines, and embedded applications.

Rust

Featured

Using MongoDB With Rust Web Development Framework

MongoDB Field Level Encryption is now Available for Rust applications

Getting Started with Aggregation Pipelines in Rust

All Rust Content