Waarom Firebase een geweldige oplossing is om een MVP te bouwen

We gaan door met een reeks artikelen over het bouwen van MVP’s van technische producten, waarbij we al hebben besproken waar u moet beginnen en wat de mogelijke beperkingen (of het gebrek daaraan) zijn.

Om dieper in te gaan op het bouwen van platforms en applicaties vanaf nul, willen we u helpen bij het maken van degelijke keuzes van tools vanuit een technisch perspectief. Ongeacht waar uw product over gaat, u zult hoogstwaarschijnlijk gebruikersgegevens moeten opslaan of grote bestanden moeten delen. Vandaag zullen we Firebase evalueren als een mogelijke backend-oplossing voor uw project.

# Wat is Firebase

Ontwikkeld door Google, Firebase is een van de toonaangevende BaaS-oplossingen (Backend-as-a-Service) op de markt. Hiermee kunt u gegevens verbinden en delen tussen Android-, iOS- en webapplicaties. Het is een infrastructuur waarvoor geen servers nodig zijn en die kan worden geconfigureerd met een online webconsole. Met de realtime database van Firebase worden al uw gegevens in realtime gesynchroniseerd en kunnen ze nog steeds worden bewaard en offline worden verwerkt.

Gebaseerd op onze ervaring hebben we geconcludeerd dat Firebase bijzonder geschikt is voor het bouwen van MVP’s. We hebben de voordelen en de mogelijke obstakels op een lijst gezet om deze verklaring te bewijzen. Laten we eens kijken naar de details.

# Firebase advantages:

• Als Google-platform is het algemeen herkenbaar en dus makkelijker om aan klanten voor te stellen. Gezien de bekendheid van Google, vertrouwen klanten er onmiddellijk in.
• Het configureren van Farebase wordt snel uitgevoerd. Hiermee kunt u een snellere projectstart hebben en het kan ook ongeveer 2 keer sneller worden samengesteld dan de Python-backend.
• Terwijl u werkt, kunt u uw project in Firestore in de gaten houden, waar u gegevens in realtime kunt synchroniseren en bijwerken.
• Het komt ook met een aantal ingebouwde voordelen, die in de toekomst werkuren zullen besparen: geïntegreerde authenticatie (met gemakkelijke, veilige logins) en geïntegreerde hosting, inclusief HTTPS, enz.
• Hiermee kunnen schaalbare applicaties worden gebouwd. Het schalen van een service in Firebase betekent het vermenigvuldigen van het aantal geïmplementeerde functie-instanties.
• Het biedt ook prestatiebewaking om de prestaties van uw app te meten vanuit het oogpunt van de gebruiker, wat uiterst belangrijk is bij het werken aan een MVP.
• Met Firebase hoeft u zich geen zorgen te maken over de infrastructuur. U hoeft geen servers in te stellen, software op een lager niveau te upgraden, kwetsbaarheden te patchen, SSL-certificaten uit te geven, proxy’s en databases op te zetten, balancers en toezichthouders te loaden, enz.
• Hoewel Firebase zijn beperkingen heeft, is het product van Google, maar het wordt voortdurend ontwikkeld. Vandaag kunt u Cloud Functions lokaal testen, aangezien Firebase onlangs bèta-simulator Suite heeft geïntroduceerd, die er veelbelovend uitziet.
• U kunt elke complexe logica extraheren naar het bijbehorende exemplaar van Google Cloud.

Samenvattend, in de zeer vroege fase van het bouwen van uw MVP bent u waarschijnlijk op zoek naar een database die hoge snelheid garandeert, niet veel tijd kost om te leren, een iteratief proces mogelijk maakt en betaalbaar is voor een startend bedrijf. Veel van deze dingen zijn al voor u geregeld door Google Cloud Platform. Firebase voldoet dus aan deze criteria.

Laten we nu eens kijken naar mogelijke problemen bij het onderhouden van Firebase.

# Beperkingen van Firebase:

