DEV Community: Plopino

When AI-generated HTML needs a backend

Plopino — Sat, 24 Oct 2026 03:20:45 +0000

AI disclosure: I used AI assistance to draft and edit this article. I reviewed the technical claims against the browser documentation linked below and checked the examples for consistency. The code is intentionally simplified.

An AI assistant can produce a polished HTML demo in a minute. The page has buttons, calculations, a form, and maybe a chart. It looks like an application, so it is easy to assume that publishing the HTML also publishes everything behind it.

That last step needs a closer look. A static page can render, calculate, filter, animate, and remember a preference in one browser. It cannot safely hold a private API key, turn every visitor's browser into your shared database, or make a service running only on your laptop available to everyone else.

Here is the checklist I use to decide whether a generated page is ready for static hosting or needs a backend.

1. Ask where the data should go

This code can make a feedback form look finished:

const items = JSON.parse(localStorage.getItem('feedback') || '[]');
items.push({ message, createdAt: new Date().toISOString() });
localStorage.setItem('feedback', JSON.stringify(items));
render(items);

It preserves the current visitor's entries in that browser. It does not send them to the page owner, and another visitor will not see them. Browser storage is useful for a draft, a preference, or a local-only tool. It is not a shared submissions database.

There is another preview trap: the required behavior of localStorage for file: URLs is undefined and can vary between browsers. A result you see after double-clicking an HTML file is not a reliable test of what storage will do after deployment.

If you only need a visual demonstration, keep the data in memory or use a small fixture and label the action clearly: "Demo only — nothing is submitted." If someone must receive the submission, use an HTTPS endpoint and show what happened after the server responds.

2. Check whose computer `localhost` means

Generated code often contains a call like this:

const response = await fetch('http://localhost:3000/api/quote');
const quote = await response.json();

While you develop, that address can reach a server on your machine. After you send the page to somebody else, the same code runs in their browser. localhost then means their device, not yours.

A relative URL does not magically preserve your development backend either:

fetch('/api/quote');

On a static host, this normally asks that host for /api/quote. If no such endpoint exists, the page may receive a 404 or an HTML fallback instead of JSON.

For a self-contained demo, replace the request with explicit sample data and keep the simulated behavior visible. For live data, deploy an endpoint your visitors can reach, then test its response and CORS policy from the public page.

3. Remove secrets from the delivered files

A private credential does not become safe because it sits inside a JavaScript variable or an HTML comment:

// Simplified anti-example: never publish a real privileged credential here.
const response = await fetch('https://api.example.com/private-data', {
  headers: { Authorization: 'Bearer SERVER_ONLY_KEY' }
});

Every visitor can download the page and inspect its scripts. Obfuscation changes how the credential looks; it does not establish a secret boundary.

Before publishing, inspect the actual export directory rather than only the project root. A bundler can copy a secret into its output even when .env itself is excluded. Check inline scripts, source maps, generated configuration, fixtures, and comments too. Remove private customer data at the same time.

If a privileged API call is required, keep that credential on a server. The browser calls your limited endpoint; your endpoint validates the request and calls the upstream service:

// Server-side route sketch. Add authentication, validation, and rate limits for a real service.
export async function GET() {
  const upstream = await fetch('https://api.example.com/private-data', {
    headers: { Authorization: `Bearer ${process.env.SERVICE_API_KEY}` }
  });

  if (!upstream.ok) {
    // Do not pass an upstream secret or sensitive response through by default.
    return Response.json({ error: 'Upstream request failed' }, { status: 502 });
  }

  return Response.json(await upstream.json());
}

Some client-side API identifiers are deliberately public and can be restricted by origin or scope. That is a provider-specific design, so follow the provider's documentation. Do not treat a server credential as public just because the variable name contains KEY.

4. Test browser boundaries, not just the layout

A local file, a development server, and a public HTTPS page are different environments.

JavaScript modules loaded from file: URLs can trigger CORS errors. Test modules through an HTTP server, and make sure the server returns JavaScript files with a JavaScript-compatible MIME type. An apparently missing module can be a delivery problem rather than an import mistake.

For a public page that calls another origin, that server's CORS policy controls whether browser JavaScript may read the response. mode: 'no-cors' is not a general way to unlock JSON for your application. If you control the API, configure the origins it should serve; if you do not, a server-side integration may be the right boundary.

