Design vraag MERN stack

[the-edge]

Door mijn onervarenheid loop ik tegen een design vraag aan.

Ik zal proberen uit te leggen wat het plan is zoals ik deze nu in mijn hoofd heb:


Klantomgeving
Hier staat al een DB van een applicatie wat de bron is voor mijn data. De API is een Node.js/express backend API met authenticatie.

Eigen omgeving
Dit is zeg maar een nader te bepalen cloud omgeving (Azure/AWS/Google) wat nu minder relevant is. Hier draait een API, wederom node.js/express met een MongoDB voor user authenticatie. Om het MERN stack circkeltje rond te krijgen wil ik daar een React front-end bij.

De eindklant connect dus naar de React front-end, voor authenticatie raadpleegt de back-end van de React front-end, de mongoDB. Vervolgens praat de back-end van de eigen omgeving met de backend van de klantomgeving om requests en responses af te handelen.

Feitelijk heb ik dadelijk 3 apps draaien, maar is dit wel de best practice? Moet ik de react front-end samen voegen met de backend? Zodat ik 2 applicaties over houd? Zie ik wat over het hoofd? Of pak ik het misschien helemaal niet slim aan?

[n9iels]

Ziet er naar mijn idee niet direct uit als een heel vreemde architectuur. Je maakt hiermee een heel duidelijke scheiding tussen de data in je klantomgeving en eigen omgeving en combineert deze in 1 front-end. Ik denk dat je je alleen moet afvragen of dit echt nodig is.

Voordelen met deze opzet zijn dat beide API's los van elkaar schaalbaar en inzetbaar zijn. Daarnaast zou je een losse applicatie bijv. enkel tegen de klant API kunnen laten praten.
Nadelen zijn echter een toenemende complexiteit. Je moet veel dingen twee keer uitvoeren zoals de authenticatie, bijhouden van API documentatie/versiebeheer, OTAP omgevingen en deployments.

Stel jezelf dus de vraag of jou product groot genoeg is of kan worden om hier echt de voordelen van te benutten.

[the-edge]

n9iels schreef op donderdag 6 mei 2021 @ 10:36:
Ziet er naar mijn idee niet direct uit als een heel vreemde architectuur. Je maakt hiermee een heel duidelijke scheiding tussen de data in je klantomgeving en eigen omgeving en combineert deze in 1 front-end. Ik denk dat je je alleen moet afvragen of dit echt nodig is.

Voordelen met deze opzet zijn dat beide API's los van elkaar schaalbaar en inzetbaar zijn. Daarnaast zou je een losse applicatie bijv. enkel tegen de klant API kunnen laten praten.
Nadelen zijn echter een toenemende complexiteit. Je moet veel dingen twee keer uitvoeren zoals de authenticatie, bijhouden van API documentatie/versiebeheer, OTAP omgevingen en deployments.

Stel jezelf dus de vraag of jou product groot genoeg is of kan worden om hier echt de voordelen van te benutten.

Dank voor je feedback! Geeft de burger moed
Ik denk wel dat het nu onnodig complex is, maar de enige 'consolidatie' die ik mijns inziens kan maken is om de react front-end en de back-end in 1 app te duwen. Of zie jij andere mogelijkheden?

[matthijsln]

Bedoel je met 3 apps je frontend, API backend en MongoDB?

En dat je de statische frontend bestanden eerst op een cloud webserver gaat deployen (zoals Firebase hosting, AWS S3 of AWS Amplify) en bedoel je met consolideren dat je de statische frontend files served vanuit je Express server met express.static()?

Qua architectuur maken beide niet zoveel verschil. In eerste instantie lijkt me het samenvoegen logischer als je ze samen ontwikkelt: dan hoef je ook maar één ding te deployen. Veel maakt het niet uit want later weer splitsen kan ook, het blijven een losse frontend en backend.

Ik neem aan dat de frontend niet direct met de API van de klantomgeving kan praten en daarom je eigen backend nodig is? Anders zou je die ook nog weg kunnen laten.

