DEV Community: David Gomes

app.build – Open-Source AI Agent That Builds Full-Stack Apps

David Gomes — Wed, 04 Jun 2025 20:41:52 +0000

Code generation has been one of the most interesting use cases for LLMs. While the best models can generate decent code for isolated problems, there is a big gap between these code snippets and fully functional applications. Agent-based solutions are better suited to create apps. To close the gap, an agent needs to iterate on the code, test the result and make decisions based on the feedback - either human comments or technical (like logs, test results, linters output etc.). In the last few months, a lot of AI app builders have come to market to tackle this problem, but the gap is not closed yet.

And today, Neon is launching app.build - an open-source agent that can build and deploy full-stack applications, with end-to-end tests and automated deployments. We want to build a community around this project, since we know a lot of developers are interested in hacking in this space, particularly by bringing their own models and doing most things locally.

How can I try it then?

npx @app.build/cli

This very simple command is all you need to get started. Notice that, by default, it will ask you to sign in with GitHub. Any application that you generate will have its own repository (in your GitHub account), and will be deployed to the Internet with a real backend and a real database. This is our "managed service" experience. We're also working on a smoother way for you to run everything locally (which will include being able to choose which models you want for which tasks, and even self-hosted models).

Can I run this locally?

Yes, everything runs locally. Our README.md contains instructions for how to run this locally, but we have yet to create a full guide for running both the CLI and the agent locally with more detail.

We also want to write down instructions on how you can bring your own models (including self-hosted ones).

What features does the platform offer?

Our CLI allows both creating new apps from scratch, and iterating on previously created apps (add new features or other types of changes). It is extremely barebones for now!

But our platform gives you:

An authentication provider (it defaults to Neon Auth)
A hosted database (it defaults to Neon Postgres)
Your app's frontend and backend get deployed immediately (in Neon and Koyeb's infrastructure)
Hosted repository on your own GitHub account

How does the agent work?

We've taken a lot of steps towards having an agent architecture that is focused on generating really high-quality applications that actually work as intended. This is why our agent writes end-to-end tests and actually runs them to succession as part of the generation pipeline.

Furthermore, we have a very solid base template for every app (for now, just 1 template, which is for web apps), and we made sure that the agent is extremely well-versed on all the technologies that are used in this template (Fastify, Drizzle, React, Vite, etc.).

Our agent follows the "divide-and-conquer" principle — app creation is decomposed into multiple tasks, and each can be solved independently. Furthermore, those tasks themselves may have their own subtasks, so we don't rely on LLMs generating large chunks of code at once. Each particular task passes a series of checks (e.g. Does it compile? Does it pass ESLint? Does it pass tests?), thus ensuring the final app works.

In future blog posts and talks, we'll definitely dive deeper into the inner workings of the agent.

How can I get involved?

For now, we're hacking over at github.com/appdotbuild. You can see all the code, all the commits and all of our planned tasks. We hope to create a Discord channel, and a proper public-facing roadmap soon!

We're also currently working on more blog posts and videos explaining our code generation pipeline, and other architectural decisions we made while building the agent.

Wrapping My Mind Around Node.js Runtimes

David Gomes — Fri, 22 Nov 2024 22:34:32 +0000

A look at Deno and Bun and how they work differently from Node.js

There’s been a lot of innovation in the last few years in Node.js runtimes. Node.js used to be the only viable option, but now there’s other contenders such as Bun and Deno. But are they ready for prime time? When should they be used, and by whom?

Wait, what even is a JavaScript runtime?

Good question. JavaScript wasn’t really built for the server. In fact, JavaScript wasn’t really “built” at all. What we think of as JS is just a specification.

A runtime is what brings that specification to life. It’s the environment that executes JavaScript code. When you’re working in a browser, the browser provides the runtime. But on a server, you need something else. That’s where Node.js came in and where these new runtimes are shaking things up.

A JavaScript runtime typically consists of several key components:

JavaScript Engine. This is the core that interprets and executes JavaScript code. V8 (used by Node.js and Chrome) is a famous example.
Event loop. Manages asynchronous operations, allowing non-blocking I/O operations.
APIs. Provides interfaces for system-level operations like file I/O, networking, and timers.
Standard library. A set of built-in modules and functions that developers can use out of the box.

