Low code Master Detail CRUD application - Oracle alternative?

Er is behoefte aan master detail structuren voor de invoer van data inclusief eenvoudige lookup functies op gerelateerde data uit het datanodel. Daarnaast moeten klanten toegang krijgen om data zelfstandig in te kunnen voeren over een project. Bij voorkeur moet de klant ook bulksgewijs data kunnen uploaden waarbij zij zelf de mapping van kolommen definieren. Vandaar de eerdere interesse in de SVAR library met gridflexibilteit, ook hierarchische grids. Mogelijk dat Budibase dan te simpel is.

Helder — met master–detail invoer, lookup op relaties, hiërarchische grids én bulk upload met self-service kolom-mapping zit je al snel boven “standaard low-code CRUD”. En ja: Budibase gaat dan snel krap voelen (o.a. relationship pickers hebben ook praktische limits).

Wat dit betekent voor je platformkeuze

Je vraagt eigenlijk om 2 dingen tegelijk:

1. Sterk data-/rechtenfundament (datamodel, relaties, RBAC, tenant/project-scheiding)
2. Een rijke data-entry UX (master-detail + grids + import mapping)
   Die tweede is precies waar jouw SVAR + Svelte gedachte logisch wordt: grids/import UX is vaak het “product”, niet het platform.

Concrete richting die wél past

1) Directus als backend, SVAR/Svelte als frontend (sterkste “fit”)

Waarom: Directus is heel goed in datamodel + auth + API. Maar de ingebouwde import is vooral “CSV/JSON met headers die matchen”; echte interactieve mapping is beperkt/afwezig en je moet vaak je CSV al passend maken.

Wat je dan doet voor jullie use-case:

• Master–detail: je bouwt dit in je eigen UI (SVAR grid + detail pane/form) en schrijft via API naar Directus.
• Lookups: Directus API (REST/GraphQL) is ideaal voor “typeahead / search in related table” en constraints per project/klant.
• Bulk upload + mapping: bouw een import-wizard in Svelte:

Bonus: Directus ondersteunt bij CSV import ook dot-syntax voor nested/relational velden (handig als je wél via Directus-import wilt werken met voorbereide headers).

Kortom: Directus is je “4D/Qodly-achtige databasis + security layer”, en SVAR je “power UI”.

2) Oracle APEX (als je een alles-in-één RAD platform wilt met sterke grids)

APEX is berucht goed in data-entry schermen, master–detail, en “database-driven apps”. Qua kostenmodel is het interessant omdat Oracle expliciet stelt: als je al een Oracle Database licentie hebt, is APEX “zonder extra licentiekosten” te gebruiken, onafhankelijk van aantallen apps/gebruikers.

Maar: dit trekt je wél richting Oracle-ecosysteem (DB-keuze, skills, infra). Als jullie nu Postgres-minded zijn, is dit een grotere strategische stap.

3) Appsmith/ToolJet-achtige tools: bruikbaar intern, maar niet als “klantportaal met grid-superpowers”

Je kúnt master–detail/drilldown screens bouwen.
Maar voor jouw “SVAR-niveau” (hiërarchie, bulk mapping wizard, datavalidatie UX) ga je alsnog veel custom doen, en dan wordt het snel minder efficiënt dan gewoon Svelte bouwen.

Mijn advies (op basis van je extra eisen)

• Als de grid/import-ervaring een kernonderdeel is van jullie dienstverlening:
  → Kies een open, server-based backend (Directus + Postgres is hier heel logisch) en bouw het portaal in Svelte + SVAR.
• Als je echt maximale snelheid wilt zonder veel frontend-code en Oracle past strategisch:
  → Kijk serieus naar Oracle APEX (maar alleen als Oracle DB acceptabel is).

Heel praktisch: hoe je “bulk upload met mapping” slim ontwerpt

Ongeacht platform, dit patroon werkt bijna altijd goed:

• Import templates per klant/project (mapping opslaan)
• Match-strategieën (insert-only vs upsert op sleutel)
• Validatie-laag (required, datatype, referential checks, duplicates)
• Error feedback op rijniveau (download “fout-CSV” / toon grid met foutkolom)
• Async verwerking (queue) voor grote bestanden