Also check for http:// dependencies in an HTTPS page. Browsers restrict mixed content, and fetch() requests to insecure resources can fail. Camera, microphone, service worker, and modern clipboard features have additional secure-context and permission requirements. http://localhost receives special treatment for development, which can hide a deployment problem.

Feature detection is more useful than assuming the preview and the public page have the same capabilities:

if (window.isSecureContext && navigator.clipboard?.writeText) {
  await navigator.clipboard.writeText(text);
} else {
  // Show selectable text and a clear manual-copy instruction.
  showManualCopy(text);
}

5. Make the static/backend split explicit

A static page is a good fit when the result depends on the current visitor's input and public assets: a calculator, a proposal preview, a chart from bundled data, or a small editing tool whose output can be downloaded.

Add a backend when the product needs shared state or authority: submissions that another person must read, accounts and permissions, shared edits, private upstream credentials, privileged actions, or durable data across visitors and devices.

Before sharing the page, run this short review:

Open the public URL while logged out, ideally on a second device. Test one important interaction and a narrow screen.
Inspect the Network panel during that interaction. Check the final URL, status, response type, CORS errors, and mixed-content errors.
Search the delivered files for private data and credentials. Do not publish the whole source directory when only the built output is meant to be public.
Submit the form and explain where the data went. Distinguish a local simulation from a server-confirmed submission.
Check clipboard, camera, microphone, and offline behavior under the real deployment protocol. Provide a usable fallback when a capability is unavailable.

The goal is not to add a backend to every generated page. It is to make the page honest about where computation, data, and authority live. Once those boundaries are clear, static hosting can stay simple without pretending to provide server behavior.

References

What an anonymous feedback inbox should store — and what it should not

Plopino — Fri, 23 Oct 2026 14:29:53 +0000

AI disclosure: I used AI assistance to draft and edit this article. I checked the code excerpts against the production codebase, ran the relevant tests locally, and stand behind the technical claims below.

Plopino is a small static host that accepts anonymous HTML uploads. That works for the sending side and leaves a hole on the receiving side: until this week, someone who hit a bug only had an abuse email address.

On October 20 I shipped an in-site feedback inbox: a form that does not require login, and an admin inbox where I read and answer messages. This post covers the tradeoffs I chose, including the cases the happy path does not show.

Why build it into the product

An external form would have taken an afternoon, but it adds another data origin, a third-party script, and a privacy-policy paragraph. The product already accepts anonymous uploads, so the contact channel had to accept the same audience.

I cut the rest: no notifications, no attachments, no categories, and no state beyond new, read, and archived.

Check cheap signals before spending quota

The endpoint is public and the rate limit is daily. The order matters: check cheap automation signals, then validate the input, then consume quota. A typo should not burn the allowance of someone acting in good faith.

// POST /api/feedback — trimmed, imports and the insert omitted
if (body?.website != null && String(body.website).trim() !== '') {
  return sendJson(res, 200, { ok: true });
}
const startedAt = Number(body?.startedAt);
if (Number.isFinite(startedAt)) {
  const elapsed = Date.now() - startedAt;
  if (elapsed >= 0 && elapsed < 2000) return sendJson(res, 200, { ok: true });
}
const message = typeof body?.message === 'string' ? body.message.trim() : '';
if (!message) return sendJson(res, 400, { error: tErr(req, 'error.feedbackRequired') });
if (message.length > 4000) return sendJson(res, 400, { error: tErr(req, 'error.feedbackTooLong', { n: 4000 }) });
const daily = consumeDailyQuota(gwdb, `feedback:ip:${clientIp(req)}`, feedbackDailyLimit);
if (!daily.allowed) return sendJson(res, 429, { error: tErr(req, 'error.feedbackRateLimited') });

website is a hidden honeypot that a person will not fill. startedAt is recorded when the page opens; less than two seconds to submit is a script signal. Both checks return 200 with ok: true, because an explicit error would tell automation which rule to avoid.

The silence has a cost: a very fast human can lose a message without knowing. A clock that is ahead also becomes a real edge case. Future timestamps therefore follow the normal flow rather than being treated as suspicious.

With no captcha, the limit is the main defense: ten messages per IP per day, stored in the same database as the upload quota and reset at the UTC day boundary. Signed-in users share the IP bucket, so a shared network splits those ten messages between everyone.