Node’s ability to handle thousands of concurrent connections with its non-blocking I/O model has made it particularly popular for real-time applications, APIs, and microservices architectures. And it is still the most popular “web technology” according to the 2024 Stack Overflow survey:

The problems with Node.js

But Node is not without its detractors—including the person who initially built Node, Ryan Dahl. In a 2019 jsconf talk titled 10 Things I Regret About Node.js, Dahl lists the problems he now sees in Node, such as…

Security. By default, the module system in Node.js allows any package to access the file system, network, and environment variables. This poses significant security risks, especially when using third-party modules.
Package management. The package.json file, npm, and the Node modules system have become overly complex. There’s also various security issues around npm (like the postinstall scripts).
Build system complexity. Node’s build system, particularly for native modules, has become unnecessarily complicated over time. Basically, supporting both CommonJS and ES modules made Node.js much more complex.

So, all this together has led a few people to think they can do better.

The new runtimes in town

Deno: Security-oriented, modern JavaScript

Ryan Dahl chose to take the learnings from Node and built Deno. Deno addresses many of the concerns he had with Node.js:

Focus on security. Deno runs code in a sandbox by default. Accessing the file system, network, or environment variables requires explicit permissions. This approach significantly reduces the risk of malicious code execution.
Built-in TypeScript support. Unlike Node.js, which requires additional setup for TypeScript, Deno supports TypeScript out of the box. This integration streamlines development and improves code quality.
Standard modules. Deno provides a standard library of high-quality, audited modules. This reduces dependency on third-party packages for common functionalities.
Browser compatibility. Deno aims to be as close as possible to browser JavaScript. It uses web standard APIs where possible, making it easier for developers to write code that works both in the browser and on the server.
Import URLs. Instead of using a package manager like npm, Deno allows modules to be imported directly via URLs.
This will somewhat change with Deno v2, more on this later.
Single executable. Deno ships as a single executable with no external dependencies, making it easy to install and use across different environments.

Deno is gaining traction, especially among developers who appreciate its modern features and security-first approach. It’s particularly attractive for projects that can benefit from its TypeScript integration and don’t rely heavily on Node-specific libraries.

Deno also provides infrastructure beyond the runtime. Tests, linters, and formatters are also included. You can also deploy your applications using Deno’s serverless environment, Deno Deploy (learn how to use Neon with Deno Deploy), and build entire applications using Deno’s framework, Fresh.

Here’s a simple setup with Deno to use Neon. The Deno-specific things are the import (@neon/serverless is called @neondatabase/serverless in NPM) and the Deno.env.get bits. Also, this is a Deno v2 example (which is currently in “canary”).

import { neon } from "@neon/serverless";

// Get the connection string from the environment variable "DATABASE_URL"
const databaseUrl = Deno.env.get("DATABASE_URL")!;

if (!databaseUrl) {
  throw new Error(`Please add a DATABASE_URL environment variable.`);
}

const sql = neon(databaseUrl);

const rows = await sql`SELECT version()`;

console.log(rows[0].version);

To run this, call:

DATABASE_URL=$DATABASE_URL deno test.ts

(And notice how Deno will ask for permission to read environment variables and make network requests at runtime.)

To show the speed of progress with Deno, up until a few months ago, the above code would have used an import URL, such as:

import * as postgres from 'https://deno.land/x/postgres@v0.17.0/mod.ts';

Deno just released version 1.46, which will be the last 1.X version. Deno 2 is changing in response to feedback from the community and a greater understanding of the initial strict choices of the runtime.

Take imports. Originally the idea was to have simple URLs like https://deno.land/x/postgres@v0.17.0/mod.ts. As Deno put it:

Designing Deno’s module system around HTTP imports was ambitious. It aimed to replace npm with a distributed system over HTTP, aligning with how ES Modules work in browsers. This eliminated the need for package.json files and node_modules folders, simplifying project structures.

But the reality wasn’t as clean. Deno found that dependency management, clutter, and reliability were all a problem with this approach. So, they’ve launched JSR, the JavaScript Registry. This is akin to npm in node, but TypeScript and ECMAScript-native. All you have to do is:

deno add @neon/serverless

Then you’re ready to roll.