[the-edge]

matthijsln schreef op donderdag 6 mei 2021 @ 22:30:
Bedoel je met 3 apps je frontend, API backend en MongoDB?

Nee, met 3 aps bedoel ik; customer-API, back-end-API en front-end.
De eigen back-end voorziet eigenlijk vooral in het user authenticatie gedeelte, ik wil namelijk de front-end multi-tenant maken.
Per ingelogde gebruiker kan deze dus, in het geval van meerdere klanten, een andere api aanspreken. Vandaar dat ik voor deze complexe, maar schaalbare oplossing heb gekozen.

Wellicht dat ik het eea nu simpeler maak en later, in de vorm van succes ga splitsen naar het uiteindelijke plaatje zoals hierboven.

[MarcoC]

Er bestaat geen slecht of fout antwoord, je moet alleen verschillende alternatieven overwegen en de kosten en baten in kaart brengen. Dit ziet er niet gek uit. Laat je vooral niet tegenhouden door designvragen. Meestal is de beste manier om erachter te komen wat juist is en wat niet, door het te ondervinden.

[killercow]

Authenticatie zou ik bij uitstek in een relationele database stoppen (des noods sqlite) ipv in een server als mongo, je data is namelijk relationeel, netjes genormaliseerd, en je wilt daar geen halve waarheden in hebben. Kortom je wilt een schema afdwingen. Afhankelijk van de aantallen kun je dan prima met sqlite of een andere simpele mysql db werken.

[the-edge]

killercow schreef op vrijdag 7 mei 2021 @ 14:38:
Authenticatie zou ik bij uitstek in een relationele database stoppen (des noods sqlite) ipv in een server als mongo, je data is namelijk relationeel, netjes genormaliseerd, en je wilt daar geen halve waarheden in hebben. Kortom je wilt een schema afdwingen. Afhankelijk van de aantallen kun je dan prima met sqlite of een andere simpele mysql db werken.

Dat is ook de twijfel die ik heb. Mijn ervaring met relationele databases (SQL) is dan ook vele malen groter dan bijv. een mongoDB. Voelt allemaal een beetje 'plat' aan. Thanks voor de tip!

[killercow]

the-edge schreef op vrijdag 7 mei 2021 @ 14:40:
[...]


Dat is ook de twijfel die ik heb. Mijn ervaring met relationele databases (SQL) is dan ook vele malen groter dan bijv. een mongoDB. Voelt allemaal een beetje 'plat' aan. Thanks voor de tip!

Er zijn voldoende goede redenen om voor een DB als mongo te willen gaan, maar ik mis eigenlijk in je hele uitleg/plaatje de argumenten voor alle keuzes die je hebt gemaakt. Bij autenticatie kon ik in ieder geval tegenargumenten vinden voor je keuze, maar er zijn er vast meer dan die (voor en tegen).

[Hydra]

killercow schreef op vrijdag 7 mei 2021 @ 14:48:
Er zijn voldoende goede redenen om voor een DB als mongo te willen gaan

Noem ze eens dan? Want document stores hebben eigenlijk verdraaid weinig use cases. En als je dan naar Elastic Search kijkt, dan is 'ie tenminste ergens beter in dan een relationele DB (search). Mongo is in letterlijk niks beter dan Postgres. Postgres benchmarks op JSON storage zijn zelfs beter dan die van Mongo. En Mongo sharding is een pain in the ass.

Mongo heeft veel aan marketing besteed door mensen te laten denken dat het heel snel is. Dat deden ze door gewoon default alle data integriteit opties uit te zetten. Sinds die tijd zit onder MongoDB 'gewoon' een relationele engine en is die snelheid weg.

Er zijn maar heel weinig redenen om voor een document DB te gaan. En er is eigenlijk nooit een reden om dan voor self-hosted Mongo te gaan.

[Hydra]

