DEV Community: Bruno Pérez

Save money on AI using those permanent free LLM APIs

Bruno Pérez — Sat, 28 Mar 2026 20:06:43 +0000

Those LLM APIs offer permanent free tiers for text inference (no trial or initial credits, permanent tier only).

Provider APIs
Inference providers

Provider APIs

APIs run by the companies that train or fine-tune the models themselves.

Cohere 🇺🇸 - Command A, Command R+, Aya Expanse 32B +9 more. 20 RPM, 1K/mo.
Google Gemini 🇺🇸 - Gemini 2.5 Pro, Flash, Flash-Lite +4 more. 5-15 RPM, 100-1K RPD.
Mistral AI 🇪🇺 - Mistral Large 3, Small 3.1, Ministral 8B +3 more. 1 req/s, 1B tok/mo.
Zhipu AI 🇨🇳 - GLM-4.7-Flash, GLM-4.5-Flash, GLM-4.6V-Flash. Limits undocumented.

Inference providers

Third-party platforms that host open-weight models from various sources.

Cerebras 🇺🇸 - Llama 3.3 70B, Qwen3 235B, GPT-OSS-120B +3 more. 30 RPM, 14,400 RPD.
Cloudflare Workers AI 🇺🇸 - Llama 3.3 70B, Qwen QwQ 32B +47 more. 10K neurons/day.
GitHub Models 🇺🇸 - GPT-4o, Llama 3.3 70B, DeepSeek-R1 +more. 10-15 RPM, 50-150 RPD.
Groq 🇺🇸 - Llama 3.3 70B, Llama 4 Scout, Kimi K2 +17 more. 30 RPM, 1K RPD (14,400 for Llama 3.1 8B).
Hugging Face 🇺🇸 - Llama 3.3 70B, Qwen2.5 72B, Mistral 7B +many more. $0.10/mo in free credits.
Kluster AI 🇺🇸 - DeepSeek-R1, Llama 4 Maverick, Qwen3-235B +2 more. Limits undocumented.
LLM7.io 🇬🇧 - DeepSeek R1, Flash-Lite, Qwen2.5 Coder +27 more. 30 RPM (120 with token).
NVIDIA NIM 🇺🇸 - Llama 3.3 70B, Mistral Large, Qwen3 235B +more. 40 RPM.
Ollama Cloud 🇺🇸 - DeepSeek-V3.2, Qwen3.5, Kimi-K2.5 +17 more. 1 concurrent model, light usage.
OpenRouter 🇺🇸 - DeepSeek R1, Llama 3.3 70B, GPT-OSS-120B +29 more. 20 RPM, 50 RPD (1K with $10+ in purchased credits).
SiliconFlow 🇨🇳 - Qwen3-8B, DeepSeek-R1-Distill-Qwen-7B, GLM-4.1V-9B-Thinking +10 more. 1K RPM, 50K TPM.

Contributing

This list changes fast. Star the GitHub repo to get notified when we add providers, and open a PR if you spot one we missed.

Cheers!

What Is An LLM Router?

Bruno Pérez — Sat, 21 Mar 2026 22:52:38 +0000

An LLM Router is a piece of software that directs prompts to different models. Instead of using always the same model for each request, the router redirects each query to a different model. LLM Routing is used mostly for 3 different purposes:

Cost saving: Using a cheaper model when handling easy tasks
Specialization: Use specialist models when needed
Availability: Using fallback models when one is down or load balancing

LLM Routers do the routing automatically so the user experience is smooth and without friction. They differ from LLM Gateways as those ones are more about managing the traffic, ensuring observability and governance rather than choosing the right model for the job.

Rule-based routing vs AI-powered routing

LLM Routers can be grouped into 2 different approaches: rule-based routers which are programmatic and AI-powered routers that use a model to do the redirect.

Rule-based routers, like Manifest, are the simplest to implement: they are fast, deterministic and can run everywhere (client or server). AI-powered routers on the other hand are more powerful and adapt to more use cases, but they cost inference and add extra latency to queries.

Some hybrid approaches are quite effective but they will inherit all AI-powered routers cons (non-deterministic, cost, latency, infra) even if minimized.

LLM Routing for OpenClaw and autonomous agents

By default, OpenClaw (and other autonomous agents) only enables you to connect to 1 model only. This model will handle all the requests from the simplest to the most demanding, from heartbeats to really complex tasks. It is hard for users to get to a winning trade-off: they either use a top-tier model resulting in extra costs or a cheap model reducing the quality of outputs.

