Website headless hosten met content delivery API

[semyazaruax]

Beste Tweakers,

ik wil een website gaan ontwikkelen waarbij performance (snelheid) centraal staat. Daarnaast moet hij schaalbaar zijn en moet de code base schoon (gescheiden) blijven.

Ik zou heel graag jullie mening willen horen. De opzet welke ik in gedachten heb is als volgt:

CMS om content te beheren per pagina. Alle logica wordt hier afgehandeld en pagina's worden in JSON formaat opgeslagen nadat alle berekeningen gedaan zijn.

API welke als doorgeefluik fungeert. Eigenlijk haalt deze alleen data op (GET). Eventueel een formulier dat gepost wordt, dat wordt door de API doorgegeven aan het CMS (endpoint van het CMS). De logica ligt dus ten alle tijden bij het CMS en niet de API.

VueJS (Nuxt) welke de frontend is geworden. Deze spreekt dus direct de API aan.

MariaDB database als opslag medium.

Het systeem is razend snel, pagina's worden bijna sneller dan het licht geladen, echter zullen veel mensen zeggen dat het niet slim is om een front-end te hebben die via een API communiceert met de database (POST, in het geval van niet doorsturen van een POST request naar het CMS) en tegelijkertijd een CMS hebben dat ook direct communiceert met de database.

Je hebt dan immers de mogelijkheid dat de API "A" opslaat als "1" terwijl het CMS dit als "2" doet. Je hebt dus "meer werk / onderhoud".

Zie onderstaand wat het schema momenteel is (als we het alleen over GET hebben dus zonder POST vanuit de frontend).



Dit is voor eens een ideale situatie in elk opzicht. Echter waar wij geen goed antwoord op hebben, is hoe gaan we een eventuele POST afhandelen? naar de API en deze sluist de request door naar het CMS waar het afgehandeld wordt?

Naar de API en deze handelt het af? wat is jullie kijk en ervaring hiermee?

[Ramon]

Op deze manier haal je jezelf wel heel veel extra werk op de hals, en dat alleen voor een beetje extra performance (wat ook nog twijfelachtig is als je het mij vraagt).

Betere performance haal je in de basis door minder over de lijn te gooien. Zo min mogelijk JS/CSS gebruiken, resources compressen, http/2, CDN's, server- en client-side caching goed instellen, etcetera...

En om toch je vraag te beantwoorden Gebruik een CMS met een ingebouwde API zodat deze één en hetzelfde zijn, scheelt een hele hoop kopzorgen.

[semyazaruax]

Dankjewel voor je antwoord Ramon en goede punten
In de testen blijkt dat de snelheid tussen de 20% en 40% hoger ligt dan wanneer ik direct met het CMS (of een ander bekend open-source CMS) verbind vandaar de keuze

Ook vinden we het fijn dat alles los is. Dus het CMS kan er tussen uit, de front-end, wat dan ook, de rest blijft werken. Wanneer de API in het CMS verweven zit, en we het CMS willen vervangen of er is storing in het CMS of de server waarop de CMS staat, dan ligt de hele applicatie er dus uit

De dingen die je aankaart worden sowieso gedaan en hebben ook altijd hoge prioriteit, maar we wilden net dat beetje extra er uit halen maar het is lastig om een goede en effectieve manier te vinden. Wat zoeken op het internet en je komt 50 verschillende typologieën tegen waarmee we echter nog niet veel ervaring hebben vandaar de vraag op het forum hier

Nogmaals dank voor je reactie, goede punten en ik neem ze zeker mee in mijn overweging!

[418O2]

Is het niet makkelijker om een site te maken die statisch is? Er zijn tegenwoordig legio cms'en die gewoon allemaal losse statische pagina's kunnen genereren.

[pachacuti]

Ramon schreef op donderdag 4 juli 2019 @ 20:32:
Gebruik een CMS met een ingebouwde API zodat deze één en hetzelfde zijn, scheelt een hele hoop kopzorgen.

