If you’re like me, and you had no coding or development experience before jumping into Computer Science program at somewhere like Oregon State, your introduction to databases, and the whole dynamic of Front End vs Back End development really, came in the form of classes like Web Development, and appropriately, Intro to Databases. These are foundational, and I’m not complaining about their content! But are they covering the current evolution of every type of software design and development architecture? Nope. And so here we are: months away from my graduation and I’m just now really learning about NoSQL databases and the many cloud computing infrastructures that use them. Without further ado, a brief rundown:
Come to find out, the days when relational databases were the de facto data storage solution are long gone. For many years (we’re talking the ’70s, the ’80s, the early ’90s), storing data was expensive, and the priority in software development was to reduce data duplication and easily write to the database. Relational Database Management Systems (RDBMS) used Structured Query Language (SQL) with painstakingly structured schema to achieve this goal, and RDBMSs like MySQL became ubiquitous. While it is certainly not true to say that relational databases have outlived their usefulness – They’re still widely used in tons of industries – it is true that so called NoSQL or non-relational databases provide an attractive alternative for some use cases. Maybe we touched on these in our database class, but it clearly wasn’t enough to stick. Moving on…
When the cost of storage began to rapidly decline, sometime in the 2000s, it became less important to focus on storage, and increasingly important that projects could iterate and adjust in keeping with Agile methodologies, scale easily, and run queries quickly. NoSQL databases use documents, key-value pairs, or sometimes graphs, instead of rigidly normalized (*shudder*) Tables. The idea, in some ways, is to store your data more similarly to how you actually think about it, and importantly, how you’ll use it. NoSQL documents can be nested JSON-like structures, which translate directly to the objects used in many programming languages. We can’t flat-out say NoSQL databases are faster than relational ones. Normalization in RDBMS seeks to make complex joins and queries as fast as possible, and yet as tables grow very large, these joins and queries are nevertheless going to become more expensive. With NoSQL however, if we will need to retrieve the data together, we simply store it together: we circumvent the need for joins almost entirely as queries can grab a single document, and are thus exceedingly quick. Hooray!
In my Capstone Project, a cross-platform discussion app built with the Flutter SDK, our group has decided to use Firebase, Google’s nifty platform for developing mobile apps. Firebase is itself backed by Google Cloud Platform, so we’re clearly set-up for scale with Google servers. Firebase has many products and integrations, from backend infrastructure like Authorization and Cloud Firestore, to performance analysis products like Crashlytics. Cloud Firestore, being a NoSQL database, offers super easy methods for listening to data-changes, implemented in Flutter as Streams. So far reads and writes have been smooth and fast. While this suite of products is a tad overwhelming at first, diving in has been a great learning experience. I’m understanding the ‘serverless’ paradigm better, and recognize how much platforms like Firebase simplify traditional back-end development. Are cloud-native and serverless architecture with NoSQL databases the answer to every use case? Not remotely. But for many situations, including our app, it relieves the developer from having to reinvent the wheel standing up their back-end, and allows data storage to be intuitive, flexible, and scalable. It’s a ‘yes’ from me!