Manifest solves that problem by giving you access to 4 different tiers of complexity where you can add a different model for each. It is a very effective way of using routing to reduce costs and maximize the quality of your OpenClaw. It is open source and has both cloud and 100% local version.

Hyper Specialization: Stockfish, Adam Smith and Saving Our Jobs in the AI Era

Bruno Pérez — Wed, 11 Mar 2026 19:10:43 +0000

It's a mistake to think we'll stay relevant by orchestrating AIs. Our salvation may be the opposite: hyper specialization.

Like many software engineers today, I haven’t written any meaningful code myself for months but I am still the one in charge: I choose the tech stack, approach and structure and the coding agents execute.

But agents are quickly reaching the orchestration layer. They ask less, make assumptions and take decisions, mostly the correct ones. It’s just a matter of time before I simply describe my problem and the AI figures out what to build and how.

But even if an absurdly powerful AI can do everything itself, it doesn’t mean it should. Being a generalist has a cost. Using an overqualified AI to do a simple task is like using a sledgehammer to crack a nut. In most cases, contracting a specialist system for that purpose is not just cheaper, but also better.

Adam Smith wrote in 1776 that “divide work into narrow tasks and let focused workers do each one better and faster”. It still makes sense today, and more importantly, tomorrow.

Not convinced? Let me tell you about Stockfish. Stockfish is a chess bot, the best one. Really powerful at chess but nothing else, not something we would call “AI”, whatever that means. It actually can run on any outdated phone. Now if we play a million chess games, Stockfish on a phone versus the latest frontier models on cutting-edge data centers, how many times do the models win?

Zero.

Not once. No wins. No draws. Not even close, the gap is abysmal. Adam Smith was right from the beginning: specialists outperform generalists in all ways. Even in the AI era.

Now if a generalist contracts a specialist to execute a task, we still have to consider the cost of delegation. It’s often easier to do it yourself, as delegation has friction. It comes in two parts:

The finding cost: Discover the service and evaluate it before hiring it. Can I trust it?
The Connecting cost: Integrate the service to our system. Does it plug in easily? How do we pay?

The math is simple:

Cost of execution (diy) ≶ Cost of delegation + Cost of the task

Note: Two factors don’t show up in this equation: risk and governance. A powerful system may prefer to handle sensitive tasks itself to keep control, even at a worse price. Classic make vs buy.

Conclusion
In a world where powerful AI systems will be able to do most of our jobs, there is still a path for individuals and organizations to deliver economic value. That value would not be in controlling those systems but rather in becoming the specialist that AI systems need to contract.

If you build a service that fills tax forms perfectly, regardless of what’s inside the box: AI, software, or humans, you will be better at that one thing and therefore become profitable as each additional customer has a low marginal cost.

Our goal at Manifest is to lower the delegation cost as close to zero as possible. This means building infrastructure where AIs autonomously discover, evaluate, and use specialized services. Connection and payment should be instant too. Reducing delegation friction is key to enable this new economy.

Don’t orchestrate AI, beat it at one thing.

How To Shut Up OpenClaw CLI Banner 🦞

Bruno Pérez — Sat, 28 Feb 2026 00:10:51 +0000

Every time you run an OpenClaw command, you’re greeted with a little lobster and a “funny” tagline:

🦞 OpenClaw 2026.2.15 (3fe22ea)
Gateway online—please keep hands, feet, and appendages inside the shell at all times.

Cute the first time but by the hundredth invocation you start wondering if the lobster is mocking you personally. Moreover, it becomes hard to distinguish the outputs from your command with those vertical spaces.

I went down the plugin rabbit hole trying to suppress it — turns out the banner fires during CLI bootstrap, before the plugin system even loads. So no, you can’t write a plugin to kill it. The lobster is faster than you.

But buried in the source code there’s a single env var doing the lord’s work:

Add to your ~/.zshrc (or ~/.bashrc):

export OPENCLAW_HIDE_BANNER=1

That’s it. One line. source ~/.zshrc and the lobster goes silent.

You’re welcome.

And if you're an stingy OpenClaw user, check out Manifest and stop paying too much tokens by routing queries to the right LLM.

User flows are the new apps

Bruno Pérez — Mon, 12 Jan 2026 17:04:49 +0000

ChatGPT Apps open a new way of considering apps, defining them by a set of flows triggered by an intent detection, rather than by a whole entity. For the user's benefit.

How traditional apps work

If we think about it, the way we ship apps is extremely inefficient: we send the integrity of what we offer to people who will only use a tiny fraction of it. This is literally what happens when you download a mobile app for example, or when you load a web app on your browser. Of course, you can answer saying "Who cares ? Storage and bandwidth are cheap!" and you'll be right to think so.

