[{"data":1,"prerenderedAt":181},["ShallowReactive",2],{"article-\u002Fblog\u002Fcloudconfig-a-backend-for-frontend-developers":3,"related-\u002Fblog\u002Fcloudconfig-a-backend-for-frontend-developers":26,"mdc-e50wcw-key":60},{"slug":4,"title":5,"description":6,"body":7,"category":8,"sources":9,"date":16,"tags":17,"language":23,"draft":24,"project":18,"path":25},"cloudconfig-a-backend-for-frontend-developers","cloudconfig: a backend for frontend developers","The idea behind Dennis Adriaansen’s cloudconfig project: keep models, validation, access rules and deployment connected.","\nIn a public post, I described a simple backend layer on Cloudflare, inspired by the ease of getting started with tools such as PocketBase and Supabase.\n\nThat is the direction behind cloudconfig. It is a beta project, currently built for Cloudflare. This article expands on the idea behind the post and the current project structure.\n\n## The repeated work is the problem\n\nA small application can need the same field described in several places: the database, validation, an API response, a form and a client type.\n\nSuppose a project record has a title and a published flag. When the title becomes required, the database and request validator need to agree. When only published records are public, the API needs an explicit rule.\n\nThe repetition makes even a modest backend harder to follow than it needs to be.\n\n## Let one model definition carry the shared contract\n\ncloudconfig uses a TypeScript backend definition to connect model declarations to migrations, validated routes, access rules and a typed client.\n\nThe goal is to keep those pieces aligned. It is still the developer’s job to decide what a model means and which operations the application should permit.\n\nA generated API is most useful when the rules behind it remain readable.\n\n## The frontend and an agent use the same boundary\n\nA dashboard might ask to update a record. A coding or application agent might propose the same update. Both requests should pass through the application’s server-side validation and permissions.\n\nA helpful interface can explain the proposed operation before execution. The backend must still reject an operation the caller is not allowed to perform.\n\nThat keeps the model’s business rules independent of the interface that happens to send the request.\n\n## Start with an actual deployment target\n\nCloudflare is cloudconfig’s current platform. Its services shape the present database and deployment integration.\n\nSupporting other clouds well means examining database behavior, storage, background work and runtime assumptions. I treat that as infrastructure work that needs explicit adapters and verification, rather than a setting that can make platforms equivalent by itself.\n\nFor current setup details, use [the cloudconfig docs](https:\u002F\u002Fcloudconfig.dev\u002Fdocs). The [project page](\u002Fprojects\u002Fcloudconfig) gives a concise overview of the work.\n","Backend & agents",[10,13],{"label":11,"url":12},"My public cloudconfig post on X","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2106081787013193818",{"label":14,"url":15},"cloudconfig documentation","https:\u002F\u002Fcloudconfig.dev\u002Fdocs","2026-10-12",[18,19,20,21,22],"cloudconfig","Cloudflare","TypeScript","backend","access rules","en",false,"\u002Fblog\u002Fcloudconfig-a-backend-for-frontend-developers",[27,43],{"slug":28,"title":29,"description":30,"body":31,"category":8,"sources":32,"date":16,"updated":16,"tags":36,"language":41,"draft":24,"path":42},"how-ai-changes-frontend-2025","MCP in een Nuxt-app: van vraag naar gecontroleerde actie","Dennis Adriaansen over MCP, tools en de scheiding tussen een AI-voorstel en een toegestane actie in je applicatie.","\nEen AI-model kan een actie voorstellen. Een applicatie moet bepalen of die actie klopt en is toegestaan. Dat onderscheid is een belangrijk uitgangspunt in mijn werk aan [cloudconfig](\u002Fprojects\u002Fcloudconfig) en [Nuxt Agentic](\u002Fprojects\u002Fnuxt-agentic).\n\nIk ben Dennis Adriaansen, in de Nuxt-community ook bekend als Dennis Adriaans. In dit artikel kijk ik naar MCP vanuit de ontwikkelaar die een werkende applicatie moet bouwen.\n\n## Wat MCP verbindt\n\nHet Model Context Protocol beschrijft hoe een AI-applicatie context en mogelijkheden van een server kan ontdekken en gebruiken. Een host beheert clients die met MCP-servers communiceren.\n\nEen server kan onder meer tools, resources en prompts aanbieden. Een tool voert een functie uit; een resource levert context; een prompt biedt een herbruikbaar uitgangspunt voor een interactie.\n\nDie verbinding vertelt de applicatie welke mogelijkheden er zijn. De concrete regels van je product blijven jouw verantwoordelijkheid.\n\n## Een voorbeeld: een project aanpassen\n\nStel dat iemand vraagt: “Zet dit project op afgerond.” Een mogelijke tool kan een projectstatus wijzigen, maar daarvoor zijn nog steeds een project-ID, een geldige status en een ingelogde gebruiker nodig.\n\nDe server controleert of de gebruiker dat project mag aanpassen. Vervolgens valideert de applicatie de nieuwe status en voert ze de wijziging uit. Een gevoelige wijziging kan eerst een zichtbare bevestiging krijgen.\n\nHet model hoeft die controles niet te vervangen. Het helpt om de vraag aan een concrete bewerking te koppelen.\n\n## Maak de grens leesbaar\n\nEen kleine tool met een duidelijke invoer is makkelijker te beoordelen dan een algemene functie die overal toegang toe heeft.\n\nLaat de interface tonen wat er gaat gebeuren. Laat de backend controleren of het mag. Leg daarna het resultaat vast, zodat een gebruiker kan zien of de bedoelde wijziging is uitgevoerd.\n\nZo blijft dezelfde applicatieregel gelden voor een knop in het dashboard, een API-aanroep en een voorgestelde actie van een agent.\n\n## Begin met één bruikbare handeling\n\nKies een afgebakende functie die je al begrijpt. Beschrijf haar invoer, bepaal de toegangsregels en test het resultaat buiten de modelinteractie.\n\nPas daarna krijgt de AI-interface er een betekenisvolle rol bij. Een protocolverbinding is het begin van de integratie; het productgedrag zit in de applicatie die je eromheen bouwt.\n\nLees meer over de infrastructuur op de [cloudconfig-projectpagina](\u002Fprojects\u002Fcloudconfig).\n",[33],{"label":34,"url":35},"Officiële MCP-architectuur","https:\u002F\u002Fmodelcontextprotocol.io\u002Fdocs\u002Flearn\u002Farchitecture",[37,38,39,40],"MCP","Nuxt","AI","tools","nl","\u002Fblog\u002Fhow-ai-changes-frontend-2025",{"slug":44,"title":45,"description":46,"body":47,"category":8,"sources":48,"date":16,"tags":52,"language":23,"draft":24,"project":58,"path":59},"scheduling-coding-agents-with-open-run","Scheduling coding agents with Open Run","The project behind local coding-agent schedules, with a focus on explicit tasks, visible changes and reviewable results.","\nA coding agent can help with a repeatable task, but someone still needs to say what should happen, where it should happen and how to check the result.\n\nOpen Run is my project for scheduling that work on a local machine. It uses coding-agent CLIs and connects their runs to projects, triggers, conversations and Git changes.\n\n## A schedule needs a precise instruction\n\n“Improve the project” leaves too many decisions open for an unattended run. A smaller instruction gives the result a clearer shape.\n\nFor example:\n\n> Inspect the failing date-formatting test. Explain the cause, make the smallest correction and run the relevant test. Leave the change available for review.\n\nThis is an example task, not a guarantee that the agent will fix it. Its value is that the goal, scope and verification step are visible.\n\n## Keep execution separate from acceptance\n\nA run can produce a change without deciding that the change belongs in production.\n\nThe diff is the bridge between the agent’s work and a developer’s judgment. The developer should be able to see which files changed and whether the checks relate to the original problem.\n\nA successful process exit alone does not establish that the application behaves correctly.\n\n## A local schedule has real operating conditions\n\nThe machine must be awake and the worker must be running for a schedule to fire. The selected CLI also needs to be available and configured.\n\nOpen Run does not require model API keys itself, but its agent CLIs still use their own subscriptions or provider configuration. “Local” describes where the orchestration runs; it does not mean the selected agent performs every model operation offline.\n\n## Make the history useful\n\nThe history of a run should help answer a few practical questions: what was requested, which agent ran, what changed and what was checked?\n\nThat is the reason I care about connecting instructions, conversations and diffs. It makes repeatable work easier to follow when someone returns to it later.\n\nRead the [Open Run repository](https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fopenrun) for current commands and runtime details, or visit [the project overview](\u002Fprojects\u002Fopen-run).\n",[49],{"label":50,"url":51},"Open Run README, CLI and security details","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fopenrun",[53,54,55,56,57],"Open Run","coding agents","automation","Git","scheduling","open-run","\u002Fblog\u002Fscheduling-coding-agents-with-open-run",{"data":61,"body":62},{},{"type":63,"children":64},"root",[65,73,78,85,90,95,100,106,111,116,121,127,132,137,142,148,153,158],{"type":66,"tag":67,"props":68,"children":69},"element","p",{},[70],{"type":71,"value":72},"text","In a public post, I described a simple backend layer on Cloudflare, inspired by the ease of getting started with tools such as PocketBase and Supabase.",{"type":66,"tag":67,"props":74,"children":75},{},[76],{"type":71,"value":77},"That is the direction behind cloudconfig. It is a beta project, currently built for Cloudflare. This article expands on the idea behind the post and the current project structure.",{"type":66,"tag":79,"props":80,"children":82},"h2",{"id":81},"the-repeated-work-is-the-problem",[83],{"type":71,"value":84},"The repeated work is the problem",{"type":66,"tag":67,"props":86,"children":87},{},[88],{"type":71,"value":89},"A small application can need the same field described in several places: the database, validation, an API response, a form and a client type.",{"type":66,"tag":67,"props":91,"children":92},{},[93],{"type":71,"value":94},"Suppose a project record has a title and a published flag. When the title becomes required, the database and request validator need to agree. When only published records are public, the API needs an explicit rule.",{"type":66,"tag":67,"props":96,"children":97},{},[98],{"type":71,"value":99},"The repetition makes even a modest backend harder to follow than it needs to be.",{"type":66,"tag":79,"props":101,"children":103},{"id":102},"let-one-model-definition-carry-the-shared-contract",[104],{"type":71,"value":105},"Let one model definition carry the shared contract",{"type":66,"tag":67,"props":107,"children":108},{},[109],{"type":71,"value":110},"cloudconfig uses a TypeScript backend definition to connect model declarations to migrations, validated routes, access rules and a typed client.",{"type":66,"tag":67,"props":112,"children":113},{},[114],{"type":71,"value":115},"The goal is to keep those pieces aligned. It is still the developer’s job to decide what a model means and which operations the application should permit.",{"type":66,"tag":67,"props":117,"children":118},{},[119],{"type":71,"value":120},"A generated API is most useful when the rules behind it remain readable.",{"type":66,"tag":79,"props":122,"children":124},{"id":123},"the-frontend-and-an-agent-use-the-same-boundary",[125],{"type":71,"value":126},"The frontend and an agent use the same boundary",{"type":66,"tag":67,"props":128,"children":129},{},[130],{"type":71,"value":131},"A dashboard might ask to update a record. A coding or application agent might propose the same update. Both requests should pass through the application’s server-side validation and permissions.",{"type":66,"tag":67,"props":133,"children":134},{},[135],{"type":71,"value":136},"A helpful interface can explain the proposed operation before execution. The backend must still reject an operation the caller is not allowed to perform.",{"type":66,"tag":67,"props":138,"children":139},{},[140],{"type":71,"value":141},"That keeps the model’s business rules independent of the interface that happens to send the request.",{"type":66,"tag":79,"props":143,"children":145},{"id":144},"start-with-an-actual-deployment-target",[146],{"type":71,"value":147},"Start with an actual deployment target",{"type":66,"tag":67,"props":149,"children":150},{},[151],{"type":71,"value":152},"Cloudflare is cloudconfig’s current platform. Its services shape the present database and deployment integration.",{"type":66,"tag":67,"props":154,"children":155},{},[156],{"type":71,"value":157},"Supporting other clouds well means examining database behavior, storage, background work and runtime assumptions. I treat that as infrastructure work that needs explicit adapters and verification, rather than a setting that can make platforms equivalent by itself.",{"type":66,"tag":67,"props":159,"children":160},{},[161,163,171,173,179],{"type":71,"value":162},"For current setup details, use ",{"type":66,"tag":164,"props":165,"children":168},"a",{"href":15,"rel":166},[167],"nofollow",[169],{"type":71,"value":170},"the cloudconfig docs",{"type":71,"value":172},". The ",{"type":66,"tag":164,"props":174,"children":176},{"href":175},"\u002Fprojects\u002Fcloudconfig",[177],{"type":71,"value":178},"project page",{"type":71,"value":180}," gives a concise overview of the work.",1794481660967]