I have to say, the more I work with React, the more I hate working with the requirements for my day job. I can’t just switch over to React at work right now but that’s OK since I’m still not 100% on top of how React works, plus I’d have to create a back-end API through which our sites would work with data.

In this personal project, though, my opportunities are flexible, but a down-side is that finding something that works for me is proving to be more difficult than it really should be in 2021. Today I am specifically talking about data storage.

This project is basically built to use a multi-tiered data construct, meaning that a top-level record has several child records, each of which have several child records. As far as data structures go, it’s not rocket surgery. In the world of relational databases, this could be represented by using “foreign keys”. A foreign key is a value that exists in two tables and allows us to select records from multiple sources by having a common, known value using something like this:

select a.title, b.author from posts a join authors b on b.id = a.author_id

In this example author_id in the posts table is considered the foreign key, because the id field of the authors table is the “primary key”.

I could set up a relational database like MySQL or even SQL Server Community Edition, but then I’d need to create a web project on top of that which runs queries (or stored procedures, canned queries that can encapsulate limited logic and error handling script) and returns them to a publicly available endpoint or “web API”. My front end would send a request to a specific web API endpoint, passing info that identifies me as well as any criteria I might need to pass. The web API would authenticate me (as a security measure) and use other info I sent to modify the database query. The result would be data returned to the front end in a consumable text format like JSON. The front end app could use this data as needed.

But I don’t want to manage the data store! Again, it’s 2021, and we have all kinds of cloud-based services for hosting websites, hosting files, hosting video game servers, and even hosting code editors. There are cloud-hosted databases like Azure or AWS, but those are stupidly heavy for a simple project like this one; they make users set up a whole series of interconnected services for disk space, firewalls, access rules…all of which is important, sure, but why can’t I just get a service which provides me with a database and security settings?

Well, I can. I found at least two that I’ve been trying out. One is called Easybase, and the other is Cloud Firestore.

Easybase

Easybase does what it says on the label: make it easy to set up databases for your online apps.

Everything is managed through a web browser. I created a table definition, assigned it to a project, and then downloaded a credential file that I included in my application. Then, it’s as easy as wrapping my code blocks in specific tags and setting values to push to the data store or submit simple queries to pull data to the app.

The downside to Easybase is that I can’t seem to find an outpouring of support for it. I came across it via an article on how to add user security to your React-based website, but when I ran into an issue, I was very hard-pressed to find info. The link to their documentation is not as obvious as it should be, and there are scant few articles around the web that talk about working with Easybase — most results point back to their own website. I’d be OK with that if their own website pushed more technical and less marketing to the top of the SEO list. I also question how many people out there are using Easybase; there should be a lot more people writing about it, pro or con, then I was able to find, and that worries me.

Easybase has a free tier which allows for single user access, unlimited tables, and “advanced integrations”. They also give a $10USD free monthly quota which…I’m not entirely sure how that works. On my free tier account, the few tests I’ve run have apparently already generated $27.13 worth of traffic, which blows that $10 stipend clear out of the water.

Considering I didn’t really push or pull that much data in my tests, I’m a tad bit concerned about what kind of bill this service would generate if I had even a small community of users working with the site. Easybase offers a pricing calculator, but I have no idea right now how much traffic, how many requests, or how much file storage this project would use.

Cloud Firestore

This option is part of the Firebase suite of services, which is owned and operated by Google. Cloud Firestore is accessed through a browser, although it’s a subset of the overall Firebase suite which is what I had to sign up for in order to access the data store portion. No worries, as there might be something in Firebase that I might find useful.

Cloud Firestore is an interesting take on the whole serverless data store approach. While it’s possible to create a data bucket ahead of time, Cloud Firestore allows the application to generate or delete data buckets on the fly in what’s known as a “code first approach”. That’s pretty trippy stuff, as it means that the code design dictates the data structure opposed to bouncing back and forth between the database schema and the code, getting the two to match up so all data is present and accounted for…sometimes even before your app is working well enough to read or write data at all.

Firebase and Cloud Firestore also have a free tier in the “Spark Plan”. When it comes to Cloud Firestore, 1GB of data storage is free, with 10GB network traffic per month. Daily, the free tier allows 20k document writes, 50k document reads, and 20k document delete actions. For testing that’s pretty OK, I’m guessing, and there are other aspects of the greater Firebase suite that are also included here. On the paid tier, stored data is $0.18 per GB, and between $0.02 and $0.18 per 100k writes, reads, and deletes. Network traffic looks to be about $0.12/GB. There’s a whole pile of cost here, most of which I’m not at the point to realize quite yet, so I can’t really even estimate the cost.

NoSQL

One thing of note is that both Easybase and Cloud Firestore are “NoSQL data stores”. Unlike traditional relational databases, NoSQL stores are pretty loose with the whole “database-table-field” thing. Here, data is stored in plain old files, in a format like JSON which is a hierarchical structure.

{  
    "employee": {  
        "name":       "KSIMMONS",   
        "salary":      56000,   
        "fullTime":    true  
    },
    "employee": {  
        "name":       "JARCHER",   
        "salary":      36000,   
        "fullTime":    false
    }  
}  

NoSQL presents some interesting opportunities. Despite storing data in regular ol’ files, the engines still index data to provide quick data retrieval. However, this also means that we can’t always perform complex queries. Both Easybase and Cloud Firestore allow limited query syntax, and cross-table joins are pretty much out of the question (such as in the first example above). There are ways around it, though, assuming the design of the data store is forward thinking about it.

The biggest kicker is that with a file-based data store, data structures are completely fluid. Easybase provides us with the means to create a “schema” that defines a “data table” that limits us to the fields we have available. This makes working with the data store pretty easy since we will always know which fields we have to work with. Cloud Firestore, however, works in true NoSQL fashion: we don’t need to have field-parity between the individual records in a data store. For example, one record could have a field:value of “middleName:Joshua”, while the record that follows doesn’t even have the “middleName” field at all; the presence or absence of a specific field depends on the presence or absence of data available to store there. As flexible as this is, allowing us to create data buckets based on our code objects and need, it also requires a lot of graceful handling of those cases where we might expect a specific data element that isn’t guaranteed to be present, even among records in a collection returned to the application.

Which Is Best?

Honestly, I’m not sure which option is best for my needs. Easybase is pretty structured, which I like because when I know what to expect in terms of data schema I don’t have to worry about mismatches between data items. However, the flexibility of Cloud Firestore is pretty awesome, and I like being able to not even have to hit the service dashboard to manage the data store.

What’s really getting my goat is how to organize a dataset which is hierarchical in nature. Cloud Firestore uses the concept of “collections” (databases), “documents” (tables), and “properties” (fields). However, documents can have sub-collections, which have their own documents and properties, and this can nest down 100 units deep. I don’t need anything that large, but being able to set up a structure like that means I could pull a dataset at one level and get everything below it at the same time, preventing the need to join to other data stores. Still, I find it easier to think in terms of relational databases, which seems to be more like what Easybase is structured to offer, even if it’s not running that way behind the scenes.

For now, I am going forward testing with Cloud Firebase since it’s all code and I don’t have to work with their dashboard to “pre-think” my data structure. I can add and remove data fields as I work, and when I settle on a final set of data elements, the data store will just accept it without any redesign on my part.