However, there is more than potential performance issues when delivering the whole jungle to someone who asked for a banana: we are over-complicating our apps, forcing users to figure out themselves where they should go. Complexity takes real estate and makes it overwhelming for users, increasing the time and energy required to complete an action.

I know we do consider user stories and improve them, but when the same platform delivers hundreds of them, they cannot be intuitive. Let's take an example: I have many bank accounts and something I often do is to display my bank account details. Simple, right? But in all my apps that feature is NEVER at the same place, so it pisses me off.

This could have been done better right?

Considering User flows

A user flow is the path of a user who completes a task. It starts with an intent and ends up with a goal, with some steps in the middle. It is a bit different than workflows, another sequence of steps that is centered on processes, not users.

In both cases, we describe our app not by what it is or how it's built, but what it does. Even if we make some technical shortcuts, we are caring more about our users than ourselves, good direction!

Right, but nothing new here! Correct. But now we have at our disposal the perfect tool to detect user's intent: AI.

And this changes literately everything.

Instantly understanding user's intention and delivering the corresponding flow makes everything better for the user.

Let's go back to my bank account details. Imagine the prompt on a chat like ChatGPT:

@myBank display my bank account details

This sentence says it all! There is 0 ambiguity about my intent even for the dumbest LLM. The app can now show me my bank account in the simplest way, because the system knows that I need that and nothing else.

And this is where the magic happens: we can now safely remove the 99% of the app and only deliver the content that our users want.

We can rethink our banking app segmented by user flows:

That simplified example can be powered by a chat agent and an MCP Server, with an optional in-chat UI. If we get creative, we can imagine similar user flows with any AI system capable of guessing an intent and trigger a flow, either visual, vocal or physical

Conclusion: Are flows going to replace apps?

Not really. We still need apps and websites for users to browse content, forge their opinion on something, dig on something and so on. Browsing is serendipity, it's nice.

However, sometimes users have really straightforward intentions, and this is where flows are effective. Delivering only what people want is way faster and easier for users.

I put a Game Boy inside ChatGPT (ChatGPT Apps)

Bruno Pérez — Fri, 19 Dec 2025 01:01:44 +0000

ChatGPT Apps are still in BETA but since yesterday, every developer can submit their apps to their registry.

I decided to try to fit a Game Boy inside Chat GPT to see if it worked... and it did !

See some screenshots below:

How to play Game Boy inside ChatGPT ?

For now you need to activate the developer mode in (settings > apps > advanced settings) and create a new app called "GameBoy" and paste this URL https://gameboy.manifest.build/mcp as MCP Server URL.

Grab your favorite ROM (obviously you need to own the original copy of it), upload it to the chat and mention @GameBoy to launch the game.

This project is open source and based on 2 other great open source projects: Gameboy.js and CSS Gameboy

Have fun!

Create Your First MCP App

Bruno Pérez — Fri, 12 Dec 2025 23:05:36 +0000

TLDR; MCP Apps are bringing interactive UIs to conversational agents and other MCP clients. While this official extension is still a but can bring new ways to interact with apps and content.

In this tutorial we will show how to create a simple yet powerful app (source code here) that can serve as a template for bigger projects. We will create an Express server (Node.js) using TypeScript, Vite and the 2 official MCP SDKs (TS server SDK and ext apps. The app will show the last flights that arrived to an airport in a nice way.

We will do this in 3 steps:

Create an MCP server
Register a tool
Register a resource and connect to tool

Create an MCP server

We are going to the TypeScript SDK to generate a simple MCP Server using the Streamable HTTP transport (recommended way).

Let's start with the basics:

# Init project
npm init --y && npm pkg set type="module"
tsc --init

# Create gitignore file
echo -e "node_modules\ndist" > .gitignore

# Install deps
npm i @modelcontextprotocol/sdk @modelcontextprotocol/ext-apps express zod && npm i -D @types/express nodemon

Our core logic will be included in our server.ts file:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import express from "express";
import { registerGetFlightsTool } from "./tools/get-flights.js";
import { registerFlightCardResource } from "./resources/flight-card/flight-card.js";

const server = new McpServer({
  name: "My First MCP App",
  version: "0.0.1",
});

// Set up Express server to handle MCP requests.
const app = express();
app.use(express.json());

app.use("/mcp", async (req, res, next) => {
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: undefined,
    enableJsonResponse: true,
  });

  res.on("close", () => {
    transport.close();
  });

  await server.connect(transport);
  await transport.handleRequest(req, res, req.body).catch(next);
});