Render nothing as HTML

Messages and replies are stored as they arrive, without an HTML sanitizer. Feedback is not a page. The rendering rule is simpler than cleaning arbitrary HTML: text from the inbox always goes into the textContent of a DOM-created element, never string-concatenated into innerHTML.

const msg = document.createElement('p');
msg.className = 'fb-msg';
msg.textContent = item.message;

The admin reply renders the same way. pageUrl accepts only an internal path; absolute URLs, protocol-relative URLs, and backslashes become NULL, with a 300-character cap. An admin UI test reads the HTML and fails if the message body lands in innerHTML.

This choice moves the risk rather than removing it. Safety depends on every future renderer following the same rule. That is why the test checks the rendering path, not just the database layer.

Three audiences, three permission levels

Submission is public. "My feedback" requires a session, filters by user_id, returns at most 20 rows, and omits email and the admin's name. Every admin endpoint requires the admin role. Status is a closed list; replies are capped at 4,000 characters; an empty reply clears the existing one.

Those APIs return Cache-Control: private, no-store, and the public form carries noindex.

The known limit: an anonymous sender gets a reply only if they leave an email. A one-time lookup link was cut because it would add another state machine for the same problem.

What one row keeps

A row holds the message, an optional email, the internal page path, and, for a signed-in sender, a reference to the account plus the username at submission time.

It does not store IP or User-Agent. Abuse control uses a daily per-IP counter and resets it the next day. The analytics event contains no message text and no email; it records only the path and whether the sender was signed in.

Writing down what the inbox must not store was more useful than choosing a schema first. The omissions reduced what had to be protected, exported, or explained later.

Translations are data with contracts

The UI already supported 20 languages. The inbox added 32 keys, translated into the other 19 languages, and localized the server errors so a 429 arrives as "too many messages today" instead of a bare code.

The structural test compares every dictionary with English on three axes: the key set, key order, and placeholder names. It does not guarantee translation quality. The 19 versions are AI-assisted and have not all been reviewed by native speakers, but no raw key reaches the screen without a failing test.

What the tests cover

I ran the 13 feedback test cases: validation, the honeypot and minimum fill time, the shared per-IP limit, isolation of "my feedback", admin permissions, replies, deletion, and 404 responses. I also ran the 4 admin UI tests; one fails if the message body goes through innerHTML.

Those tests check the code, not real traffic. There is no browser visual test yet, and I will understand shared-network behavior from the inbox itself.

The design decision I would repeat: define the data the inbox must not keep before choosing the database or building the UI. The implementation then has less to forget later.

This article is a canonicalized cross-post of the original in my engineering notes: Adding feedback to an account-free service: what the inbox does not store.

Preço certo, prazo antigo: como conferir as transições de uma proposta em HTML

Plopino — Fri, 02 Oct 2026 12:38:09 +0000

Uma proposta interativa pode mostrar o preço certo e, ao mesmo tempo, manter o prazo da opção anterior. É fácil não perceber isso quando cada botão é conferido separadamente.

Ao organizar um exemplo pequeno em HTML e JavaScript, o critério foi fazer preço, prazo e entregáveis saírem da mesma combinação de dados. São dois pacotes e duas revisões, com valores fictícios.

Primeiro, saber de onde vem cada resposta

O estado guarda as escolhas, não o resultado:

let revision = "first";
let plan = "essential";

Uma tabela contém as quatro combinações. Este recorte usa números em USD apenas para ilustrar o modelo, sem conversão para reais:

const proposals = {
  first: {
    essential: { price: 4800, weeks: 3 },
    complete: { price: 7200, weeks: 4 }
  },
  revised: {
    essential: { price: 5400, weeks: 4 },
    complete: { price: 8100, weeks: 5 }
  }
};

O registro atual é proposals[revision][plan]. Não existe uma variável extra para o preço, nem outra para o prazo. Assim, há menos valores que precisam ser mantidos em acordo.

O evento escolhe; a renderização atualiza

Em vez de cada botão atualizar um pedaço da página, os eventos mudam uma escolha e chamam a mesma função render().

No exemplo completo, essa função atualiza o resumo, reconstrói a lista de entregáveis e ajusta aria-pressed dos dois grupos de botões. Os textos entram com textContent, sem serem interpretados como HTML.