Like Node.js, Deno is built on the V8 engine. Originally, Deno wasn’t supposed to be compatible with Node.js. But, as with import URLs, pragmatism beat out idealism. The Deno team realized that compatibility with the vast Node.js ecosystem would significantly increase Deno’s adoption and usefulness. As a result, they’ve been working on Node.js compatibility layers, allowing developers to use many Node.js packages and APIs within Deno projects, thereby bridging the gap between the two runtimes.

If you want to learn more, I highly recommend the recent participation of Ryan Dahl on the “Syntax” podcast to learn more about Deno v2.

Bun: A performance-focused Node replacement

Bun is a little different. It was Node-compatible out of the gate and not looking to right-the-wrongs of Node.js. But, as it grew, it started to evolve towards a slightly different direction.

Benchmarking is hard. We at Neon are definitely very well aware of that, but my anecdotal experience is that Bun is indeed really fast. How fast exactly is very hard to measure, of course.

Like Deno, Bun is looking to rely on JavaScript primitives and code simplicity. Here’s Neon running with Bun:

import { neon } from "@neondatabase/serverless";

const databaseUrl = process.env.DATABASE_URL;

if (!databaseUrl) {
  throw new Error(`Please add a DATABASE_URL environment variable.`);
}

const sql = neon(databaseUrl);

const rows = await sql`SELECT version()`;

console.log(rows[0].version);

To call this, run:

DATABASE_URL=$DATABASE_URL bun test.ts

Bun’s approach to improving the JavaScript runtime environment focuses on several key areas:

Performance. Built on the JavaScriptCore engine (used by Safari), Bun is designed for speed from the ground up. Its fast startup times and efficient execution make it particularly suitable for serverless environments and microservices.
TypeScript support. Similar to Deno, Bun offers out-of-the-box TypeScript support. However, Bun takes it a step further by transpiling TypeScript at runtime, eliminating the need for separate build steps in many cases.
Enhanced APIs. Bun provides additional APIs that aren’t available in Node.js, such as the Bun.file API for efficient file operations and the SQLite API for built-in database functionality.
Streamlined configuration. Bun aims to reduce configuration overhead. For instance, it automatically loads environment variables from .env files, simplifying local development and deployment processes.
All-in-one toolkit. Bun isn’t just a runtime; it’s a complete toolkit. It includes a package manager, test runner (which Node.js now has as well), and bundler, all optimized for performance. This integrated approach simplifies the development workflow and reduces the need for additional tools.

The Bun team is rapidly iterating and adding some interesting features. For example, they introduced “hot module reloading” for server-side code, a feature that’s been long desired in the Node.js ecosystem. Also, more recently, they added support for C code using TinyCC 🤯And I believe they led the way with SQLite embedding (but Node.js has now caught up).

While Bun is still young compared to Node.js and even Deno, its focus on performance and developer experience is attracting attention. It is particularly appealing for projects where raw speed is a priority, such as high-traffic web servers or compute-intensive apps.

Furthermore, it’s also extremely appealing to use Bun not as your production runtime, but just as your package manager. We’re currently doing that with neonctl, purely because of Bun’s performance (we also want to migrate the CLI runtime to Bun at some point, due to its single-file executable feature and overall performance).

Final thoughts

First of all, I have to mention that there are a few other runtimes that are probably worth mentioning. Although, perhaps it’d be better to refer to some of them as “neo-runtimes” since they’re not necessarily full blown runtimes:

Then, there’s the aspect of picking a runtime. This is a very hard decision and obviously migrating existing projects is even harder. But this is my very personal current thought process:

Use Node.js for anything that needs to live for really long, or doesn’t need Deno’s security model
Use Deno if you want extra security, or if you specifically want to use Deno Deploy.
Don’t use Deno if all you care about is not transpiling TypeScript. Node.js will support TypeScript soon enough.
Use Bun if performance is the most important thing to you. Or, if you want to use some of Bun’s more “fun” features (Macros, embedded SQLite, etc.) and you don’t have a super critical requirement that your project outlives your time on Earth (Bun is afterall backed by a very early stage company).

That’s basically it, but I know this is all very subjective — do your own research! I really love Bun’s performance and I try to use Bun for all package management on my local machine. However, I would only use Bun as a production runtime under certain circumstances for now.