// Start the server.
app.listen(3000, () => {
  console.log("MCP server listening on http://localhost:3000/mcp");
});

Then we want to create a pleasant development environment that serves the MCP server and reloads when we change a file. We are going to use nodemon for this. Create a nodemon.json file:

{
  "watch": ["."],
  "ext": "ts,html,css",
  "ignore": ["dist", "node_modules"],
  "exec": "tsc && node dist/server.js"
}

And adapt the package.json to add a new script

"dev": "nodemon"

Last but not least, we have to make sure that the complied files goes to the dist folder. In the tsconfig.json, uncomment the "outDir": "./dist", moment.

Here we go! We can now run our server:

npm run dev

We are going to use MCP Jam to test that our MCP server is running correctly:

npx @mcpjam/inspector@latest

And add a server with URL http://localhost:3000/mcp. The connection should be successful:

Bravo! Take a sip of coffee because you just finished the step 1 of this tutorial.

Register a tool to your MCP server

Our server is feeling pretty lonely without any tool or resource around! Let's create our first tool that is going to fetch the last flights from an airport.

We are going to return the next flights arriving at a specific airport. Our tool will receive the airport code as input and return an array of flight arrivals. For now we are mocking the flights response, but the point of those MCP tools is to connect to real-world APIs here.

We create a tools/get-flights.ts and register it in the main server.ts file.