Isso também evita um comportamento estranho: trocar a revisão não volta o pacote para o básico. Quem está comparando o pacote completo continua nele. Só a revisão muda.

Essa escolha deixa a comparação mais fácil de acompanhar. Se um pacote não estiver disponível em uma revisão futura, a interface precisará tratar e explicar esse caso.

Conferir quatro resultados e depois percorrer o caminho

A tabela esperada é pequena:

Revisão	Pacote	Valor fictício (USD)	Prazo
Inicial	Básico	4800	3 semanas
Inicial	Completo	7200	4 semanas
Revisada	Básico	5400	4 semanas
Revisada	Completo	8100	5 semanas

Conferir essas linhas ajuda a encontrar um dado errado. Mas a interface tem memória entre os cliques: algum elemento pode ficar com o conteúdo da seleção anterior.

Por isso, vale percorrer Completo → Revisada → Básico → Inicial sem recarregar a página.

Em cada etapa, confira:

se o preço e o prazo correspondem à mesma combinação;
se a lista de entregáveis foi atualizada;
se o pacote escolhido foi mantido ao trocar a revisão;
se os dois grupos mostram o estado selecionado correto.

Não é preciso transformar esse exemplo em uma aplicação grande para conferir isso. Uma sequência curta já revela mais do que abrir cada combinação isoladamente.

O teclado também precisa entrar na conferência

Os controles usam elementos button. Tab muda o foco; Enter e Espaço ativam o botão. aria-pressed expõe a seleção.

O resumo usa aria-live="polite" e aria-atomic="true", para disponibilizar a atualização completa às tecnologias assistivas. Ainda é necessário conferir o comportamento nos leitores de tela usados pelo público; esses atributos, sozinhos, não garantem que toda a experiência esteja boa.

Prévia não é publicação

As duas revisões já estão no arquivo. O botão alterna o que aparece, sem salvar nem atualizar a página hospedada.

Por isso, “prévia da revisão” descreve melhor a ação. Para atualizar o conteúdo público, é necessário enviar o arquivo alterado e conferir o endereço que será compartilhado.

O exemplo ficou pequeno porque tem uma tarefa limitada: comparar escopo sem separar preço, prazo e entregáveis. A parte interessante é conferir se essa promessa continua verdadeira depois de vários cliques.

O artigo original em inglês traz o HTML e o JavaScript completos para reproduzir o exemplo. Aqui, o foco foi o raciocínio por trás da verificação das transições.

Vocês costumam testar os estados isolados primeiro ou já começam pelos caminhos que a pessoa pode percorrer?

Cambiar la versión de una propuesta sin perder el paquete elegido

Plopino — Fri, 02 Oct 2026 12:36:37 +0000

Al comparar dos versiones de una propuesta, ya hay bastante que recordar. Si cambio de versión y la página también cambia el paquete que había elegido, termino comparando dos cosas a la vez.

Ese detalle fue uno de los criterios al ordenar un pequeño ejemplo en HTML y JavaScript: dos paquetes, dos revisiones y un resumen con precio, plazo y entregables. Los importes son ficticios.

Dos decisiones, no cuatro botones independientes

La selección cabe en dos variables:

let revision = "first";
let plan = "essential";

Cambiar la revisión modifica únicamente revision. Cambiar el paquete modifica únicamente plan. No hay una razón para reiniciar la otra elección.

Un ejemplo mínimo de los datos sería este. Los importes están expresados en USD, solo para ilustrar la estructura:

const proposals = {
  first: {
    essential: { price: 4800, weeks: 3 },
    complete: { price: 7200, weeks: 4 }
  },
  revised: {
    essential: { price: 5400, weeks: 4 },
    complete: { price: 8100, weeks: 5 }
  }
};

function currentProposal() {
  return proposals[revision][plan];
}

El resultado se deriva de la selección. Guardar también el precio como estado crearía otra cosa que mantener sincronizada.

Un solo sitio para actualizar la interfaz

La tentación es poner un poco de lógica en cada botón: este cambia el precio, aquel cambia el plazo, otro reconstruye la lista. Cuesta ver si todos terminan dejando la página en el mismo estado.

La alternativa del ejemplo es que cada evento actualice una variable y llame a render(). Esa función obtiene el registro de la combinación actual y actualiza el resumen, los entregables y aria-pressed de los botones.