Als je wil, kan ik een voorstel schetsen voor:

• een datamodel (Project → Orders → Lines etc. + tenanting)
• een import mapping flow (incl. lookup rules)
• en hoe je dat het best koppelt aan Directus (rollen/permissies per project/klant).

Klinkt als een logische keuze. Met Directus + Postgres als “model + security + API laag” en Svelte + SVAR voor de “power UX” krijg je precies de combinatie die je zoekt: kostencontrole, geen per-user lock-in, én maximale grid/import flexibiliteit.

Een paar heel concrete volgende stappen om dit snel goed te toetsen:

1) Directus datamodel aanpak voor master–detail

• Master (bijv. Project, Order, Levering) als collectie
• Detail (Orderregels, Taken, Deliverables) als child-collectie met M2O (many-to-one) terug naar master
• Lookups: zet waar mogelijk relaties + “display templates” slim neer (zodat je UI makkelijk kan zoeken/tonen)
• Performance: ontwerp met “filter per project/tenant” als harde basis, zodat elke query vanzelf scoped is

2) Klanttoegang en scheiding per project

Je hebt grofweg twee routes (beide werken, keuze hangt af van jullie commerciële model):

• Single-tenant per klant (simpel in rechten, maar meer infra-beheer)
• Multi-tenant (één instance, alles gescheiden via tenant/project veld + policies/permissions)

Voor “scale p” is multi-tenant meestal het meest kostenefficiënt, maar je moet het vanaf dag 1 netjes doen.

3) Bulk upload met mapping in Svelte

Ik zou dit als een eigen “import service” zien, los van Directus UI:

Flow die in de praktijk heel goed werkt

1. Upload bestand (CSV/XLSX) → parse in browser of server
2. Toon preview in SVAR grid (eerste 100–500 rijen)
3. Mapping UI: kolom → veld (met suggesties op naam/datatypes)
4. Per mapped veld: validatieregels + lookup rules (match op SKU / e-mail / extern ID)
5. Dry-run: toon fouten per rij + download error report
6. Commit: schrijf in batches (en bij grote imports async via queue/worker)
7. Sla mapping op als “template” per klant/project

4) Proof-of-concept checklist

Als je 1–2 weken effectief wilt testen (zonder “platform verdwalen”):

• Kunnen we in Directus het kernmodel + relaties snel en netjes neerzetten?
• Kunnen we RBAC zo instellen dat klanten alléén hun projectdata zien en bewerken?
• Krijgen we de master–detail UX in Svelte/SVAR soepel (select master → inline detail grid edit)?
• Werkt lookup/autocomplete performant (zeker bij grotere tabellen)?
• Kunnen we import-mapping + validatie zó bouwen dat klanten er zelfstandig mee overweg kunnen?
• Hoe borgen we audit/traceability (wie wijzigde wat, wanneer, via import of UI)?

Als je wilt, kan ik ook een “start-architectuur” uitschrijven (tabellen + relaties + rollen) op basis van jullie typische projecten/draaiboeken (Project → Deliverables → Taken → Resources, etc.), zodat je Directus-model meteen in één keer goed staat.

Zeker 👍 Hieronder een gerichte vergelijkingstabel met focus op jouw eisen en jullie context bij Meeples. Ik heb hem bewust praktisch gehouden, niet marketing-praat.

Vergelijking: Qodly (4D) vs Directus (+ Svelte/SVAR) vs Mendix (referentie)

Interpretatie in jullie context (Meeples)

Qodly / 4D – “alles-in-één RAD klassieker”

Sterk in:

• Datamodel + relaties
• Snelle interne tools
• Traditionele RAD-ontwikkeling

Maar voor jullie:

• Minder geschikt voor rijke data-entry UX
• Import/mapping is niet het natuurlijke domein
• Lock-in + licentiekosten drukken op schaal

➡️ Goed als je volledig in 4D wilt blijven. Minder goed als je product-achtig denkt.

Directus + Svelte/SVAR – “modern, open, data-centric”

Sterk in:

• Datamodel als fundament (zoals jij dat waardeert)
• RBAC + API perfect voor klantportalen
• Jij bepaalt de UX → grids, hiërarchie, imports, validatie
• Kosten voorspelbaar en laag