If you’re looking for a more pessimistic take on new runtimes, I can recommend this blog post. But I tend to have a more positive outlook on new companies building cool new dev tooling.

Introducing Neon RLS: Simplifying Row-Level Security For Postgres

David Gomes — Wed, 30 Oct 2024 18:15:50 +0000

RLS policies in your codebase, verified by Neon

Today we’re launching Neon RLS, a tool that aims to simplify the usage of Postgres row-level security policies while enabling new deployment models for app developers. With Neon RLS, you can manage RLS directly in your codebase and integrate with any authentication provider, making it easier to enforce fine-grained access control without added complexity.

Every app needs a database. And every app needs authentication and authorization.

However, it can be cumbersome to bind these things together. If you’ve worked on application backends before, it’s very likely you’ve seen code like this:

try {
  const result = await query(
    `SELECT r.role_name
     FROM user_roles ur
     JOIN roles r ON ur.role_id = r.id
     WHERE ur.user_id = $1 AND r.role_name = $2`,
    [userId, "admin"]
  );

  if (result.rows.length > 0) {
    next();
  } else {
    res.status(403).json({ error: 'Access denied' });
  }
}

This type of database access is hard to properly secure. The core issue is that it’s quite easy to mess up the authorization check – WHERE ur.user_id = $1 AND r.role_name = $2).

This is where Row Security Policies) in Postgres come in. This feature allows developers to configure declarative access rules for their tables. As an example, let’s say you have the following users table:

Table "public.projects"
┌───────────────┬──────────────────────────┬──────────┬───────────────────┐
│    Column     │           Type           │ Nullable │      Default      │
├───────────────┼──────────────────────────┼──────────┼───────────────────┤
│ id            │ uuid                     │ not null │                   │
│ owner_user_id │ uuid                     │ not null │                   │
│ name          │ text                     │ not null │                   │
│ created_at    │ timestamp with time zone │          │ CURRENT_TIMESTAMP │
│ updated_at    │ timestamp with time zone │          │ CURRENT_TIMESTAMP │
└───────────────┴──────────────────────────┴──────────┴───────────────────┘

To secure it with RLS, you’d configure the following rules:

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Create policy for selecting own records
CREATE POLICY select_own_records ON public.projects
FOR SELECT
USING ((select owner_user_id = auth.user_id()));

-- Create policy for inserting rows
CREATE POLICY insert_policy ON public.projects
FOR INSERT
WITH CHECK ((select owner_user_id = auth.user_id()));

-- Here, we're missing similar policies for DELETE and UPDATE.

Notice that auth.user_id() and auth.session() are part of the open-source pg_session_jwt Postgres extension, authored by the Neon team.

info
The advantage of RLS is that the authorization layer for your application is now declarative. Just like React.js brought declarative views to frontend development, RLS rules bring declarative access logic to backends.

With access logic at the database level, your application becomes much safer. Just like foreign keys enforce referential integrity, and CASCADE deletes can be used to enforce data correctness, RLS can enforce authorization on every database query.

Expanding access to RLS with Neon RLS

With Authorize, we’re making it easier for developers to use RLS by providing an integration between any authentication provider and Postgres on Neon. After setting it up, calls to the database can be authenticated with a JWT (JSON Web Token) generated by the auth provider, which will be:

– Verified by the Neon Proxy

– Added to the request and made available for RLS rules and WHERE clauses alike

Furthermore, you’ll also have access to a few utility functions such as auth.session() and auth.user_id() which will help you use the JWTs that are coming from your auth provider.

Any authentication provider is automatically supported by our platform as long as it can generate JWTs and provide some URL for us to download the JWKS. Here’s an example of using the JWT in a filter:

SELECT
    u.name,
    u.email
FROM
    users u
WHERE
    auth.user_id() = u.user_id

Here’s a list of Auth providers we’ve already tested in partnership with each team (more to come):

Clerk – Example Repo
Stack Auth – Example Repo
Auth0 – Example Repo
Stytch – Example Repo
AWS Cognito – Example Repo
Azure AD – Example Repo
Descope Auth – Example Repo
Supertokens – Example Repo
Firebase Auth
Keycloak
GCP Cloud Identity

Refer to the Neon RLS docs for all the details.