Para los textos se usa textContent. Un entregable es texto; no hace falta interpretarlo como HTML.

Hay una consecuencia útil: si estoy viendo el paquete completo y paso a la revisión, sigo viendo el paquete completo. El precio puede cambiar porque cambió el alcance, pero mi selección permanece.

Una tabla correcta no garantiza una transición correcta

Estos son los cuatro resultados esperados:

Revisión	Paquete	Precio ficticio (USD)	Plazo
Inicial	Básico	4800	3 semanas
Inicial	Completo	7200	4 semanas
Revisada	Básico	5400	4 semanas
Revisada	Completo	8100	5 semanas

Comprobar cada fila sirve para revisar los datos. Después conviene recorrer una secuencia:

Completo → Revisada → Básico → Inicial.

En cada paso, hay que comparar el precio, el plazo, los entregables y el estado seleccionado de ambos grupos. Así también se busca contenido que se haya quedado de la selección anterior.

Los controles son botones nativos. Se puede recorrer la interfaz con Tab y activarlos con Enter o Espacio. aria-pressed comunica la selección y una región aria-live="polite" anuncia el resumen. Eso no sustituye una prueba con lectores de pantalla.

El nombre del botón también forma parte del comportamiento

Las dos revisiones ya están en el archivo. El selector las muestra: no guarda cambios ni publica una actualización.

Llamarlo “vista previa de la revisión” ayuda a entender esa diferencia. Para modificar una página alojada, todavía hay que subir el archivo cambiado y comprobar el enlace público.

Es un detalle pequeño, pero el control no debería prometer una acción que no ha ocurrido.

La versión en inglés con el HTML y JavaScript completos incluye el ejemplo reproducible. Esta versión se centra en el criterio de conservar las elecciones durante la comparación.

¿En qué casos sí tendría sentido reiniciar el paquete al cambiar de versión? Por ejemplo, si un paquete deja de existir, haría falta explicar ese cambio en lugar de aplicarlo en silencio.

A tiny HTML proposal with two switches and one render function

Plopino — Fri, 02 Oct 2026 11:44:42 +0000

A proposal can look perfectly reasonable until you change one option. The price updates, but the delivery time still belongs to the old plan. Now the page is giving two different answers.

That is the small problem this example tackles: two packages, two revisions, and one consistent summary. It uses ordinary HTML and JavaScript. The company details and estimates are fictional.

The useful part is the shape of the state. You can reuse it for a quote calculator, a package comparison, or a project scope preview.

Keep the choices separate from the result

There are only two choices:

let revision = "first";
let plan = "essential";

The estimate is derived from those choices. It does not need another state variable.

const proposals = {
  first: {
    essential: {
      price: "$4,800", weeks: 3,
      items: ["Five responsive pages", "Contact form"]
    },
    complete: {
      price: "$7,200", weeks: 4,
      items: ["Five responsive pages", "Contact form", "Project gallery"]
    }
  },
  revised: {
    essential: {
      price: "$5,400", weeks: 4,
      items: ["Five responsive pages", "Booking flow", "Accessibility review"]
    },
    complete: {
      price: "$8,100", weeks: 5,
      items: ["Five responsive pages", "Booking flow", "Accessibility review", "Project gallery"]
    }
  }
};

Each combination has a complete record. That makes it possible to inspect the numbers and scope together before touching the interface.

These are fixed example estimates. A real pricing tool would need its own rules for currency, tax, and calculations.

Give every change the same path through the DOM

Here is the markup. Put it in the body of an HTML page, with the JavaScript below it in a script element.

<h1>Website proposal</h1>
<p>Fictional estimates for a scope comparison.</p>

<div role="group" aria-label="Proposal revision">
  <button type="button" data-revision="first" aria-pressed="true">First draft</button>
  <button type="button" data-revision="revised" aria-pressed="false">Revised scope</button>
</div>

<div role="group" aria-label="Choose a package">
  <button type="button" data-plan="essential" aria-pressed="true">Essential</button>
  <button type="button" data-plan="complete" aria-pressed="false">Complete</button>
</div>

<p id="summary" aria-live="polite" aria-atomic="true"></p>
<ul id="deliverables"></ul>

Both sets of buttons change a choice and call the same function:

function render() {
  const proposal = proposals[revision][plan];
  const revisionLabel = revision === "first" ? "First draft" : "Revised scope";
  const planLabel = plan === "essential" ? "Essential" : "Complete";

  document.getElementById("summary").textContent =
    `${revisionLabel}, ${planLabel}: ${proposal.price}; ${proposal.weeks} weeks.`;

  document.getElementById("deliverables").replaceChildren(
    ...proposal.items.map(item => {
      const li = document.createElement("li");
      li.textContent = item;
      return li;
    })
  );

  document.querySelectorAll("[data-revision]").forEach(button => {
    button.setAttribute("aria-pressed", String(button.dataset.revision === revision));
  });
  document.querySelectorAll("[data-plan]").forEach(button => {
    button.setAttribute("aria-pressed", String(button.dataset.plan === plan));
  });
}

document.querySelectorAll("[data-revision]").forEach(button => {
  button.addEventListener("click", () => {
    revision = button.dataset.revision;
    render();
  });
});

document.querySelectorAll("[data-plan]").forEach(button => {
  button.addEventListener("click", () => {
    plan = button.dataset.plan;
    render();
  });
});

render();

The click handlers are deliberately boring. They do not calculate prices, rewrite individual list items, or decide which buttons should look selected. Those changes happen together in render().

Selecting Complete and then Revised scope keeps Complete selected. Switching the revision does not quietly reset the package. That behavior follows directly from keeping the choices separate.

Using textContent also means a deliverable is inserted as text, rather than interpreted as HTML. If this later reads external data, that is a useful boundary to preserve.

Check the combinations, then the transitions

There are four expected results:

Revision	Package	Price	Delivery
First draft	Essential	$4,800	3 weeks
First draft	Complete	$7,200	4 weeks
Revised scope	Essential	$5,400	4 weeks
Revised scope	Complete	$8,100	5 weeks

Checking each row catches incorrect data. Checking a sequence catches stale UI. Try Complete → Revised scope → Essential → First draft, and compare the summary, deliverables, and pressed button states after each step.

Then use only Tab, Enter, and Space. Native buttons provide the keyboard interaction; aria-pressed exposes the selected state. The polite live region makes the combined price and delivery summary available to assistive technology. That is a starting point, and it still needs testing with the screen readers and browsers your audience uses.

A revision preview needs an honest label

Both revisions in this page are already in the JavaScript object. The switch previews them. It does not save anything, publish a new version, or update a hosted page.

That distinction matters when sharing a prototype. Label the control as a preview, keep the estimates fictional, and test the actual public URL after deployment. A working local file cannot tell you whether the recipient's link works.

The page stays small because it has a small job: let someone compare scope without allowing the price, timeline, and deliverables to drift apart.

AI disclosure: This article and the adapted code example were generated by an AI agent from an existing HTML example. The example was checked in a browser before publication.

MCP or CLI? Choose by Who Controls the Workflow

Plopino — Thu, 24 Sep 2026 02:21:10 +0000

Suppose a tool can publish a built site. Should it offer a command line interface, an MCP server, or both?

The tempting answer is “MCP for AI, CLI for humans.” That is too simple: agents can run commands, and people can ask an MCP client to call tools. A better question is who decides the next step, and where does the data live?

Start with the caller

Choose a CLI when the caller already has a repeatable sequence: build, test, publish, inspect the result. A shell script or CI job can pass a path, use an exit code to detect failure, and parse JSON when it needs a URL or identifier. The command is also easy to run and debug locally.

# Illustrative command, not a package name
publisher publish ./dist --json

Choose an MCP tool when an assistant needs to discover an operation and call it as part of a conversation. A tool such as publish_page can declare that it accepts content and filename, then return a structured result. The assistant can use that result in its next step. MCP gives the client a standard way to list and call tools; it does not make a publication automatically safe or correct.

Situation	Starting point
A fixed deployment job publishes the same build output	CLI
A developer wants one command after a local build	CLI
An assistant drafts a small page and asks to publish it	MCP tool accepting content
An assistant works with a local directory and its assets	Local MCP tool accepting a path, or CLI
A remote assistant has no access to the developer's disk	MCP tool accepting file contents or another upload mechanism

These are starting points, not hard boundaries. If an agent already has a reliable terminal, invoking the CLI may be the simplest integration. If an application already speaks MCP, a tool can avoid teaching the assistant command syntax and output parsing.

