Streamlining Cloud-Native Development with Gitpod and MongoDB Atlas
Rate this tutorial
Developers are increasingly shifting from the traditional development model of writing code and testing the entire application stack locally to remote development environments that are more cloud-native. This allows them to have environments that are configurable as-code, are easily reproducible for any team member, and are quick enough to spin up and tear down that each pull request can have an associated ephemeral environment for code reviews.
As new platforms and services that developers use on a daily basis are more regularly provided as cloud-first or cloud-only offerings, it makes sense to leverage all the advantages of the cloud for the entire development lifecycle and have the development environment more effectively mirror the production environment.
In this blog, we’ll look at how Gitpod, with its Cloud Development Environment (CDE), is a perfect companion for MongoDB Atlas when it comes to a cloud-native development experience. We are so excited about the potential of this combined development experience that we invested in Gitpod’s most recent funding round.
As an example, let’s look at a simple Node.js application that exposes an API to retrieve quotes from popular authors. You can find the source code on Github. You should be able to try out the end-to-end setup yourself by going to Gitpod. The project is configured to use a free cluster in Atlas and, assuming you don’t have one already running in your Atlas account, everything should work out of the box.
The code for the application is straightforward and is mostly contained in app.js, but the most interesting part is how the Gitpod development environment is set up: With just a couple of configuration files added to the GitHub repository, a developer who works on this project for the first time can have everything up and running, including the MongoDB cluster needed for development seeded with test data, in about 30 seconds!
Let’s take a look at how that is possible.
We’ll start with the Dockerfile. Gitpod provides an out-of-the-box Docker image for the development environment that contains utilities and support for the most common programming languages. In our case, we prefer to start with a minimal image and add only what we need to it: the Atlas CLI (and the MongoDB Shell that comes with it) to manage resources in Atlas and Node.js.
To make things a little easier and cleaner, we’ll also add to the container a mongodb-utils.sh file and load it into bash_aliases. It’s a bash script that contains convenience functions that wrap some of the Atlas CLI commands to make them easier to use within the Gitpod environment.
The second half of the configuration is contained in .gitpod.yml. This file may seem a little verbose, but what it does is relatively simple. Let’s take a closer look at these configuration details in the following sections of this article.
Our Quotes API application uses MongoDB to store data: All the quotes with their metadata are in a MongoDB collection. Atlas is the best way to run MongoDB so we will be using that. Plus, because we are using Atlas, we can also take advantage of Atlas Search to offer full-text search capabilities to our API users.
Since we want our development environment to have characteristics that are compatible with what we’ll have in production, we will use Atlas for our development needs as well. In particular, we want to make sure that every time a developer starts a Gitpod environment, a corresponding ephemeral cluster is created in Atlas and seeded with test data.
With some simple configuration, Gitpod takes care of all of this in a fully automated way. The
atlas_up script creates a cluster with the same name as the Gitpod workspace. This way, it’s easy to see what clusters are being used for development.The script above is a little sophisticated as it takes care of opening the browser and logging you in with your Atlas account if it’s the first time you’ve set up Gitpod with this project. Once you are set up the first time, you can choose to generate API credentials and skip the login step in the future. The instructions on how to do that are in the README file included in the repository.
When developing an application, it’s convenient to have test data readily available. In our example, the repository contains a zipped dataset in JSON format. During the initialization of the workspace, once the cluster is deployed, we connect to it with the MongoDB Shell (mongosh) and run a script that loads the unzipped dataset into the cluster.
As part of our Quotes API, we provide an endpoint to search for quotes based on their content or their author. With Atlas Search and the MongoDB Query API, it is extremely easy to configure full-text search for a given collection, and we’ll use that in our application.
As we want the environment to be ready to code, as part of the initialization, we also create a search index. For convenience, we included the
data/_create-search-index.sh script that takes care of that by calling the atlas cluster search index create command and passing the right parameters to it.To make the cluster truly ephemeral and start with a clean state every time we start a new workspace, we want to make sure we terminate it once it is no longer needed.
For this example, we’ve used a free cluster, which is perfect for most development use cases. However, if you need better performance, you can always configure your environment to use a paid cluster (see the
--tier option of the Atlas CLI). Should you choose to do so, it is even more important to terminate the cluster when it is no longer needed so you can avoid unnecessary costs.To do that, we wait for the Gitpod environment to be terminated. That is what this section of the configuration file does:
The
atlas_cleanup_when_done script waits for the SIGTERM sent to the Gitpod container and, once it receives it, it sends a command to the Atlas CLI to terminate the cluster.
During development, it is often useful to look at the data stored in MongoDB. As Gitpod integrates very well with VS Code, we can configure it so the MongoDB for VS Code extension is included in the setup.
This way, whoever starts the environment has the option of connecting to the Atlas cluster directly from within VS Code to explore their data, and test their queries. MongoDB for VS Code is also a useful tool to insert and edit data into your test database: With its Playground functionality, it is really easy to execute any CRUD operation, including scripting the insertion of fake test data.
As this is a JavaScript application, we also include the Standard VS Code extension for linting and code formatting.
MongoDB Atlas is the ideal data platform across the entire development lifecycle. With Atlas, developers get a platform that is 100% compatible with production, including services like Atlas Search that runs next to the core database. And as developers shift towards Cloud Development Environments like Gitpod, they can get an even more sophisticated experience developing in the cloud with Atlas and always be ready to code. Check out the source code provided in this article and give MongoDB Atlas a try with Gitpod.
Rate this tutorial
Related
Tutorial
Enhancing LLM Accuracy Using MongoDB Vector Search and Unstructured.io Metadata
Dec 04, 2023 | 12 min read
Tutorial
Add a Comments Section to an Eleventy Website with MongoDB and Netlify
Feb 03, 2023 | 19 min read