The elephant in the room: RLS’s SQL syntax

One of the biggest issues with Postgres RLS is the difficult-to-understand SQL syntax. While LLMs can be great at generating this syntax, it still can easily become too hard to reason about.

That’s why we’ve partnered with Drizzle ORM to offer a cleaner, more intuitive way of defining RLS rules. With Drizzle and Neon, developers can set up RLS policies in a declarative format right alongside their schema definitions. This means you can manage RLS in the same place as your schema and data models, making your codebase more organized and easier to maintain.

What if I'm not using Drizzle?
That's completely fine: you can still use Neon RLS. Drizzle is not a requirement but an enhancement.

We worked with the Drizzle team in order to design and test both the pgPolicy function, as well as a crudPolicy higher-level API that can be used as a helper utility to generate multiple Postgres policies with one function call.

Here’s a sneak peek of what it looks like to use @drizzle-orm/pg and @drizzle-orm/neon together. Also in this repo: https://github.com/neondatabase-labs/social-wall-drizzle-neon-authorize

import { sql } from "drizzle-orm";
import { pgTable, text, timestamp } from "drizzle-orm/pg-core";
import { authenticatedRole, anonymousRole, crudPolicy, authUid } from "drizzle-orm/neon";



/**
* This defines a simple schema with two tables:
* - users: a table of users
* - posts: a table of social posts
*
* The schema has two RLS policies:
* - users: admin-only
* - posts: anyone can read, authenticated users can modify their own posts
*/




// private table, without RLS policies this is admin-only
export const users = pgTable("users", {
 userId: text("user_id").primaryKey(),
 email: text("email").unique().notNull(),
 createdAt: timestamp("created_at").defaultNow().notNull(),
 updatedAt: timestamp("updated_at").defaultNow().notNull(),
}).enableRLS();


// posts table with RLS policies
// - anyone can read
// - authenticated users can read any post and can modify their own posts
export const posts = pgTable(
 "posts",
 {
   id: text("id").primaryKey(),
   title: text("title").notNull(),
   content: text("content").notNull(),
   userId: text("userId").references(() => users.userId),
 },
 (table) => [
   // anyone (anonymous) can read
   crudPolicy({
     role: anonymousRole,
     read: true,
   }),
   // authenticated users can read any post, and modify only their own posts
   crudPolicy({
     role: authenticatedRole,
     read: true,
     // `userId` column matches `auth.user_id()` allows modify
     modify: authUid(table.userId),
   }),
 ],
);

In this schema, we’re using Postgres for a bunch of different things:

– Column uniqueness

– Referential integrity

– Cascade deletes

– And with Authorize: access rules!

Of course, one can also just keep all these rules in “regular application code”. We’re not forcing anyone to use RLS policies. By having authenticated database requests with JWTs, developers can make use of their payloads in WHERE clauses from their app’s backend as well.

Get started with Neon RLS + Drizzle + Clerk

If you’re using Clerk, we have a tutorial to help you get set up quickly, using a sample todos app built with Next.js. Also in this repo:

https://github.com/neondatabase-labs/clerk-nextjs-neon-authorize

What you’ll learn:

How to configure Neon RLS with Clerk for authentication
How to set up RLS policies via Drizzle in a clear, declarative way alongside your schema
How to test and verify your setup to ensure smooth, secure access control

Wrapping Up

Neon RLS is just the start of our journey towards making application development faster with Postgres. We hope to partner with more authentication providers and ORMs in the future to streamline all of this even more.

One of the novelties that comes out of this new feature is that you can now develop applications that are entirely client-side without a server/backend. We believe that for simple apps, you can get away with hosting them (for free) on GitHub Pages and then using Neon together with your auth provider of choice, without a backend. However, for more serious projects, we still recommend that you build a backend to protect your database.

RLS for everything or not?

Whether to use PG RLS for everything or not is an interesting debate. For the most part, we recommend defining some RLS rules for very important and core authorization logic. For example, multi-tenant enterprise applications can definitely benefit from having RLS for extra security. However, it’s probably better to define very intricate access logic in your backend code.

Since all of this is a bit novel, we’re hoping to get a lot of feedback from the community. So, we’ve created a channel for #neon-authorize on our Discord server. Please reach out!