Location matters more than the interface name

Consider a tool argument like publish_path({ path: "./dist" }). With a local MCP server launched over stdio, the server process can usually read that directory. With a remote MCP server over HTTP, ./dist means a path on the server, not the user's laptop. The same string has different consequences depending on the transport.

For a remote client, send the contents explicitly, or upload them through an API that provides a file handle to the server. For a local directory with many related assets, a local tool or CLI is often a better fit. The MCP transport documentation describes stdio and Streamable HTTP; the filesystem boundary follows from where each server runs.

Design the failure path, too

A useful CLI needs stable exit codes, script-friendly output, and a way to provide credentials without an interactive prompt. Keep human progress messages separate from machine-readable output. A useful MCP tool needs a precise input schema and a result that tells the client what succeeded or failed. For a stdio MCP server, stdout is the protocol channel, so ordinary logs belong elsewhere.

Publishing also deserves the same controls through either interface: make the destination clear, inspect what files will leave the machine, keep secrets out of the published bundle, and avoid returning a private claim or edit link as the public viewing URL. If an operation replaces an existing page, make that intent explicit in the arguments or flags.

If you offer both, share the operation

The two interfaces can sit on top of one publishing function. The CLI handles flags, terminal output, and exit codes. The MCP adapter handles tool definitions and structured results. Authentication, upload rules, size limits, and update behavior should come from the shared operation, so the two entry points do not quietly disagree.

My rule of thumb: use a CLI for a known sequence; use MCP when a tool-aware client is choosing actions; use a local interface for local paths. Then add the second interface only when a real caller needs it.

How do you draw that line in your own tools? Have you found cases where an agent calling a CLI works better than an MCP integration?

AI disclosure: An AI assistant drafted this article. The technical distinctions were checked against the MCP transport documentation and an implementation that exposes both CLI and MCP entry points. This post is intended as a discussion of interface design, not a product recommendation.

Things that were harder than expected building a drag-and-drop static host

Plopino — Tue, 15 Sep 2026 15:01:44 +0000

I built a small static host (plopino.com) with a boring
premise: drag a file onto a page, get a link. No account for the basic flow.

The feature list is short. What took the time was a handful of specific
problems. Here they are, in case they save you the same afternoon.

1. Path-based hosting means every relative link is your problem

Most drop-style hosts give each project a subdomain:
my-project.host.com. I went the other way. Every board lives under a path:

https://plopino.com/b/<boardId>/...

One route serves it. One TLS certificate. No per-board DNS, no wildcard cert
renewal, no waiting on propagation — the whole routing and TLS story stays
simple.

The bill comes due on relative links. A board is arbitrary user HTML, so a page
at /b/<id>/sub/page.html can contain anything:

<a href="../../other.html">
<img src="//cdn.example.com/x.png">
<a href="/absolute/path">
<a href="javascript:void(0)">