// tools/get-flights.ts
import type { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import z from "zod";
import { flightCardResourceUri } from "../resources/flight-card/flight-card.js";

export function registerGetFlightsTool(server: McpServer) {
  server.registerTool(
    "get-flights",
    {
      description: "retrieves flight arrivals for a given airport code",
      inputSchema: {
        code: z.string().describe("The ICAO airport code, e.g. 'KJFK'"),
      },
    },
    async (input: { code: string }) => {
      // Mock flight data for demonstration purposes. In a real implementation, you would fetch
      // this data from an external API.
      const mockFlights = [
        { flightNumber: "AA100", airline: "American Airlines" },
        { flightNumber: "DL200", airline: "Delta Airlines" },
        { flightNumber: "UA300", airline: "United Airlines" },
      ];

      return {
        content: [{ type: "text", text: JSON.stringify(mockFlights, null, 2) }],
        structuredContent: { flights: mockFlights },
      };
    }
  );
}

And register the tool in your server.ts file:

import { registerGetFlightsTool } from "./tools/get-flights.js";
[...]

const server = new McpServer({
name: "My First MCP App",
version: "0.0.1",
});

// Register the tool.
registerGetFlightsTool(server);

Our tool is now live and can be called dynamically in our chat playground. Cheers! You just end up the second part of this tutorial!

Register a UI resource and link it to our tool

Now we want to render the tool result in a UI within our chat application. Let's install more deps

npm i vite vite-plugin-singlefile glob

For now we just compiled TypeScript code into JavaScript but now we will use Vite to convert HTML too. We also want to use vite-singlefile plugin to gather the logic in the same file to return the whole MCP App in one request.

// vite.config.js
import { defineConfig } from "vite";
import { viteSingleFile } from "vite-plugin-singlefile";

export default defineConfig({
  plugins: [viteSingleFile()],
  build: {
    outDir: "dist",
    emptyOutDir: true,
    rollupOptions: {
      input: {
        "flight-card": "resources/flight-card/mcp-app/flight-card-mcp-app.html",
        // Add more HTML resources here as needed
      },
    },
  },
});

Adapt the nodemon.json exec script adding the vite build command:

"exec": "vite build && tsc && node dist/server.js"

And let's declare the flight card resource:

tools/flight-card/flight-card.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import fs from "node:fs/promises";
import path from "node:path";

// Define a unique URI for the flight card resource.
export const flightCardResourceUri = "ui://flight-card.html";

export function registerFlightCardResource(server: McpServer) {
  server.registerResource(
    flightCardResourceUri,
    flightCardResourceUri,
    {},
    async () => {
      // Read the HTML content from the file system.
      const html = await fs.readFile(
        path.join(import.meta.dirname, "mcp-app/flight-card-mcp-app.html"),
        "utf-8"
      );

      return {
        contents: [
          {
            uri: flightCardResourceUri,
            mimeType: "text/html;profile=mcp-app",
            text: html,
          },
        ],
      };
    }
  );
}

And register the resource in your server.ts file:

// server.ts
import { registerGetFlightsTool } from "./tools/get-flights.js";
import { registerFlightCardResource } from "./resources/flight-card/flight-card.js";
[...]

const server = new McpServer({
name: "My First MCP App",
version: "0.0.1",
});

// Register tools and resources.
registerGetFlightsTool(server);
registerFlightCardResource(server);

Now we can create the flight card MCP app, which will be an HTML template and a TS module. I created a new folder at /tools/flight-card/mcp-app to put those 2 files.

<!-- tools/flight-card/mcp-app/flight-card-mcp-app.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script type="module" src="./flight-card-mcp-app.ts"></script>
    <title>Flight Cards</title>
    <style>
      * {
        margin: 0;
        padding: 0;
        box-sizing: border-box;
      }

      body {
        font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
          sans-serif;
        background: #f0f2f5;
        padding: 40px;
      }

      .container {
        display: grid;
        grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
        gap: 20px;
        max-width: 1200px;
        margin: 0 auto;
      }

      .card {
        background: white;
        border-radius: 12px;
        padding: 20px;
        box-shadow: 0 2px 8px rgba(0, 0, 0, 0.1);
        display: flex;
        align-items: center;
        gap: 16px;
      }

      .icon {
        width: 48px;
        height: 48px;
        background: #e8f4fd;
        border-radius: 50%;
        display: flex;
        align-items: center;
        justify-content: center;
        font-size: 24px;
      }

      .info {
        flex: 1;
      }

      .flight-number {
        font-size: 18px;
        font-weight: 600;
        color: #1a1a2e;
      }

      .airline {
        font-size: 14px;
        color: #666;
        margin-top: 4px;
      }
    </style>
  </head>
  <body>
    <div class="container" id="flights"></div>
  </body>
</html>

And the TS module:

// tools/flight-card/mcp-app/flight-card-mcp-app.ts
import { App, PostMessageTransport } from "@modelcontextprotocol/ext-apps";

// Create a new MCP App instance.
const app = new App({
  name: "Flight Card MCP App",
  version: "0.0.1",
});

const flightsEl = document.getElementById("flights")!;

// Handle tool results to display flight information.
app.ontoolresult = (result) => {
  const flights = result.structuredContent?.flights as {
    flightNumber: string;
    airline: string;
  }[];

  flights.forEach((flight) => {
    flightsEl.innerHTML += `
        <div class="card">
          <div class="icon">✈️</div>
          <div class="info">
            <div class="flight-number">${flight.flightNumber}</div>
            <div class="airline">${flight.airline}</div>
          </div>
        </div>
      `;
  });
};

app.connect(new PostMessageTransport(window.parent));

And last but not least, go back to your get-flights tool and add link to your resource using the _meta key.

// tools/get-flights.ts
import { RESOURCE_URI_META_KEY } from "@modelcontextprotocol/ext-apps";
import { flightCardResourceUri } from "../resources/flight-card/flight-card.js";
[...]

 server.registerTool(
    "get-flights",
    {
      description: "retrieves flight arrivals for a given airport code",
      inputSchema: {
        code: z.string().describe("The ICAO airport code, e.g. 'KJFK'"),
      },
      // Link to resource here.
      _meta: { [RESOURCE_URI_META_KEY]: flightCardResourceUri },
    },

Bootsrapping all together, we are now able to see the UI appear when you ask the flights! Checkout the source GitHub repo

Personal thoughts

The MCP App extension is still a draft but we can already see where this is heading next: more focused and "intent-based" interfaces that deliver minimalistic yet effective experiences.

Of course, the browser experience is not going anywhere soon but we sense that many use cases can benefit from being ported to the chat format:

UI-intensive user stories that could be accelerated through this format (like long multi-step forms)
Brands that want to deliver rich experiences to tell a narrative despite website traffic loss

On the technical side we hope to see soon more MCP clients supporting this protocol.

What use cases are you seeing for this extension? Are you seeing some drawbacks or challenges? Leave your take on the comments.

Supabase alternative for AI Code editors (Cursor, Bolt, Lovable...)

Bruno Pérez — Thu, 19 Jun 2025 13:26:26 +0000

In this post I compare existing solutions for the backend of AI generated apps and share our journey building Manifest, a minimalistic open source backend for AI-assisted coding.

As of today, AI code editors already work very smoothly with frontend generation. Even a non coder is able to create nice UIs and websites with a bit of motivation. However vibe coding the backend side is still a bit laborious.

The bootstrap approach to backend (local tools)

Local AI code editors like Cursor, Windsurf and VS Code with Copilot are made for people already familiar with IDEs, matching high requirements like a strong version control or working with existing/legacy codebases.

If you ask any of those editor to create a backend, chances are that you will get something made with FastAPI or Django in Python, Laravel in PHP, Ruby on rails, NestJS and so on.

All of those frameworks have proven to be exceptional products, robust and highly customizable. They have been used by developers for years support top tier platforms.

However, in the context of AI-assisted programming, they have some drawbacks:

A backend with those frameworks consists necessarily in a huge amount of files which makes it nearly impossible to be humanly validated and cost a lot in computing (tokens)
Each feature is mostly developed in the spot for you and may contain security flaws for unknown reasons
The developer must still have solid knowledge with the framework to understand it

The Supabase approach to backend (online tools)

Then you have the online vibe coding tools like Bolt.new, Lovable, co.dev and so on. Those tools are addressing a large audience and require little knowledge to get started. They are amazing to quickly ship a project from scratch.

What do they have in common regarding the backend ? They all have the "connect to Supabase" button. It actually makes a lot of sense as it is so much simpler to rely on a cloud backend rather than creating a consistent environment for different backend stacks.

Supabase is a well-know BaaS (Backend as a Service) based on PostgreSQL and giving built-in features like auth or storage. Nevertheless, even if Supabase is an amazing product on its own, linking your AI-generated frontend to a Supabase backend can be tricky for many reasons:

Having to deal with 2 projects creates a poor DX, making you going back and forth between 2 dashboards and the LLM not always understanding what is on the other side
Branching, versionning and environment management becomes suddenly way more complex
You may not be familiar with PostgreSQL

Even if Supabase is building a strong MCP to connect the service, it will always be 2 connected services at the end of the day.

Manifest: finding the sweet spot

When we first built Manifest, as an internal tool, we did not think right away about making it fit in the context of AI coding. However, we strongly focused on simplicity of use and reducing the development time. Those characteristics are now 100x enhanced by AI code tools that we use today which makes a perfect fit for Manifest as a backend for AI editors.

Manifest is a complete backend that fits into 1 simple YAML file, that makes it so easy for LLMs to generate that content, and for humans to validate. Relying on pre-made components like auth or upload modules is also a way of ensuring the developer that there is no breaches in security or privacy.

We also wanted Manifest to be not only open source but also 100% portable, it's just an npm package that you can add to any codebase with a package.json in it. Manifest uses SQLite by default, a file-based DB that works even in browser environments like Stackblitz.

Where we go next

Manifest is still on BETA but already used on multiple projects. If you think Manifest could be a good fit for you, give it a try ! You can share some love by giving Manifest a star on GitHub and we'll be happy to hear your feedback on our Discord server.

From DEV to CTO: Embracing technical Debt

Bruno Pérez — Wed, 04 Dec 2024 09:22:58 +0000

How can I have a debt if I didn't borrow any money ?

This is the first question that technical debt brings to mind.

But let's approach technical dept with an example: Bob had to paint his flat, he spent all Saturday doing it. He was invited to a really cool party on the evening. By nightfall, Bob had just finished painting but still needed to clean the brushes and put things away. He said "you know what ? f*** it", stuffed roughly all the paint pots and brushes in the closet and went to that party.

What do you think about Bob's attitude ? Is he a pragmatic man ? Or a low-life and immature person ?

There are 2 key things to understand in this story:

Bob could not have been to that party if he had to clean and put tools away after painting
Bob ca no longer use his closet normally because his clothes are blocked by paint pots

Understanding Bob's story is understanding technical debt - there is nothing more to it. The next paragraphs are about helping you choose when to clean you brushes and when to go to the party.

Doing the right thing: a practical example

Let's take a technical example: You have a component that needs to fetch data from an API. As a good developer, you know that the right thing to do is to create a service/store/hook/function (or whatever your framework calls it) to put all the API logic and inject it in your component.

However, software development is about delivering things that work. And the fastest way to do it is to skip the service thing and make that HTTP call directly from your component.

Is it bad code ? Yes. Does it work ? Yes.

There are obvious reasons why you should not do that: poor readability, it's hard to maintain, there is no separation of concerns and this will inevitably lead to WET code if that call is repeated elsewhere.

However.

If that code will never be touched again in the future (not likely) or, if you do not care about how this code will be changed in the future (more likely), bad code can be your best option. End of chapter 1.

Time capsule: doing it again

Let's imagine that the you from the future opens that stinky codebase from chapter 1. You have to create a new component that calls the same API. See where we are going ?

Once again we have two choices:

Clear that technical debt once for all and to that damn service, and implement it in both components
increase the technical debt by ruthlessly copy-pasting your code in the new component

Does the trade-off change ? No. It is exactly the same situation as above, you have to choose based on the situation. Be quick or be solid.

The outcome: mastering technical debt

From a developers' perspective, it is clear: bad code is bad code, it is evil. Every book and tutorial will tell you exactly that you should never write bad code.

Yet, from a different perspective, the reality is not that simple. Bad code is never 100% bad and neither is good code 100% good. There are also deadlines to respect, profitability to ensure, new contributors to integrate among many other factors.

Does it mean that you have to make concessions and give up on good practices ? Not at all ! Bad code will definitely come back at you soon or late and you will pay it slowing development, weakening your app and annoy developers because no one likes to work on a stinky codebase.

The point is finding the sweet spot: nothing is absolute, everything varies from situations. Sometimes you have to deliver quickly, sometimes you need to consolidate.

It is when you start evaluating and embracing the technical debt, knowing what you get in exchange for it that you pass from developer to CTO.

Ship fast without trading off your standards with Manifest

If you understand that mastering technical debt is key, you will love Manifest ! It is an open source 1-file backend that allows you to create complete backends quickly while keeping your coding conventions and standards.

Star the Manifest project if you want to see Manifest grow ❤️.

A minimalist newsletter signup app with HTMX and Manifest

Bruno Pérez — Tue, 22 Oct 2024 12:46:48 +0000

TLDR;

This simple full stack newsletter signup app has been built with minimal code. See the source code or open the live stackblitz demo

Intro

What is HTMX ?

HTMX is an open source JS library that extends HTML allowing it to make HTTP requests (other than the default form POST) and update the DOM.

Unlike JS frameworks like React, HTMX does not take control of your app. It is a minimalist library that integrates directly into HTML files. It works really well on small projects where you need to interact with a server.

  <script src="https://unpkg.com/htmx.org@2.0.3"></script>
  <!-- have a button POST a click via AJAX -->
  <button hx-post="/clicked" hx-swap="outerHTML">
    Click Me
  </button>

What is Manifest ?

Manifest is an open source Backend-as-a-Service in 1 file that provides key backend features out-of-the-box. Manifest's purpose is to empower front-end developers enabling them to create backends easily and quickly.

The syntax is a clear YAML file that generates an admin panel, a database and a fully functional REST API.

# manifest/backend.yml
name: Healthcare application 🏥

entities:
  Doctor 👩🏾‍⚕️:
    properties:
      - fullName
      - avatar
      - { name: price, type: money, options: { currency: EUR } }
    belongsTo:
      - City

  Patient 🤒:
    properties:
      - fullName
      - { name: birthdate, type: date }
    belongsTo:
      - Doctor

  City 🌍:
    properties:
      - name

Why both ?

In order to shine, HTMX needs to interact with a backend to fetch and post data. Instead of choosing a large backend framework that constrasts with the "micro-frontend" HTMX approach, Manifest fits better as it also provides a minimal and functional syntax.

The mission

In this demo, we will create a simple newsletter signup form with an email and a name input. The newly created subscribers get saved in the persistent database using Manifest and can be managed from the non-technical admin panel.

The HTMX

Our HTMX consists in a small HTML form where we add 3 attributes: hx-post, hx-target and hx-swap.

  <h1>Subscribe to our Newsletter</h1>
    <!-- We use hx-post to make an HTTP POST request on submit -->
    <form
      hx-post="http://localhost:1111/api/dynamic/subscribers"
      hx-target="#message"
      hx-swap="innerHTML"
    >
      <!-- The name of the inputs is important as it will be the payload key -->
      <input type="text" name="name" placeholder="Your name" required />
      <input type="email" name="email" placeholder="Your email" required />
      <button type="submit">Subscribe</button>
    </form>
    <div id="message"></div>
    <script>
      document.addEventListener("htmx:afterRequest", (event) => {
        const response = JSON.parse(event.detail.xhr.response);

        // Display a custom message on request success.
        const message = `
                <div class="message">
                    Thank you, ${response.name}! You have successfully subscribed with the email: ${response.email}.
                </div>
            `;
        // Inject the message into the target element
        document.getElementById("message").innerHTML = message;
      });
    </script>

The backend

In order to launch Manifest, you need to have NodeJS installed in your machine. From the root of your app, run:

npx add-manifest

This will create the manifest/backend.yml file with some dummy content. We replace it with our data model.

name: Newsletter Backend 💌
entities:
  Subscribers:
    properties:
      - { name: name, type: string }
      - { name: email, type: email }

Now we can serve the backend with the following command:

npm run manifest

You can now use your backend:

🖥️ Admin Panel: http://localhost:1111
📚 API Doc: http://localhost:1111/api

It you open your frontend with your browser, you can now subscribe to the newsletter, and verify in the admin panel that the new subscriber has been added to the collection !

Conclusion

We successfully created a full-stack app with 2 minimalist components: HTMX and Manifest with few lines of code.

One important point is that we need to use a bit of JavaScript to modify the DOM as HTMX expects HTML response from the server and Manifest delivers JSON through its REST API. Once that is clarified, the connection between front and back is really smooth.

Svelte + Manifest = Giving Svelte a proper backend with 7 lines of code 🧡🦚

Bruno Pérez — Mon, 07 Oct 2024 15:50:00 +0000

TL;DR: Using Manifest as backend for Svelte turns it into a full stack application with minimal coding. Check the source code on github

# manifest/backend.yml
name: My TODO App ✅
entities:
  Todo:
    seedCount: 10
    properties:
      - title
      - { name: completed, type: boolean }

Svelte is an amazing framework with a very simple and elegant syntax.

However, a frontend is rarely enough to make a functional app: we often need a backend with some logic, a database and and a couple of API endpoints. This can often be time consuming and cumbersome.

In this post I will show what I think is the fastest and easiest way of giving a backend for Svelte: Manifest. It consists in a single YAML file (yes, YAML !) that generates a full backend.

We will create a todolist app with the following features:

Adding a new todo stores it in the database with the completed property set to false
Clicking on the todo checkbox marks it at complete or uncomplete
Clicking on the "remove" button deletes the todo

This is what we are building:

Create the Svelte app

Svelte has a nice installation script:

npm create svelte@latest my-app

In this example I choose the Skeleton project, in TypeScript and without any additional options.

We can now run the Svelte frontend with:

npm run dev

Add the backend

We can directly add the Manifest backend from the root of our Svelte app:

npx add-manifest@latest

This will create a manifest folder with a backend.yml on it. Replace the dummy content with this one.

# manifest/backend.yml

name: My TODO App ✅
entities:
  Todo:
    seedCount: 10
    properties:
      - title
      - { name: completed, type: boolean }

We can now run our backend server:

npm run manifest

You can now connect to your admin panel and see your OpenAPI documentation:

Connect the client and the server

Now we need to add the app logic and get the data from our backend. First of all intall the Manifest SDK:

npm i @mnfst/sdk

To make it short we will put all the logic in the src/routes/+page.svelte file. On bigger projects it is recommended to have a better separation of concerns

We will create our 3 functions:

getTodos: fetch all the todos
addTodo: Adds an uncomplete todo to the DB,
removeTodo: Removes a todo from the DB
ToggleTodoCompletion: Toggles the completion status of an existing todo

Lets start by defining what a Todos is:

// Define the Todo type.
type Todo = { id: number; title: string; completed: boolean };
let todos: Todo[] = [];

And now we can create our functions:

import Manifest from "@mnfst/sdk";

// Initialize the Manifest SDK.
const manifest = new Manifest();

// Fetch all todos from the database.
async function getTodos() {
  todos = (await manifest.from("todos").find()).data as Todo[];
}

// Add a new todo to the database.
async function addTodo() {
  await manifest.from("todos").create({ title: newTodo, completed: false });
  // Fetch all todos again to update the list
  getTodos();

}

// Remove a todo from the database.
async function removeTodo(id: number) {
  await manifest.from("todos").delete(id);
  todos = todos.filter((todo) => todo.id !== id);

}

// Toggle the completion status of a todo.
async function toggleTodoCompletion(todo: Todo) {
  // Update the todo in the database.
  const updatedTodo = { ...todo, completed: !todo.completed };
  todo = await manifest.from("todos").update(todo.id, todo);

  // Reassign the array to trigger update in the UI.
todos = todos.map((t) => (t.id === updatedTodo.id ? updatedTodo : t));
}

Putting everything together

Checkout the +page.svelte file on the demo repository to see the style and UI implementation. We managed to add simply a backend for this Svelte demo app ! Let me know your thoughts about this implementation ! What backend stack do you use for your backends usually ?

If you liked using Manifest, give us a ⭐ on Github to follow to projects and help us improving it. We also have some hacktoberfest issues 🎃 for contributors among you !

Do front-end developers fear the back-end?

Bruno Pérez — Mon, 19 Feb 2024 14:03:19 +0000

As the frontier between frontend and backend is not clear in most people's minds (especially clients), frontend developers sometimes have to deal with backend requests. They can ask you to create an API, an admin panel, etc.

If you are a freelancer or working on a small team without a backend developer, how do you handle those requests? Do you give it a try or just refuse it straight away?

I am interested in hearing about different experiences on this topic. Leave your answer as a comment.