Welkom bij weer een nieuwe blog over Coqfoss, ons interne project waarin we nieuwe dingen te leren door samen te werken. In deze reeks blogs nemen we je mee in de technieken die we gebruiken en delen de ervaringen die we opdoen. We zijn toe aan een wat permanentere oplossing voor data opslag. In deze blog gaan we de persistentie regelen met een Azure Cosmos database.
In de vorige blog heb je gelezen hoe we aan onze applicatie een voorkant in Vue hebben kunnen toevoegen. Daarmee hebben we nu een ietwat gebruikersvriendelijke manier om de API van de backend aan te spreken. Omdat we graag de input van onze gebruikers ook zouden onthouden na een redeploy van de Docker container hebben we een database nodig.
Vijf databases in één
Gelukkig heeft Azure in hun free tier, naast de App Service die we al gebruiken, ook Cosmos database zitten. Cosmos is een redelijk uniek soort database. Je kunt namelijk bij het aanmaken van zo’n database kiezen wat voor type API en bijbehorend datamodel je voor je database wenst. Je hebt daarbij een aantal keuzes. De eerste optie is voor een ‘standaard’ SQL API. Ook kan er gekozen worden uit een NoSQL oplossing met de MongoDB API die veel mensen ook wel eens voorbij hebben zien komen. Daarnaast is er een key-value pair storage, die Azure Table heet en qua API op Redis lijkt. Voor de liefhebber van Graph databases is er ook een Gremlin API, die de concurrentie aangaat met de Cypher API van Neo4j. Als laatste optie is er dan nog Cassandra.
We hebben dus met Cosmos database veel ruimte om te kiezen wat voor API en datamodel we willen gebruiken. Voor ons lijkt de keuze nu relatief makkelijk. We hebben tot op heden elke keer dat we aan Coqfoss werken wijzigingen aan ons model gemaakt. Daarom is flexibiliteit nu een groot goed. We moeten zonder veel gezeur of poespas makkelijk van opslagmodel kunnen wijzigen. Ook hebben we vooralsnog geen relaties tussen domeinobjecten die we graag willen vastleggen of queryen. Daarmee is de keuze gemaakt; we kiezen voorlopig voor de MongoDB variant van Cosmos.
Het maken van de database zelf is zo gedaan. We geven een naam op, selecteren de juiste API en locatie en we kunnen nadat we op create drukken gelijk onze gratis database gebruiken.
Hoe zit het met de kosten?
Omdat CodeSquad een kleine organisatie is (lijkt dat je wat? we kunnen nog goede collega’s gebruiken!) hebben we onder de 20 gebruikers, die ook niet dagelijks de applicatie hoeven te gebruiken. Door bewust te kiezen voor de gratis opties en daar mee te experimenteren hebben we nog steeds geen cent uitgegeven op Azure, en hoeven we dat ook in de toekomst niet snel te gaan doen.
Wel is het zo dat deze ‘gratis’ oplossing wat beperkingen met zich mee brengt. Zo gaan we kosten maken als we over de 1 GB aan dataopslag gaan, en duurt het herstarten van de applicatie bij een deployment ook een aantal minuten. Desalniettemin zijn we toch blij dat het goed lukt de kosten op 0 te houden.
In de volgende blog gaan we zien hoe we met Clean Architecture een module voor opslag neerzetten. Tot dan!