I need to know which of those stay inside the board and which don't, because
that decision drives both storage accounting and whether a board can reach
outside its own tree. The rule I landed on: data:, javascript:, mailto:,
tel:, blob:, protocol-relative (//x) and root-relative (/x) URLs are all
"not board-internal". Everything else resolves against the board root.

Root-relative is the one that trips people up. /style.css inside a board looks
like it should work, and it "works" in the sense that the browser requests
https://plopino.com/style.css — which is my site's path space, not the
board's. Treating it as external is the only safe reading.

2. Streaming the upload, and streaming the zip

The upload path uses Busboy with a couple of settings that matter:

Busboy({ headers: req.headers, preservePath: true, defParamCharset: 'latin1' })

preservePath is what makes folder drags work. When you drag a directory into a
browser, the multipart parts carry relative paths (site/css/main.css), and if
you let the parser flatten them to basenames you have thrown away the structure
before you ever see it.

Each file part streams straight to a temp file. Nothing is buffered in memory —
uploads are large enough that buffering a zip only to decompress it afterwards
would double peak memory for no benefit.

Zip extraction goes through yauzl in lazy mode:

yauzl.open(zipPath, { lazyEntries: true, decodeStrings: false }, ...)

lazyEntries keeps one entry in flight at a time instead of materialising the
central directory as an array of objects, which matters when someone uploads a
zip with a few thousand files. decodeStrings: false is the interesting one —
see below.

3. Filename encoding is still a mess in 2026

This is the part I underestimated.

Zip entries don't have a mandated encoding for filenames. The spec says CP437
unless a UTF-8 flag is set, but in practice you receive whatever the producing
tool felt like writing — and on Chinese Windows systems that frequently means
GB18030.

Meanwhile multipart filename parameters are specified as Latin-1-ish, with
RFC 5987's filename* as the escape hatch for anything else. Browsers are
inconsistent about which they send.

So there are two decode paths that have to agree:

filename* (RFC 5987) — Busboy already decodes this to Unicode correctly, use it as-is.
Plain filename — Busboy preserves the raw bytes as Latin-1, so I take those bytes and try UTF-8 first, falling back to GB18030 detection.

If you skip this, a user with a Chinese-locale machine uploads a folder and
every filename comes out as mojibake. From their side it looks like the site
corrupted their files.

4. Persistent workers, not per-request processes

Board thumbnails and Office previews both need a real renderer. The obvious
implementation — spawn one per request — is also the one that makes previews
feel slow and pins the CPU.

Both run in long-lived pools instead:

Office (docx / xlsx / doc) previews render in a persistent worker pool and are cached, so nothing blocks the main thread.
Thumbnails use one lazily-started headless Chromium, one page per task, at a fixed viewport, with a single-flight queue so a burst of new boards doesn't start a browser per request.

The thumbnail step also needed a bit of judgement that isn't obvious from the
outside: before screenshotting, it hides the preview page's own chrome (the
wordmark and download button) and collapses left-hand navigation. Otherwise
every card thumbnail has a tiny "Download" button burned into the corner,
and documentation-style boards show nothing but a sidebar.

5. A test that enforces translation key order

The UI ships in 20 languages including RTL Arabic and Persian.

The test that keeps this honest compares every dictionary against the English
one on three axes: the key set, the key order, and the placeholder names
inside each string.

assert.deepEqual(Object.keys(dict), EN_KEYS);          // set AND order
assert.equal(placeholders(dict[key]), placeholders(EN[key]));

Key order is the unusual one. Nothing forces a JS object literal to keep the
same ordering as another, and nothing breaks at runtime if it drifts — but a
dictionary that has drifted is a dictionary someone edited by hand and then
stopped maintaining. Asserting order means the file layout itself is part of the
contract, so a missing translation fails the suite instead of silently rendering
an English string into a Persian page.

The test also validates BCP-47 tag shape, direction (ltr/rtl), and that the
default language sorts first.

One more thing that follows from having 20 languages: the server injects
<title>, description, og:* and hreflang per language. Crawlers and social
scrapers don't run JavaScript, so a client-side i18n layer is invisible to them.
The page declares data-i18n-doctitle / data-i18n-docdesc on <html>, and the
server renders the real head from the dictionary.

6. Quotas, and moderation that runs on reports

Anonymous uploads are rate-limited per IP per day, and the counters are
persisted — a deploy does not hand everyone a fresh allowance. Signed-in users
get a larger allowance.

Moderation is report-driven: an abuse contact, a takedown path, and reports get
acted on. I'm spelling that out because it is the most predictable question
about a service that hosts arbitrary HTML from strangers.

A related decision that took longer than it should have: are uploaded boards
indexable? Blocking them entirely is the safe-feeling default, but it's wrong in
a subtle way — robots.txt-blocked URLs can't be crawled, so a private board's
URL can linger in search results as a bare link with no context. The site now
serves X-Robots-Tag: noindex on /b/ by default and removes it for public,
undeleted boards. Public boards are linkable-and-crawlable when someone shares
them; private, deleted and expired ones stay out. The sitemap lists zero boards
either way — I'm not turning my sitemap into a directory of user content.

What I'd tell someone starting this

Decide the URL shape on day one. Path vs subdomain changes the link-resolution code, the TLS story and the SEO story, and retrofitting it is miserable.
Treat filenames as hostile input from at least three encodings.
If you render anything user-supplied, keep the renderer warm and put a queue in front of it.
Write the i18n test before the fourth language, not after the tenth.

The service is at plopino.com if you want to try the
actual thing. It's not open source right now — mostly because I don't want to
hand out deployable copies while the abuse story is still unfinished.