A better approach for Cloud Firestore — ODM (Part 1)

Structuring Firebase NoSQL

source: https://unsplash.com/photos/-7A6aRj_3nY

The apps we create are mostly based on a CRUD and there’s a need to connect the code and the data that is generated from it to a database in order to not have it just in ephemeral state.

We might consider working with Cloud Firestore as our backend solution since the connection becomes an easy and practical task since we don’t need to be focusing on a lot of rules beforehand to build the database, and even setting up the database itself is an automatic task.
All we have to do comes down to just creating the project and enabling the database service and from within our code add (and if collection nonexistent creates) the desired data as we wish. With not many rules attached to the process, as for instance the type of data for each document and its fields, when working with the data there’s a need to really check on and make sure that we’re actually reading the data correctly within our implementation.

Thinking about that, it’s being introduced (in Alpha as of the date of publishing this article) a library that allows developers to create schemas for the Cloud Firestore database, called ODM.

In this series of articles we’re going to learn about Cloud Firestore in a more depth way, from the definitions up to a practical example:

1. A better approach for Cloud Firestore — ODM (Structuring Firebase NoSQL) (this article)
2. A better approach for Cloud Firestore — ODM (Setting Up and Defining our Models)

So, what’s ODM?

ODM means Object Document Mapper, and basically works as a way to define a structure for a NoSQL database, it is popular with MongoDB users, where you can define for you no-structured database some “rules” as schemas to add some form of validation before committing the data.

Why use Cloud Firestore ODM

Although I spat the tea already on the introduction, I’ll try to use a more specific example now, so it gets clear.
For instance, let’s say you define an object Developer and you want to have his name (String), number of bugs detected — num_bugs (int) and bugs fixed — fixed_bugs(also a int), so a schema as the one defined when working with a relational database is required, of course you’d think, since I already defined the object, it’s fine. But the truth is the Cloud Firestore doesn’t know that, so the Document fields can be defined as the dataset understands which type the data is, so, creating this schema makes more safer to have control on both sides (Cloud Firestore and the code), so while reading the data won’t also be necessary to worry about the parsing.

Let’s dig into some key points here:

• Bi-directional data validation
  When we have a Cloud Firestore database set up, as it was explained previously we cannot be 100% sure that the data type you are inserting is really the one we should according to the collection, unless you’re checking yourself, since we don’t have any type of error for that case if not while you already trying to parse, which, could be avoided if it was previously defined a schema that wouldn’t allow “wrong” data to go into the “wrong” collection in first place, this is why there’s a need to define schemas that our flutter code will interpret while creating and reading the data to/from Firestore.
• Type-safe data querying, supporting all Firestore query operations
  Following what was previously said about how sure you can be on the data being treated as we code, with Cloud Firestore ODM there’s an implementation that allows us to see those errors at compile time, so, we don’t only find out when reading the data from Firestore, which we’ll see later on with the practical example.
• Flutter Widgets for simple data binding with your data
  In order to make the experience simpler there’s also the implementation of widgets like FirestoreBuilder that allow us to easily work with our cloud firestore instances.
• Data selectors to help avoid unnecessary Widget rebuilds
  This is a concept where, the basic idea is that instead of listening to an entire object while reading its data, we can just listen to an attribute of it, allowing the widget to rebuild only if that specific attribute changes or gets updated instead of any other attribute of the object.
• Full API code completion
  For those who are familiar with some other solutions as MobX, this is the same concept of code generation for easy implementation of functionalities for our code in order to reduce some boilerplate. If you aren’t familiar with the concept we’ll explore it later on over the series.

So, that’s it for now… Thank you for reading. I hope you enjoyed and learned from it.
If you want to know more about the topic you can read the next article for a more in depth example.

Sign up to the mailing list to get notified for new articles drop.
For questions and/or suggestions, I am available through the comments section, email igorlsambo1999@gmail.com or twitter @lsambo02.

Thank you and we will catch up on the next article!!!