Een webapp op maat bouwen met Next.js en Supabase

Wat de combinatie doet

Next.js is het raamwerk voor de site zelf: de pagina's, de navigatie, de snelheid. Supabase is de achterkant: de database, het inloggen, de opslag. Samen vormen ze een complete webapp zonder dat je losse servers hoeft te beheren. Voor een ondernemer is dat de kern van maatwerk: geen thema dat net niet past, maar precies wat je proces nodig heeft.

Het belangrijkste detail zit in de database. Supabase draait op PostgreSQL, een open databasesysteem dat al decennia bestaat en dat je overal kunt draaien. Je gegevens zitten dus niet opgesloten bij één leverancier. Wil je later weg, dan neem je de hele database mee. Dat klinkt als een technisch detail, maar het houdt een site over jaren heen overdraagbaar en onderhoudbaar.

Wat je uit de doos krijgt

Supabase is meer dan een database. Zodra je een project aanmaakt, staat er een complete achterkant klaar:

• Inloggen en accounts: met mailadres en wachtwoord, via Google of GitHub, of met een inloglink. Gebruikers en sessies zijn al geregeld.
• Een echte database: een volwaardige PostgreSQL-database met een visuele editor, waarin je gewone tabellen en relaties opbouwt.
• Toegangsregels in de database zelf, ook wel Row Level Security. Je legt per rij vast wie wat mag zien of wijzigen, op één plek in plaats van verspreid over je hele app.
• Realtime updates: wijzigingen komen direct binnen bij verbonden gebruikers, handig voor dashboards of chats.
• Bestandsopslag: afbeeldingen en documenten met dezelfde toegangsregels als de rest.
• Kleine serverfuncties: losse stukjes logica voor koppelingen, webhooks of geplande taken.

Hoe het werk verdeeld wordt

Onder de motorkap zit een duidelijke werkverdeling, en die bepaalt of een app snel en veilig is. Het loont om die op hoofdlijnen te begrijpen, ook als je zelf niet bouwt.

Het ophalen en tonen van gegevens gebeurt op de server. Een productpagina haalt de gegevens op voordat de pagina bij de bezoeker aankomt. Er is geen laadspinner, de inhoud staat er meteen.

Interactie gebeurt in de browser. Iets liken, een filter aanzetten, een formulier versturen. Daarvoor gebruikt de app een publieke sleutel. Die sleutel mag zichtbaar zijn, want de regels in de database bepalen wat er echt mag.

Bewerkingen met logica lopen via aparte serverroutes: validatie, berekeningen of acties met meer rechten. Daar hoort een geheime sleutel bij die alle regels mag overslaan. Die sleutel hoort nooit in de browser, alleen op de server. Zodra je iets berekent wat mensen niet mogen namaken, zoals een ranglijst of een score, doe je dat hier, buiten het zicht.

Waarom zo'n app snel is

Een veelgebruikte techniek is dat pagina's als statische bestanden worden opgeslagen en periodiek op de achtergrond worden ververst. De eerste bezoeker bouwt de pagina op, de rest krijgt een kant en klare versie die razendsnel laadt. Zo krijg je de snelheid van een statische site met inhoud die toch actueel blijft. Voor de meeste bezoeken raakt de app de database niet eens aan.

Ook zoeken hoeft niet ingewikkeld te zijn. Postgres kan met de juiste index verrassend snel door grote hoeveelheden gegevens zoeken, over veel filters tegelijk. Voor veel projecten is een aparte, dure zoekmachine simpelweg niet nodig, en dat scheelt weer een onderdeel om te beheren.

Waar het meestal misgaat

De meeste problemen zitten niet in het bouwen, maar in de beveiliging. Een fout die in de praktijk vaak terugkomt: de toegangsregels staan niet aan. Elke nieuwe tabel begint zonder bescherming. Zet je die regels niet aan, dan kan in theorie iedereen met de publieke sleutel meelezen of wijzigen. Het vervelende is dat je er niet vanzelf tegenaan loopt: de app geeft geen foutmelding, alleen een leeg resultaat, en je zoekt op de verkeerde plek.

De meeste beveiligingsproblemen ontstaan niet door slimme aanvallers, maar door regels die niemand heeft aangezet.

De tweede valkuil is de geheime sleutel die per ongeluk in de browser belandt. Die sleutel geeft volledige toegang tot de database. Belandt hij in de code die bezoekers kunnen inzien, dan ligt alles open. Hij hoort alleen op de server thuis.

Verder zijn er de openbare adressen die naar de database schrijven zonder rem erop. Bots en scrapers vinden ze vanzelf, en zonder limiet op het aantal verzoeken loopt je database vol met rommel. En elke beschermde route hoort bij elk verzoek te controleren wie er aanklopt, ook een adres dat nergens in je menu staat.

Waar de kosten in zitten

Over bedragen valt weinig zinnigs te zeggen zonder te weten hoe groot iets wordt. Wel is duidelijk waar ze zich ophopen. In het begin passen veel projecten binnen de ruime gratis grenzen van deze diensten. Je gaat pas betalen bij meer opslag, meer gebruikers of dagelijkse reservekopieën. De kosten groeien mee met het gebruik, niet andersom.

De echte rekening zit vaak ergens anders. Bij een traditionele opzet betaal je niet alleen voor servers, maar vooral voor het beheer ervan: updates, reservekopieën, beveiliging, koppelingen die stuk gaan. Die tijd is de eigenlijke kostenpost. Bij deze stack valt een groot deel daarvan weg. Je zet de code online en het draait, zonder server om in te loggen en zonder wildgroei aan losse onderdelen.

Let ook op verborgen kosten. Een gesloten platform lijkt goedkoop tot je wilt verhuizen. Omdat je gegevens hier in een gewone database zitten, blijft die stap open, ook over een paar jaar.

Wat dit betekent voor een bestaande site

De les voor een ondernemer is niet dat je dit zelf moet bouwen, maar welke vragen je stelt, ook bij een site die je laat overnemen of onderhouden. Zit mijn data in een systeem dat ik kan meenemen? Staan de toegangsregels aan? Is de gevoelige sleutel echt afgeschermd? Wordt er op de server gecontroleerd, of vertrouwt de app op de goede wil van de bezoeker?

Een webapp op maat is geen groot mysterie. Het is een klein aantal keuzes die goed of slecht kunnen uitpakken. Wie die keuzes begrijpt, kan beter beoordelen wat er gebouwd wordt, of een bestaande site goed in elkaar zit, en wat het waard is om te onderhouden.