For this blog post I will describe some of the technologies that I have researched so far regarding different architectures and strategies for creating a relational database for our crowd-sourced shopping app project. I will describe the technologies I’ve used in the past and some of the new technologies I’m considering and why they might be beneficial for this project.
From my previous experience in my databases class we were tasked with creating a website that utilized a relational database with various CRUD functionality between the different tables stored on different pages. This is a very straight forward way of doing it and the CRUD functionality is relatively intuitive if you’re looking at a schema of the database layout. I enjoyed this class because it was almost like a puzzle to figure out the various interactions and joins you have to before to implement a search function or what foreign keys have to updated where on the creating of a new entry. However, it get complicated quickly and when something breaks or you need to restore a table or something you must remap all the relationships or reestablish all the relationships one by one which is a pretty inconvenient way of doing things. That’s where some of the new to me technologies I’ve been researching may come into play.
From my research I discovered that the previous structure of database and website that I implemented would be what is referred to as a “monolithic architecture” meaning that there is one singular structure in which the website or app or in this case database interactions take place (https://medium.com/koderlabs/introduction-to-monolithic-architecture-and-microservices-architecture-b211a5955c63). This was a common strategy for web applications some time ago before there were huge websites like Amazon and Facebook that have incredibly complex and elaborate layouts and interconnections and data volume. This architecture, like my database from earlier, is straight forward and intuitive to understand. it works perfectly fine for a simple web app or website because if something breaks since it is relatively small it is easy to find what broke. But if something breaks on a large ecommerce site if there was a singular monolithic architecture it would be nearly impossible to find and fix the bug that comes up because you wouldn’t know which specific part of the application was broken.
That’s where microservices come in. Microservices is another architecture strategy like monolithic architecture but the idea behind microservices is that the application you are designing is broken up to small modularized components. This is an advantage because if someone were to push a change for a website or application and something breaks it if they were using a microservice architecture they would know that the bug is isolated within the single module of the application for which they were working on. There are various other advantages as well regarding scaling of servers for example if a microservice for an ecommerce site had a large increase in traffic like around the holidays rather than deploying the whole ecommerce site to more and more servers they could simply deploy the microservices that are most impacted by the increase in traffic to those servers (https://www.youtube.com/watch?v=j1gU2oGFayY&t=726s&ab_channel=JavaBrains). The disadvantage of a microservice architecture is that it does increase complexity. You have to integrate these additional handlers that would not normally be there and break the database up into smaller parts so that the functionality can be modularized.
This increase in complexity is currently where I am at with the development of the database I will be creating for our crowd-sourced shopping app. I still need to understand how to split the monolithic approach for a database that I have in my head into “micro-databases” that can be utilized by various microservices. So the next step I will be taking is trying to understand how a monolithic relational database can be split up into smaller databases but still maintain the core required functionalities required to implement the CRUD functionality we will need. I’m not positive if this is the best approach for our app but it is something that I think is worth looking into and the concepts of creating a more modularized application definitely has its merits.