Realiteit:

• Je bouwt zelf de “slimme UI”
• Maar: precies dát is waar SVAR + jouw achtergrond uitblinkt

➡️ Dit is de meest congruente keuze met:

• jullie schaal
• jullie data-intensieve processen
• jouw technische profiel

Mendix (en Betty Blocks) – “enterprise citizen low-code”

Eerlijk:

• Technisch capabel
• Maar pricing + licentievoorwaarden botsen keihard met schaal p
• UX voor complexe grids/imports blijft beperkt

➡️ Strategisch ongunstig voor Meeples.

Samenvattend oordeel (kort en scherp)

• Qodly = sterk model, maar te gesloten en te weinig UX-flexibel
• Mendix/Betty = technisch oké, commercieel ongeschikt
• Directus + Svelte/SVAR = beste balans tussen
  modelgedreven werken, kostenbeheersing en product-UX

Als je wilt, kan ik in een volgende stap:

• een concreet voorbeeld-datamodel (Project → Deliverable → Items → Resources)
• of een schets van de import/mapping UX (stap voor stap)
• of een “wanneer doen we het in Directus UI vs wanneer in Svelte?” beslisregel

Zeg maar wat je handig vindt voor de volgende stap.

Goede en hele terechte vraag — dit is precies het punt waar veel mensen even afhaken bij Directus, omdat de positionering op de website wat misleidend is.

Kort antwoord:
👉 Ja, directus.io is de juiste leverancier.
👉 Nee, Directus is géén “CMS-only” en het klopt dat hun marketing dat te smal neerzet.
👉 Ja, je kunt er wél degelijk model-gedreven applicaties mee bouwen, maar niet op dezelfde manier als Qodly/4D.

Ik leg het scherp uit, want dit is een belangrijk onderscheid.

1️⃣ Waarom Directus zichzelf “Headless CMS” noemt (maar meer is)

Historisch gezien begon Directus als database wrapper met admin UI.
Marketing-wise is “Headless CMS”:

• begrijpelijk voor een groot publiek
• goed verkoopbaar

Maar technisch gezien is Directus eigenlijk:

Een model-driven data platform met auth, RBAC en API-generatie

Het “content” gedeelte is optioneel. Je kunt Directus gebruiken zonder ook maar één CMS-achtig concept (pagina’s, rich text, etc.).

2️⃣ Wat “model-gedreven” in Directus betekent (en wat níet)

❌ Wat Directus niet doet (t.o.v. Qodly / Mendix)

Directus:

• genereert geen applicatie-UI op basis van je model
• heeft geen workflow engine zoals BPM
• is geen RAD platform dat schermen voor je bouwt

Als je dat verwacht, voelt het inderdaad alsof “het model niks doet”.

✅ Wat Directus *wél model-gedreven doet

Dit is de kern, en dit sluit verrassend goed aan bij jouw eisen:

🔹 Datamodel = bron van waarheid

• Tabellen/collecties
• Relaties (M2O, O2M, M2M)
• Constraints
• Defaults
• Indexen

Alles visueel te beheren.

🔹 Datamodel → automatische API

Zonder code krijg je:

• REST endpoints
• GraphQL schema
• Filters, sorts, pagination
• Relational querying (nested!)

Dit is 100% model-driven gedrag, maar op API-niveau.

🔹 Datamodel → permissies

• RBAC per collectie
• Per veld
• Per actie (read/create/update/delete)
• Dynamische filters (bijv. alleen records met project_id in user.projects)

Dit is cruciaal voor jouw klant-per-project toegang.

🔹 Datamodel → admin UI

Directus genereert automatisch:

• formulieren
• relation pickers
• eenvoudige master-detail views

Niet voldoende voor jullie SVAR-grids, maar perfect als beheer- en fallback-UI.

3️⃣ Vergelijking met Qodly / 4D (belangrijk onderscheid)

👉 Qodly = model → applicatie
👉 Directus = model → API + security

Dat is een fundamenteel ander paradigma.

4️⃣ Hoe “model-gedreven applicatieontwikkeling” er bij jou uitziet met Directus