the-edge schreef op vrijdag 7 mei 2021 @ 14:40:
Dat is ook de twijfel die ik heb. Mijn ervaring met relationele databases (SQL) is dan ook vele malen groter dan bijv. een mongoDB. Voelt allemaal een beetje 'plat' aan. Thanks voor de tip!

Als ik jou was zou ik het hele Mongo verhaal vergeten zolang het nog kan en gewoon voor Postgres te gaan. Er is niks dat Mongo kan dat Postgres niet (beter) kan, en relationele databases zij sowieso veel flexibeler dan document stores. Vergeet niet dat de meeste data relationeel is.

[Hydra]

killercow schreef op vrijdag 7 mei 2021 @ 14:38:
Authenticatie zou ik bij uitstek in een relationele database stoppen (des noods sqlite) ipv in een server als mongo, je data is namelijk relationeel, netjes genormaliseerd, en je wilt daar geen halve waarheden in hebben. Kortom je wilt een schema afdwingen.

Absoluut. Sterker nog; relationele databases zouden de default moeten zijn. Je kunt altijd een secundaire store gebruiken voor 'moeilijke' dingen (search, caching, etc.). Maar daar ga je sowieso niet snel komen.

Afhankelijk van de aantallen kun je dan prima met sqlite of een andere simpele mysql db werken.

SQLite is niet geschikt voor stateless services, je kunt eigenlijk vrijwel altijd voor een 'echte' DB gaan. En dan is het sowieso aan te raden NIET voor MySQL te gaan, dat is tegenwoordig een commerciele database. Dan is de keuze nog tussen MariaDB en Postgres en dan zou ik voor de laatste gaan.

Het is erg maf eigenlijk dat MySQL zo populair is geworden t.o.v. Postgres.

[kwaakvaak_v2]

Hydra schreef op zaterdag 8 mei 2021 @ 12:09:
[...]


SQLite is niet geschikt voor stateless services, je kunt eigenlijk vrijwel altijd voor een 'echte' DB gaan. En dan is het sowieso aan te raden NIET voor MySQL te gaan, dat is tegenwoordig een commerciele database. Dan is de keuze nog tussen MariaDB en Postgres en dan zou ik voor de laatste gaan.

Het is erg maf eigenlijk dat MySQL zo populair is geworden t.o.v. Postgres.

Dat komt deels omdat postgres rond de eeuwwisseling nogal lastig was om even te installeren, in vergelijking met mysql. Voor veel mensen was een extra user met postgres als shell systeem best ingewikkeld, mysql was kwestie van download, install en klaar.

[RagingPenguin]

Hydra schreef op zaterdag 8 mei 2021 @ 12:09:
Het is erg maf eigenlijk dat MySQL zo populair is geworden t.o.v. Postgres.

kwaakvaak_v2 schreef op zaterdag 8 mei 2021 @ 17:05:
[...]


Dat komt deels omdat postgres rond de eeuwwisseling nogal lastig was om even te installeren, in vergelijking met mysql. Voor veel mensen was een extra user met postgres als shell systeem best ingewikkeld, mysql was kwestie van download, install en klaar.

En ook een beetje 'too little, too late'. Nu is Postgres zeker een veel betere database dan MySQL, maar voor je gemiddelde website maakt het nu ook al weer niet zo veel uit. Op het moment dat Postgres een goede optie werd was de LAMP stack al compleet ingeburgerd als de standaard voor web development. En aangezien dat iets als wordpress (en vele andere old-skool php knutselwerkjes) geen data-access abstractie laag hebben is switchen van database een ontzettende hoeveelheid werk en moet je we wel een hele goede reden voor hebben. Nou ja, eigenlijk hetzelfde verhaal waarom wp nog steeds php-mysql gebruikt i.p.v. php-mysqli. Er is zoveel code (zowel in de core als in plugins en thema's) direct afhankelijk van de exacte database provider dat een upgrade pracktisch niet mogelijk is.