• Firebase bemoeilijkt het verwerken van complexe database-joins en het migreren van grote hoeveelheden gegevens. Hiermee moet rekening worden gehouden bij het bouwen van een complex project.
• Hoewel het schaalbaar is, kan het op een gegeven moment duurder worden om grote applicaties te bouwen.
• Koude start van functies. Het gebeurt als een Cloud-functie al een tijdje niet is aangeroepen en de achterliggende instance automatisch wordt afgesloten om gebruikte bronnen te minimaliseren. Na het afsluiten, wanneer Function voor de eerste keer wordt aangeroepen, kan het langzaam reageren (= koude start) terwijl de achterliggende instance opnieuw opstart.
• Op dit moment biedt Cloud Firestore geen migratie- / back-up mechanisme out-of-the-box.

Er is ook een drempel, waarna het gebruik van Firebase problemen en technische achteruitgang kan opleveren tijdens het proces, en we zullen dit uitgebreid behandelen in onze komende artikelen.

# Firebase als een tijdbesparende oplossing

Firebase is niet de enige tool op de markt en voor een startend product kan het keuzeproces een uitdaging zijn. We hebben voor alternatieve opties en hun kenmerken met betrekking tot de ontwikkelingsschattingen vergeleken met een echt voorbeeld.

Gegeven: Firebase, Django / Flask, AWS Amplify – opties voor het bouwen van webapplicaties.

Taak: het implementeren en uitvoeren van een client-server-webtoepassing genaamd «Hallo, wereld!».

Vereisten: HTTPS, browsercache, databaseverbinding, toegang tot implementatie via ssh / console.app, gegevenssynchronisatie met backend en een mogelijkheid om offline te werken.

Er is geen CMS- of beheerderspaneel-app om dezelfde gegevens te bewerken, wijzigen of maken als een mobiele applicatie kan.

Kortom, u heeft één bestemmingspunt en drie mogelijke transportmiddelen om daartoe te komen, die zullen verschillen in tijd en efficiëntie. Hier is wat u kunt verwachten in termen van duur met verschillende toolset.

1. Het project opzetten:

• Met zowel Firebase als Django / Flask duurt het ongeveer 3 tot 4 uur, inclusief projectskelet en implementatie.
• Met AWS Amplify verdubbelt dit aantal tot 8 uur, wat resulteert in formatiesjablonen voor elke module en een implementatiescript.

2. De authenticatie- en autorisatiefunctie toevoegen:

• Het kost absoluut geen tijd in Firebase, omdat de oplossing meteen met de bovenstaande functie wordt geleverd.
• Het duurt 6 tot 8 uur met Django / Flask om de autorisatiefunctie met wachtwoordreset en wijziging  toe te voegen.
• Met AWS Amplify kunt u de out-of-the-box autorisatie en het resetten / wijzigen van wachtwoorden binnen 4 uur afronden.

3. Data CRUD-bewerkingen met updates in realtime:

• Het duurt 2 uur om met Firebase te implementeren met behulp van SDK of 4 uur als CRUD Cloud eindpunten ondersteunt.
• Met Django / Flask duurt het 4 uur.
• Het zal evenveel tijd kosten met AWS Amplify met een paar regels in het GraphQL-schema en een paar resolvers in geval u AWS Appsync gebruikt.

4. Google Analytics:

• Komt zo meteen wanneer u Firebase gebruikt.
• Voor Django- en AWS-aanpak is extra inspanning nodig (2-4 uur).

5. Pushmeldingen voor uw gebruikers:

• Een berichtenserver is al inbegrepen als SDK in Firebase.
• Bij Django moet je een apart mechanisme opzetten.
• AWS heeft extra inspanningen nodig.

6. Servers monitoring en load monitoring:

• Ook inbegrepen in Firebase, kan ontwikkelaar / klant zelf grafieken bekijken.
• Bij Django is er een extra tijd (een paar uur) nodig om hiervoor service van derden in te stellen.
• AWS Amplify heeft zijn eigen dashboards, dus geen extra inspanningen nodig.

In totaal kunt u met Firebase 22 uur winnen vergeleken met Django / Flask en 18 uur in tegenstelling tot AWS Amplify. Als het gaat om tijdefficiëntie, neemt Firebase een stevige positie tussen Django / Flask en AWS Amplify.