Dit!

Het grote probleem van jouw opzet is dat bij elke upgrade van het CMS je API en dus ook je frontend waarschijnlijk stuk gaan zijn.
Indien het een groot CMS systeem is kan het serieus tegen vallen om te zien wat er juist overal gewijzigd is.

Ik heb dikwijls genoeg zo'n systemen gezien en na enige tijd komt het besef dat het gewoon onderhoud zeer veel tijd vraagt waardoor er gewoon gekozen wordt om het CMS niet meer te updaten, wat dan weer serieuze security issues met zich mee brengt

[Leknaas]

Kijk eens naar contentful. Dat is een api gebaseerd CMS. Ik heb er zelf een nodejs servetje tussen zitten met Jade voor de templates.

Als je het helemaal zelf wil knutselen. Dan pak je een front end framework met firebase. Dan hoeft er zelfs geen back end servetje tussen te zitten.

Kijk ook eens naar stenciljs ipv js frameworks. Zelf vind ik vuejs nogal ouderwets qua concept.

Gr Peter

[Tom]

semyazaruax schreef op donderdag 4 juli 2019 @ 21:19:

In de testen blijkt dat de snelheid tussen de 20% en 40% hoger ligt dan wanneer ik direct met het CMS (of een ander bekend open-source CMS) verbind vandaar de keuze

Maar dat is helemaal afhankelijk van de technieken die zowel de API als CMS gebruiken.

In principe doen ze beide exact hetzelfde: er is een serverside taal die wacht op een request, ze halen data uit een database of cache-laag en sturen het naar de client. De API verpakt die data in JSON/XML en het CMS in HTML. Waarbij de API-variant de eerste hit een tweetrapsraket is (eerst laad de client de HTML/JS en dan gaat er een call naar je API).

Ik schiet je keus niet af, maar als het echt om performance te doen is zou je beter zelf twee PoCjes op moeten zetten en gaan meten. Houd ook rekening met SEO als dat belangrijk voor je is, je content met een API ophalen is dan niet zo handig.

[BarôZZa]

Wat bedoel je met CMS? Is dat puur de applicatielogica(backend) of bedoel je het beheergedeelte voor de admins(dus losse front-end en backend aan die kant) en is de frontend het deel voor de bezoeker?

In het eerste geval lijkt me dit logischer:



In het tweede geval dit:



En wat bedoel je met performance? Wil je een zo snel mogelijke API? Of een frontend waarbij het voor de user lijkt alsof er geen laadtijden zijn?

Twee plekken die met de database communiceren is niet heel handig, dan krijg je logica op twee plekken(de CMS en API). Dat gaat dubbel werk en bugs opleveren.

[reddevil]

Het ligt eraan waarvoor het gebruik is. Wij gebruiken een soortgelijke architectuur, maar dat komt meer omdat een standaard CMS onze high traffic niet zomaar aankan op die manier. Oh ja en met 'high traffic' bedoel ik niet een paar duizend bezoekers per dag

999/1000 keer is het meer dan genoeg om gewoon een open source CMS te gebruiken die dit out-of-the-box kan... scheelt je enorm veel werk, hele community die updates en security patches voor je maakt. Vaak lijkt het voor developers "minder leuk of interessant" maar het scheelt zoveel werk voor uiteindelijk hetzelfde resultaat...

[ Voor 7% gewijzigd door reddevil op 19-07-2019 11:13 ]

[EnnaN]

Het kan zijn dat ik details mis, maar ben je nu niet gewoon een frontend cache aan het namaken? Kan je niet gewoon je CMS als CMS gebruiken zoals ie bedoelt is, en dan bv varnish er voor gooien om te cachen? Dan heb je ook je snelheidswinst omdat je alleen statisch uitserveerd, en kan je voor de rest gewoon geen problemen hebben....