In jullie beoogde setup:

[ Directus ]
- Datamodel
- Relaties
- Validatie
- RBAC
- API (REST / GraphQL)
↓
[ Svelte + SVAR ]
- Master–detail grids
- Hiërarchische data entry
- Lookup UX
- Bulk import + mapping

Hier is het model nog steeds leidend, maar:

• het model stuurt data + rechten + API
• de applicatie-UX bouw je zelf

Dit is exact waarom Directus zo goed combineert met jouw SVAR-gedachte.

5️⃣ Waarom dit voor Meeples juist sterk is

Voor jullie use-case:

• Data-intensief
• Veel invoer
• Veel structuur
• Externe klanten
• Schaal p

Is dit vaak beter dan klassieke low-code:

• je vermijdt per-user licenties
• je voorkomt UI-beperkingen
• je houdt controle over performance en UX
• je kunt groeien zonder platformwissel

6️⃣ Eerlijke conclusie

Je gevoel klopt deels:

• ❌ Directus is geen Mendix / Qodly-vervanger
• ❌ Het bouwt geen applicatie voor je

Maar:

• ✅ Het is een zeer sterk model-gedreven backend platform
• ✅ Ideaal als fundament onder een maatwerk frontend
• ✅ Past uitstekend bij Svelte + SVAR + grid-heavy UX

Als je wilt, kan ik:

• een mini-voorbeeld uitwerken (datamodel → API → grid)
• een mentale vertaalsleutel geven: “Hoe denk ik in Directus als 4D/Qodly-denker?”
• of een beslisboom: wanneer iets in Directus hoort en wanneer in Svelte

Zeg maar wat je helpt voor de volgende stap.

Ja — Directus kan out-of-the-box items importeren uit CSV en JSON via de Admin UI. Dat doe je per collectie via Import / Export.

CSV en JSON (standaard, direct in Directus)

• Ga naar de collectie → Import / Export → kies bestand → Start Import.
• Het bestand zelf wordt niet opgeslagen als “asset”; alleen de geïmporteerde items komen in je collectie.
• Voor relaties werkt het in de basis door de ID van het gerelateerde record mee te geven in de relatie-kolom/veld.

Excel (XLSX)

Niet standaard als “direct import” in core Directus (de standaard import is CSV/JSON).
Maar: er bestaan Directus extensions waarmee je wél .xlsx kunt importeren, inclusief kolom-mapping.

Alternatief: importeren via de API (handig voor jouw mapping-wizard)

Als je in Svelte/SVAR toch een import-wizard bouwt (met kolom-mapping, validatie, dry-run), dan is de “nette” route:

• XLSX/CSV client-side of server-side parsen
• mappen → JSON payload
• POST naar /items/{collection} (batch/loop of via worker)
  Dit geeft je volledige controle over:
• foutafhandeling per rij
• upsert-strategieën
• lookup/match regels (SKU, e-mail, extern ID)
• audit logs

Als je wil, kan ik je een pragmatische aanpak geven voor “v1 import”: wat je in Directus standaard kunt laten (CSV/JSON) en wat je meteen in je Svelte import-wizard moet trekken (XLSX + mapping + validatie + upsert).

Dank voor je advies. De Oracle weg lijkt me te zwaar en ik ben niet enthousiast over de lockin. Ik ga de directus route wat verder verkennen in combinantie met de Svelte SVAR route. Een krachtig datamodel tool in Directus lijkt me erg interessant.Je stelde een vergelijkingstabel voor met oa Qodly. Zou je die willen maken.Voor directus kom ik op de site van directus.io terecht. Daar spreken ze over een headless content systeem. Is dit de juiste leverancier? Ik zie nog niet zo goed het model gedrerven applicatie ontwikkelen hierin. Klopt dit? \Ah dat verklaart al veel. Directus genereert dus wel al direct simpele basis UI voor basis CRUD acties begrijp ik. Meer geavanceerd bouwen we dat dan in Sveltekit met SVAR grids en components. IS het al wel mogelijk direct in Directus basis tabellen in te lezen vanuit een CSV-bestand, JSON-bestand of een Excelbestand?Nagedacht gedurende 5s