DEV Community: David Neal

Build Your First CRUD API with Node.js, MongoDB, and Claude Code

David Neal — Wed, 28 Oct 2026 17:59:10 +0000

Atlas Ephemeral Clusters let you create a temporary, free MongoDB Atlas database with a single API call, with no account or API keys. In this tutorial, Claude Code provisions an ephemeral cluster, builds a Fastify CRUD API against it, and then you claim the cluster to keep your data.

You know the free sample stations at the warehouse club? Nobody hands you a clipboard before you get the tiny cup of ravioli. Nobody asks you to verify your email address, pick a subscription tier, or configure network access rules. You taste the ravioli. Then you decide if it goes in the cart.

Now think about the last time you wanted to try an idea against a real cloud database. Create an account. Verify the email. Create an organization. Create a project. Pick a cloud provider and a region. Create a database user. Allow-list your IP address. Somewhere around step six, the idea you were excited about has quietly left the building.

That friction is worse now that AI coding agents are in the mix. Tools like Claude Code can scaffold an entire API in minutes, but they'd historically hit a wall at "please go click through a signup form." The agent can write the code. It still can't taste the ravioli for you.

The new Atlas Ephemeral Clusters feature gives you a real, live MongoDB Atlas database from a single API call. No signup, no API keys. Make one call, receive a connection string, and about 15 seconds later you (or your AI agent) are writing data to the cloud.

In this tutorial, we'll put that to the test by having Claude Code build a complete Task Board API with Node.js, Fastify, and MongoDB Atlas. First, here's what we'll cover.

What you'll learn

How to provision a MongoDB Atlas database with one curl command
How to prompt an AI agent to provision the database and build a full CRUD API against it
How to evolve the schema on a live prototype without a rewrite
What happens when an ephemeral cluster expires
How to claim your cluster and keep your data

Note: Want to skip ahead? The finished Task Board API is on GitHub. You'll still need your own ephemeral cluster, so start with Step 1, then point the code at your new connection string.

What is an ephemeral cluster?

An ephemeral cluster is a temporary, free MongoDB Atlas cluster you can create without an Atlas account or API keys. With one API call, you get back everything you need to start building:

Field	What it's for
`connectionString`	A ready-to-use `mongodb+srv://` URI with credentials baked in
`clusterId`	The cluster's ID, used to check its status (and to look up a lost `claimUrl`)
`claimUrl`	A link to attach the cluster to an Atlas account and keep it (valid for 7 days after creation)
`expiresAt`	When the unclaimed cluster is paused and goes offline (it isn't deleted yet)
`status`	Cluster state: `PROVISIONING`, `ACTIVE`, or `PAUSED` (you're looking for `ACTIVE`)
`termsOfService`	The legal fine print you're agreeing to by using it

That makes ephemeral clusters perfect for prototypes, demos, workshops, and "I just want to try something" moments. It's the perfect scratch database, and you can convert it to a permanent database if you choose.

Keep a few caveats in mind while the cluster is unclaimed:

There's no dashboard until you claim it.
Network access is open to any IP address.
Anyone holding the connection string can read and write your data.

How long does an ephemeral cluster last?

An unclaimed cluster stays live for a couple of days. When expiresAt passes, the cluster is paused: it goes offline, and your app can't reach it. Your data isn't deleted, though.

The claimUrl remains valid for up to 7 days after the cluster is created. Claim it within that window (before or after it pauses), and it converts into a permanent free-tier Atlas cluster. Your data comes along for the ride. Miss the 7-day window, and the cluster and its data are deleted for good.

Time after creation	What happens
About 15 seconds	Status changes to `ACTIVE`, and the cluster is ready to use
2 days	The cluster pauses: it goes offline, but your data is kept
Up to 7 days	The `claimUrl` still works, even if the cluster is paused
After 7 days	The unclaimed cluster and its data are deleted

What are the limits of an ephemeral cluster?

An unclaimed cluster is a free M0 cluster with the usual free-tier limits:

Setting	Value
Cluster tier	`M0` (free)
Cloud provider and region	AWS `us-east-1`
MongoDB version	8.0
Storage	512 MB
Throughput	100 operations per second
Connections	500 concurrent connections

You can't add database users, restrict IP access, or scale the cluster until you claim it.

MongoDB also caps the number of ephemeral clusters everyone can create in total. If the API responds with a 429, create a standard free cluster instead. See the Ephemeral Clusters docs for the details.

Why are ephemeral clusters useful for AI agents?

MongoDB has always been a flexible choice across the development lifecycle. Your data can change as your application evolves, and you can use the same database from first sketch to production scale. Getting started used to be the most friction-filled part of the journey. With Atlas Ephemeral Clusters, that part now takes one API call and no forms.

For AI agents, an ephemeral cluster is the perfect solution. An agent can provision its own database in the middle of a session, wire it up, and keep building. It no longer has to stop and wait for a human to click through a web console.

How do you create an Atlas ephemeral cluster?

Before we hand the keys to an agent, let's see how the API works. This is the entire database provisioning process:

curl -sS -X POST 'https://cloud.mongodb.com/api/atlas/v2/unauth/ephemeralClusters:create' \
 -H 'Accept: application/vnd.atlas.preview+json'

If you were to run that command, you'd get a response like this (with real values where you see placeholders):

{
  "claimUrl": "https://account.mongodb.com/account/register?claimId=<claimId>",
  "clusterId": "<clusterId>",
  "connectionString": "mongodb+srv://<username>:<password>@cluster0.xxxxxxx.mongodb.net/",
  "expiresAt": "2026-10-18T17:29:07Z",
  "status": "PROVISIONING",
  "termsOfService": "By using this API and any resources provisioned through it, you agree to be bound by MongoDB's Cloud Terms of Service at https://www.mongodb.com/legal/terms-and-conditions/cloud; and Privacy Policy at https://www.mongodb.com/legal/privacy/privacy-policy."
}

Notice the status says PROVISIONING. The cluster needs a moment to spin up, so check on it using the clusterId:

curl -sS 'https://cloud.mongodb.com/api/atlas/v2/unauth/ephemeralClusters/<clusterId>' \
 -H 'Accept: application/vnd.atlas.preview+json'

When I tried it, the status came back ACTIVE after about 15 seconds. At that point, the connectionString points to a live cluster you can connect to and get to work. Done!

One command in, one database out. Sweet.

How to keep your ephemeral cluster credentials safe

One thing to watch: the status response replaces the password in connectionString with a <db_password> placeholder. The create response is the only time Atlas returns the real password. Save that first response somewhere safe and git-ignored.

Treat the claimUrl and clusterId as secrets, too. Anyone who has them can claim your cluster.

Now let's see what an AI agent can do with it.

What do you need to build a CRUD API with Claude Code?

Before we jump into building the API, you’ll need the following installed on your computer:

Node.js version 24 or higher (latest LTS recommended)
Claude Code (or equivalent AI agent)
curl for testing the API (already installed, if you have a modern OS)
mongosh (optional) so the agent can verify the database connection
jq (optional) for working with JSON on the command line; get it from jqlang.org

Pro tip: To make it even easier for Claude Code to work with MongoDB, install the MongoDB Claude Plugin with claude plugin install mongodb@claude-plugins-official. It bundles the MongoDB MCP Server, so the agent can query your database directly, and MongoDB Agent Skills for tasks like schema design and query optimization.

Step 1: How to provision a MongoDB database with Claude Code

We could run those curl commands ourselves, but there's no need. The Ephemeral Clusters docs are written so an agent can follow them, which means the provisioning prompt can be short. Create an empty project folder, start Claude Code in it, and give it this prompt:

Create a MongoDB Atlas Ephemeral Cluster for this project by following
https://www.mongodb.com/docs/atlas/tutorial/create-ephemeral-cluster/

Save the connection details to a git-ignored .env file, wait until the
cluster is ACTIVE, and confirm you can connect. Then tell me when it
expires and how to claim it.

What's happening in this prompt?

The docs do the heavy lifting. Instead of pasting the API call into the prompt, we point the agent at the documentation. It reads the endpoint, headers, and response fields for itself.
We tell it where the secrets go. The connection string has credentials baked in, and the password only comes back once. A git-ignored .env file keeps it safe and ready for the app.
"Wait until ACTIVE" saves us a headache. Without it, an eager agent might start building against a cluster that's still provisioning.
We ask for the expiration and claim details up front. So the expiration date doesn't sneak up on us. (Spoiler: it snuck up on me anyway.)

Agents improvise, so your session won't match mine word for word. In my run, Claude Code:

Called the create endpoint, then checked the status until the cluster reported ACTIVE
Connected with mongosh and got a successful ping back from MongoDB 8.0
Saved MONGODB_URI, ATLAS_EPHEMERAL_CLUSTER_ID, and ATLAS_EPHEMERAL_CLAIM_URL to .env
Saved the raw API response to .ephemeral-cluster.json and added both files to .gitignore
Warned me not to delete those files, since the create call is the only time Atlas returns the real password
Told me the cluster pauses in 2 days and is deleted after 7, that only a human can open the claim URL, and summarized the free-tier limits

We have a live cloud database and haven't written a line of code yet. Time to fix that.

Step 2: How to build a Fastify CRUD API with Claude Code

Now for the fun part. In the same session, give Claude Code the spec for the Task Board API:

Build a Task Board API in this folder with Node.js, Fastify, and the
official MongoDB Node.js driver, using MONGODB_URI from .env.

- Boards: name, description, owner, createdAt
- Cards: title, description, status ("todo", "in-progress", "done"),
  position, boardId, createdAt, updatedAt
- Full CRUD for boards, and for cards under /boards/:boardId/cards
- Routes to reorder cards and to move a card to a different status
- Deleting a board also deletes its cards
- Validate input with Fastify JSON schemas, use proper HTTP status codes,
  and add GET /health
- Write a README with setup steps and example curl commands
- No auth or frontend yet

When you're done, start the server and smoke test every route against
the cluster.

What's in this prompt?

The data model and routes are spelled out. Boards and cards, nesting, reorder and move routes. We own the design, and the agent fills in the implementation.
The details that matter are explicit. Validation, status codes, and the cascading delete are the kinds of things that get skipped when you don't ask for them.
Out-of-scope is explicit, too. Telling an agent what not to build is just as valuable as telling it what to build. (Agents will happily build all kinds of things you didn't ask for.)
We ask it to prove it works. The smoke test runs against the real cluster, not a mock.

Here's the flow you can expect Claude Code to follow without any additional help from you:

Scaffold the project:
- A config module
- A MongoDB connection plugin with indexes
- JSON schemas for validation
- Route files for health, boards, and cards
- A Fastify app factory with centralized error handling
- A server entry point with graceful shutdown
Write a README.md with setup instructions and example curl commands
Start the server and run an end-to-end smoke test against the live cloud cluster: create, read, update, delete, reorder, move, cascade delete, plus 400 and 404 cases.

The wild part is the smoke test. Minutes after creating the project folder, the agent is testing your API against a real Atlas cluster in the cloud. Same session, no signup, no console, no "hold on while I go create a database user."

Step 3: How to test your API with curl

Trust, but verify. With the server running (start it using the instructions in the generated README), let's hit the API ourselves.

First, the health check, which pings the database:

curl -s http://localhost:3000/health

You should get back a response showing the API is up and the database connection is healthy. Next, create a board and add a card to it:

curl -s -X POST http://localhost:3000/boards \
  -H 'Content-Type: application/json' \
  -d '{"name": "Launch Plan", "description": "Everything for the big day", "owner": "user-david"}'

# Grab the board id from the response, then:
curl -s -X POST http://localhost:3000/boards/<boardId>/cards \
  -H 'Content-Type: application/json' \
  -d '{"title": "Write the announcement post", "status": "todo"}'

Each create request returns a 201 with the new document, including its generated id. Grab those ids to drill deeper into the API. And remember, every document you create is landing in a real MongoDB Atlas cluster that didn't exist five minutes ago.

Pro tip: Ask the agent to generate verification commands for you. Prompt it with "Give me the commands I can use to verify the data returned by the API," and you'll get back a full curl + jq walkthrough of the data tree, including a one-shot script with counts at every level.

Step 4: How to add a new collection without a migration

Here's where MongoDB's flexibility earns its keep. A prototype's data model is never done. With a document database, adding a collection doesn't mean migrations, downtime, or a sad afternoon of writing SQL scripts.

Let's add a Comments feature so users can discuss individual cards. Same session, same database, one follow-up prompt:

Add a Comments feature so users can discuss individual cards.

- Comments: text, author, cardId, createdAt
- Full CRUD under /boards/:boardId/cards/:cardId/comments
- Deleting a card deletes its comments, and deleting a board deletes
  the comments on all of its cards
- Follow the existing patterns for validation and status codes
- Add the new routes to the README with example curl commands

Watch for Claude Code to add the comments collection and index, the nested routes, and the cascading deletes (board → cards → comments). Then it updates the README and verifies the whole thing end-to-end. A new feature and a new collection, with no migration scripts in sight.

How to seed realistic sample data with Claude Code

To make the prototype feel real, follow up with one more prompt: "Seed the boards, cards, and comments with sample projects and tasks. The information should be realistic."

Expect the agent to write a seed script with a few plausible projects, wire it up to npm run seed, and fill your board with realistic data.

My run produced 3 boards, 11 cards, and 13 comments across a website redesign, a mobile app release, and a platform API. It even included staggered timestamps and multi-author comment threads. Not bad for a one-sentence prompt.

Step 5: What happens when an ephemeral cluster expires?

This is a step you don't have to repeat, because I took the hit for you. I started building this on a Friday, came back to the project after the weekend, and asked Claude Code to check on the database. The verdict:

The cluster had passed its expiresAt date, unclaimed
The API couldn't reach the database at all

Whoops.

For a moment, I assumed the worst: cluster deleted, seed data gone, start over. The good news is not all was lost. When an ephemeral cluster expires, it's paused, not destroyed. The cluster goes offline, and your app stops working. Your data, though, is still sitting there, and the claimUrl works for up to 7 days after the cluster was created.

So I opened the claimUrl the agent saved back in Step 1 (told you we'd want it later). I created my Atlas account and claimed the "dead" cluster. It came back online as a standard free-tier Atlas cluster with every board, card, comment, and seed document intact.

Even better, the original connection string and credentials keep working after a claim. I didn't have to touch .env, and I kept right on prototyping.

Two lessons from my scare:

Treat expiresAt as the day your prototype goes offline, not the day you lose everything
The claimUrl is your safety net, which is exactly why we had the agent save the cluster details in Step 1

If you ever lose the claimUrl, the agent can look it up again with the clusterId and the status endpoint.

What if you miss the 7-day claim window?

If you miss the full 7-day claim window, recovery still takes one prompt: "Provision a fresh ephemeral cluster and re-seed." Claude Code then:

Calls the API to create a new cluster
Drops the new connection string into .env
Updates the saved cluster info
Re-runs the seed script
Verifies the data via the API

Total damage: about a minute. But claiming beats rebuilding, which brings us to the last step.

Step 6: How to claim an ephemeral cluster and keep your data

Don't wait for the expiration scare as I did. When you know you want to keep what you've built, open the claimUrl in a browser. This is the one step an agent can't do for you. Here's how it goes:

Sign in to your MongoDB Atlas account, or create one (new accounts verify their email first).
Choose an existing organization, or create a new one for the cluster.
Configure IP access. The cluster has been open to any IP address (0.0.0.0/0), so this is a good moment to allow only your own IP address.
Click Claim Cluster. This is a one-time action and can't be undone.

Your cluster lands in a new project, and your data comes along. You get full admin access to scale it, add database users, and lock it down. It no longer expires, though like any free-tier cluster, Atlas pauses it after 30 days of inactivity.

Here's what I love about this design: the signup form didn't disappear; it just moved to the end. You sign up after the database has proven it's worth keeping, not before you've written a line of code. And because it becomes a standard Atlas cluster, your prototype's database can graduate to production without switching engines.

The 7-day claim window is forgiving but not infinite, and your prototype goes offline the moment it expires. Claim early and skip the drama. Learn from my ravioli.

What should you build next with ephemeral clusters?

Back to the sample station. Free samples work because you get to taste before you commit. Atlas Ephemeral Clusters bring the same deal to databases. You and your AI agent get a real cluster first, and you only sign up after the prototype has proven useful.

This Task Board API has plenty of room to grow. Next up, you may want to explore one of the most useful design decisions in MongoDB, embedded vs. referenced documents, by adding checklists to cards. Unlike comments, checklists belong inside the card document. After that, consider adding:

Filtering and search
Users and assignments
An aggregation-powered stats endpoint
Authentication, to take this thing from prototype to production-ready

In the meantime:

Try the one-liner yourself and see how fast you're connected
Point your favorite AI agent at it with the prompts above and swap in your own app idea
Grab the complete Task Board API source code on GitHub
Read the Ephemeral Clusters documentation for the full API reference and limits
Install the MongoDB Claude Plugin to give your agent the MCP Server and MongoDB Agent Skills
Dig into the MongoDB Node.js driver docs to see what the agent wired up under the hood
Set a reminder to claim your cluster (seriously)

Now go forth and prototype something cool! If you build something fun on an ephemeral cluster, I'd love to hear about it. What would you build if the database was never the hard part?

Key takeaways

One API call creates a live MongoDB Atlas cluster, with no account or API keys.
Unclaimed clusters pause after 2 days. You can claim them for up to 7 days after creation; after that, they're deleted.
AI agents like Claude Code can provision and use the database without leaving the session.
MongoDB's flexible document model lets you add collections to a live prototype without migrations.
Claiming converts the cluster to a standard free-tier Atlas cluster, and your data and connection string keep working.

FAQs

Do I need a MongoDB Atlas account to use an ephemeral cluster?

No. You can create an ephemeral cluster with a single API call, with no account, email verification, or API keys. You only need an Atlas account to claim the cluster and keep it.

How long does an Atlas ephemeral cluster last?

An unclaimed ephemeral cluster stays active for 2 days. After that, it pauses and goes offline, but your data is kept. You can claim it for up to 7 days after it was created. After 7 days, the unclaimed cluster and its data are deleted.

What happens to my data when an ephemeral cluster expires?

Your data isn't deleted when the cluster expires. The cluster pauses, so your app can't connect to it. If you claim the cluster within 7 days of creating it, it comes back online with your data intact.

Can I use an ephemeral cluster in production?

Not while it's unclaimed. Unclaimed clusters are open to any IP address, can't have their own database users, and expire. After you claim one, it becomes a standard free-tier Atlas cluster that you can secure, scale, and take to production.

Can I use ephemeral clusters with AI agents other than Claude Code?

Yes. The Ephemeral Clusters API is a plain HTTP API, and the docs are written so any agent can follow them. Any AI coding agent that can make HTTP requests can provision and use an ephemeral cluster.

Build a Command-Line Application With Deno 2.0

David Neal — Mon, 11 Nov 2024 19:07:28 +0000

Command-line interfaces (CLI) are often used for automating tasks, such as building reports, synchronizing data between systems, migrating data, deploying applications, and so on and on. Over the years, I have built countless CLI apps to save time. If I ever find myself doing something more than once, I try to find a way to automate it!

Deno 2.0 is an excellent solution for writing CLI apps. It supports TypeScript and JavaScript, it's cross-platform (runs on Windows, macOS, and Linux), has dozens of powerful tools in its standard library, and can also tap into most Node.js modules. The only limit is your imagination!

In this tutorial, you will learn how to:

Create a command-line interface with Deno 2.0
Parse command-line arguments
Print help and version information
Prompt for additional information
Compile your app into a standalone executable

Set Up Your CLI Project

First, let's make sure you have the tools you need!

Install Deno
A good text editor, such as Visual Studio Code

Open your computer's terminal (or command prompt). Change the current directory to the folder where you normally save projects.

Note: If you don't already have a folder where you store software projects, I like creating a folder at the root of my home directory named projects. More than likely, when you open your computer's terminal/console app, you are automatically placed in your "user home" folder. Use mkdir projects (or md projects if you're on Windows) to create the folder. Then, use cd projects to change to that new folder.

Verify you have Deno 2.0 (or higher) installed using the following command.

deno --version

You should see something like:

deno 2.0.5 (stable, release, aarch64-apple-darwin)
v8 12.9.202.13-rusty
typescript 5.6.2

If you receive an error, or if your version of Deno is 1.x, follow the installation.

Next, enter the following commands to initialize a new Deno project.

deno init deno-cli-demo
cd deno-cli-demo

We're going to use Deno's @std/cli standard library, so add that to the project using the following command.

deno add jsr:@std/cli

Create Your First CLI App

Open up your new project using your preferred editor. Create a new file named hello.ts and add the following code.

const now = new Date();
const message = "The current time is: " + now.toTimeString();

console.log("Welcome to Deno 🦕 Land!");
console.log(message);

From your terminal, enter the following command to run the script.

deno run hello.ts

You've built your first Deno CLI application! Feel free to play around with writing other things to the console.

Using Command-Line Arguments

Arguments? No, we're not talking about getting into a heated debate with your terminal. Although that can certainly happen. Computers can be rather obstinate.

Command-line arguments are options and values you might provide the CLI when you run the app. When you enter deno run hello.ts, deno is the CLI, and run hello.ts are two arguments you provide to the CLI.

Create a new file named add.ts and add the following code.

import { parseArgs } from "@std/cli/parse-args";

const args = parseArgs(Deno.args);
console.log("Arguments:", args);
const a = args._[0];
const b = args._[1];
console.log(`${a} + ${b} = ` + (a + b));

The idea is to take two numbers and add them together. Try it out!

deno run add.ts 1 2

Experiment with additional arguments. Or none at all. The parseArgs function can also handle arguments traditionally called switches and flags. Try the following and observe the output.

deno run add.ts 3 4 --what=up -t -y no

Advanced Command-Line Arguments

We've only just scratched the surface of what you can do with command-line arguments. Let's try a more advanced example!

Create a new file named sum.ts and add the following code.

import { parseArgs, ParseOptions } from "@std/cli/parse-args";
import meta from "./deno.json" with { type: "json" };

function printUsage() {
    console.log("");
    console.log("Usage: sum <number1> <number2> ... <numberN>");
    console.log("Options:");
    console.log("  -h, --help        Show this help message");
    console.log("  -v, --version     Show the version number");
}

const options: ParseOptions = {
    boolean: ["help", "version"],
    alias: { "help": "h", "version": "v" },
};
const args = parseArgs(Deno.args, options);

if (args.help || (args._.length === 0 && !args.version)) {
    printUsage();
    Deno.exit(0);
} else if (args.version) {
    // Pro tip: add a version to your deno.json file
    console.log(meta.version ? meta.version : "1.0.0");
    Deno.exit(0);
}

// validate all arguments are numbers
const numbers: number[] = args._.filter((arg) => typeof arg === "number");
if (numbers.length !== args._.length) {
    console.error("ERROR: All arguments must be numbers");
    printUsage();
    Deno.exit(1);
}
// sum up the number arguments
const sum = numbers.reduce((sum, val) => sum + val);

// print the numbers and the total
console.log(`${numbers.join(" + ")} = ${sum}`);

Whoa, there's a lot going on here 😬 Let's try it out first, and then we'll cover some of the highlights. Try the following commands and see how the output changes.

deno run sum.ts 1 2 3 4 5
deno run sum.ts --help
deno run sum.ts --version
deno run sum.ts -h
deno run sum.ts 1 2 three

Now, if you go back and look through the code in sum.ts, you can probably figure out some of the logic involved in handling the different arguments. The main thing I want to point out is this block of code.

const options: ParseOptions = {
    boolean: ["help", "version"],
    alias: { "help": "h", "version": "v" },
};
const args = parseArgs(Deno.args, options);

The parseArgs function supports quite a few options to support a wide variety of arguments.

boolean: ["help", "version"]: defines the --help and --version flags.
alias: { "help": "h", "version": "v" }: defines alternate -h and -v flags.

As you may have guessed, Deno.exit(0); causes Deno to immediately stop the current script.

More Input Required (Prompts)

Imagine you're creating a CLI app to automate a report. Your app might connect to a system that requires authentication, such as a database or API.

Never embed secrets (sensitive information such as user names, passwords, API keys, connection strings, etc.) in your code. You don't want your secrets ending up in the hands of the wrong people!

In this case, the CLI should prompt for the sensitive information when it runs. Let's create another example to demonstrate how this is done.

First, add a new dependency using the following command.

deno add jsr:@std/dotenv

Create a new file named taskRunner.ts and add the following code.

import { Spinner } from "@std/cli/unstable-spinner";

function sleep(ms: number): Promise<void> {
    return new Promise((resolve) => setTimeout(resolve, ms));
}

export async function simulateTask(ms: number, message: string) {
    const spinner = new Spinner({ message, color: "yellow" });
    const start = performance.now();
    spinner.start();
    await sleep(ms);
    spinner.stop();
    const finish = performance.now();
    const duration = Math.round((finish - start) / 100) / 10;
    console.log(`${message} (${duration.toFixed(1)}s).`);
}

This is a module that exports a function named simulateTask that we'll use from the CLI app. The simulateTask function includes a few tricks, such as keeping track of how long the task runs and displaying a cool spinning animation while the task is running 🤓

Create a new file named updater.ts and add the following code.

import "@std/dotenv/load";
import { parseArgs, ParseOptions } from "@std/cli/parse-args";
import { promptSecret } from "@std/cli/prompt-secret";

import meta from "./deno.json" with { type: "json" };
import { simulateTask } from "./taskRunner.ts";

function printUsage() {
    console.log("Usage: ");
    console.log("  updater --input <input file> --output <output file>");
    console.log("Options:");
    console.log("  -h, --help        Show this help message");
    console.log("  -v, --version     Show the version number");
    console.log("  -i, --input       Input file");
    console.log("  -o, --output      Output file");
}

const options: ParseOptions = {
    boolean: ["help", "version"],
    string: ["input", "output"],
    default: { "input": "data.csv", "output": "report.pdf" },
    alias: { "help": "h", "version": "v", "input": "i", "output": "o" },
};
const args = parseArgs(Deno.args, options);

if (args.help) {
    printUsage();
    Deno.exit(0);
} else if (args.version) {
    // Pro tip: add a version to your deno.json file
    console.log(meta.version ? meta.version : "1.0.0");
    Deno.exit(0);
}

// validate the input and output arguments
if (!args.input || !args.output) {
    console.log("You must specify both an input and output file");
    printUsage();
    Deno.exit(1);
}

// attempt to get the username and password from environment variables
let user = Deno.env.get("MY_APP_USER");
let password = Deno.env.get("MY_APP_PASSWORD");

if (user === undefined) {
    const userPrompt = prompt("Please enter the username:");
    user = userPrompt ?? "";
}
if (password === undefined) {
    const passPrompt = promptSecret("Please enter the password:");
    password = passPrompt ?? "";
}

// simulating a few long-running tasks
await simulateTask(1000, `Reading input file [${args.input}]`);
await simulateTask(1500, `Connecting with user [${user}]`);
await simulateTask(5000, `Reading data from external system`);
await simulateTask(3200, `Writing output file [${args.output}]`);

console.log("Done!");

Some of this code may look familiar to the previous sum.ts CLI example. Try running the app and see what happens!

deno run updater.ts --help

Did you get a strange message like ⚠️ Deno requests read access to...? What's going on here?

Deno security and permissions

Deno is secure by default. It won't be able to read/write files, access your local environment variables, connect to your network, and a number of other potentially risky operations unless you explicitly give it permission.

Now run it using the following command. Don't worry. It's not doing anything; it's just simulating what a real app might look like.

deno run --allow-read --allow-env updater.ts

Wasn't that cool??

Deno tasks

However, including those permissions is a lot to type every time you want to run the CLI app. Let's add a task to make it easier. Open up your deno.json file and update the "tasks" with the following.

"tasks": {
    "updater": "deno run --allow-read --allow-env updater.ts"
},

Now you can use the following command.

deno task updater --input data.csv --output report.pdf

Prompts and environment variables

Let's revisit the code in updater.ts. Specifically, this block of code.

// attempt to get the username and password from environment variables
let user = Deno.env.get("MY_APP_USER");
let password = Deno.env.get("MY_APP_PASSWORD");

if (user === undefined) {
    const userPrompt = prompt("Please enter the username:");
    user = userPrompt ?? "";
}
if (password === undefined) {
    const passPrompt = promptSecret("Please enter the password:");
    password = passPrompt ?? "";
}

It's common practice to store app configuration as environment variables. Deno can access environment variables (with permission) using Deno.env.get(). If MY_APP_USER or MY_APP_PASSWORD are not set as environment variables, the app will use prompt() or promptSecret() to ask for those values. As you've already seen, promptSecret() hides the characters you type.

Remember the dependency we added for jsr:@std/dotenv? This standard library reads a file named .env and adds any values as environment variables.

Create a new file in the project named .env and add the following text.

MY_APP_USER=loluser
MY_APP_PASSWORD=p@ssw0rd1

Now run the updater task again. It should run without prompting you for a username or password.

Compile Your CLI App to an Executable

Want to share your CLI app with others or run the app on another computer? You can compile a Deno-powered CLI app into a standalone executable! Standalone means it can run without installing Deno or any of the libraries. Everything is bundled 📦

Pro tip: Use a task scheduler to run the executable periodically.

deno compile --allow-read --allow-env updater.ts

You should now have an executable version!

./updater --help

Among other things, you can create executables for other platforms.

Wrapping Up and Additional CLI Tools for Deno

Thank you for joining me on this journey of learning Deno! If you have any questions or suggestions, please drop them in the comments.

Get the source code for the examples
Connect with me: X/Twitter | BlueSky | Threads | YouTube | LinkedIn

Here are more CLI tools for Deno you might explore!

ask: additional command-line prompts for Deno.
chalk: custom text styles and color for the command-line.
cliffy: advanced command-line tools for Deno.

Build Web Apps Absurdly Fast with Vite

David Neal — Fri, 13 Sep 2024 11:55:29 +0000

Let’s face it: the frontend build process has been slow and complicated for too long. Whether you’re dealing with Webpack, Parcel, or your custom Frankenstein monster setup (we’ve all been there), configuring and bundling a web app can be a drag.

Vite is the new kid on the block, ready to blow your mind with speed and simplicity. And Vite isn’t just important for developers; it’s a game-changer for businesses. Speedy development cycles equals happy devs. Happy devs build better code. That means faster time-to-market and lower costs for your business or clients.

Vite is designed to make the pain of slow builds disappear. It takes advantage of native ES modules in the browser, eliminating the need for bundled code on dev builds. Translation: You get hot module replacement (HMR) so fast that your F5 key will feel neglected. Let’s dive into how you can make your projects Vite-powered and never look back.

Vite is a French word meaning “quick” or “fast.” It’s pronounced “veet” and rhymes with meet.

Why Vite? Ain’t nobody got time for slow builds

We all know how painful it is to stare at our screen, watching that progress bar crawl along. It’s enough to make you question your life choices.

Vite offers near-instantaneous cold server start, lightning-fast HMR, and builds that are quicker than you can say “npm install.”

Lightning-fast dev startup: Traditional tools like Webpack bundle all your code before serving it. Vite uses native ES modules to serve your code, so it starts fast — the browser loads only what it needs.
Hot Module Replacement: Changes reflect instantly, making your development experience smoother than a jazz saxophone solo.
Out-of-the-box TypeScript support: Vite handles TypeScript without setting up a complicated build pipeline.
Optimized builds: When it’s time to ship, Vite uses Rollup to bundle your code efficiently. It splits your code into chunks, so users aren’t downloading stuff they don’t need.

Get started with Vite

Let’s take Vite for a spin and find out what it can do!

Step 1: Set up your Vite project

First things first, let’s create a new Vite project. Assuming you have Node.js installed, open up your terminal and run:

npm create vite@latest my-awesome-vite-project -- --template react

This command creates a new Vite project with React. Feel free to replace “react” with “vue” or “vanilla” if that’s more your jam. Svelte, Preact, Qwik, and others are supported, too!

Step 2: Install dependencies and run the dev server

Now, let’s install our dependencies and fire up that blazing-fast dev server:

cd my-awesome-vite-project
npm install
npm run dev

Boom! Your dev server is now running faster than a caffeinated squirrel. Open up your browser. Change one of the source files and marvel at the speed!

Step 3: Structure your project

Vite gives you a pretty bare-bones structure to start with. Here’s a typical setup:

my-awesome-vite-project/
├── public/
│   └── vite.svg
├── src/
│   └── assets/
│       └── react.svg
│   ├── App.css
│   ├── App.jsx
│   ├── index.css
│   └── main.jsx
├── index.html
└── vite.config.js

Feel free to add more folders like styles, utils, or services. Vite won’t judge you.

Step 4: Customize your Vite config

Open up vite.config.js, and let’s add a few settings:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig( {
  plugins: [ react() ],
  server: {
    port: 3000,
  },
  build: {
    outDir: "dist",
    sourcemap: true,
  },
} );

This config sets up your dev server port, output directory for builds, and enables source maps. There are lots more ways to configure Vite to meet your needs!

Step 5: Add some code and watch the magic happen

Let’s create a new component to see Vite’s HMR in action. Create a new file src/Hello.jsx:

import { useState } from "react";

export default function Hello() {
  const [ name, setName ] = useState( "World" );

  return (
    <div>
      <h1>Hello, {name}!</h1>
      <input
        type="text"
        value={name}
        onChange={( e ) => setName( e.target.value )}
        placeholder="Enter a name"
      />
    </div>
  );
}

Now, import and use this component in your App.jsx:

import { useState } from "react";
import reactLogo from "./assets/react.svg";
import viteLogo from "../public/vite.svg";
import "./App.css";
import Hello from "./Hello.jsx";

function App() {
  const [ count, setCount ] = useState( 0 );

  return (
    <>
      <Hello />
      <div>
        <a href="https://vitejs.dev" target="_blank">
          <img src={viteLogo} className="logo" alt="Vite logo" />
        </a>
        <a href="https://react.dev" target="_blank">
          <img src={reactLogo} className="logo react" alt="React logo" />
        </a>
      </div>
      <h1>Vite + React</h1>
      <div className="card">
        <button onClick={() => setCount( ( count ) => count + 1 )}>
          count is {count}
        </button>
        <p>
          Edit <code>src/App.jsx</code> and save to test HMR
        </p>
      </div>
      <p className="read-the-docs">
        Click on the Vite and React logos to learn more
      </p>
    </>
  );
}

export default App;

Save these files and watch as Vite updates your app faster than you can say, “Why didn’t I switch to Vite sooner?”

Neat stuff Vite can do

Vite isn’t a one-trick pony. It’s got some cool features:

Static assets? Got you covered: Vite optimizes your images and other assets automatically.
Environment variables? Yep: Use .env files to manage different environments easily.
Plugins? Tons of ’em: Need more features? There’s probably a plugin for that.
CSS pre-processors? Sure thing: Want to use Sass? Just install it and start using it. Vite figures out the rest.

Example of adding Sass to Vite

npm install --save-dev sass

Create a file named App.scss in the src folder and add some code, such as:

$awesome-color: #ff69b4;
.card {
    color: $awesome-color;
}

Update App.jsx to import the new Sass file:

import './App.scss';

Wrapping up: Vite is sweet!

Speed matters – Vite’s dev server is so fast you’ll forget you ever had to refresh a page.
Easy setup – With one simple command, you can spin up a project, ready to go.
Framework agnostic – Whether you’re into React, Vue, Svelte, Preact, Solid, Qwik, or you prefer the taste of plain vanilla JavaScript, Vite has your back.
Production ready – Rollup optimization ensures your code is as lean and fast as possible.

Now, go forth and build something awesome! Vite it!

About Me

Hi, I’m David! I’ve been a web developer pretty much since the beginning of the “World Wide Web”. My mission is to help folks in technology be more awesome! I also do all my own stunts… I mean… illustrations and graphics. You can learn more about me over on my website ReverentGeek.com.

Three Ways to Share Node.js Modules Across Multiple Projects

David Neal — Fri, 14 May 2021 16:59:46 +0000

A friend recently asked me about splitting some of their Node.js application into a shared library to be used across multiple projects. There are at least three solutions, and they all have tradeoffs between convenience and portability.

Move Your Code Into A Separate Project

The first step across all the following options is to move your code into a separate Node.js project. This project will have its own package.json file.

Option 1: Link to a Local Project Folder

Once you've moved your shared code into a separate project, link the project as a dependency using npm link.

npm link [../relative-path-to/library]

Note: The shared library can be maintained in a separate repository or the same repository as your other projects (a.k.a, monorepo).

Pros: Any changes you make to the library project will be immediately available in the other local projects that depend on it. This option is the most convenient method for local development.

Cons: Other developers who work on these projects will have to go through specific steps to set it up. This option is the most inconvenient method for collaborating with other developers, especially if you are not using a monorepo.

Option 2: Install From a Git Repository

Once you've moved your shared code into a separate project, push the library code into a Git repository. Then, install the library as a dependency using npm install.

npm install <git-host>:<git-user>/<repo-name>
# or
npm install <git repo url>

To get a new version of your library into your other projects, push updates to the library repository. Then, run npm update within each project to pull down those changes.

Note: You may want to think through using a specific commit, branch, or tag to control when other projects receive updates.

Pros: You may use private repositories with npm to keep your code safe. And, it is relatively easy for other developers to use your module, as long as they have access to your Git repositories.

Cons: There are more steps involved to share changes with your other projects.

Option 3: Publish to npm

Publishing a library to npm is not as scary as it sounds. The first step is to make sure your package.json has the basic required information.

{
  "name": "my-awesome-library",
  "version": "1.0.0",
  "description": "Use this to become more awesome",
  "main": "index.js",
  "author": "Bacon McBaconFace <username@mydomain.com>",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "git+https://mygithost.com/username/my-awesome-library.git"
  }
}

Note: It's a good idea to include README.md and LICENSE files in your repository.

Next, publish your package to the registry.

npm publish

If you're not already signed in, you will receive a prompt to sign in or create an account.

Finally, install your new package as a dependency using npm.

npm install my-awesome-library

To get a new version of your library into your other projects:

Make changes to the code
Update the version number in package.json file
Push the updates to the git repository
Publish the latest package using npm publish
Run npm update within each project

Pros: Arguably the easiest method for collaborating with other developers since it's the same dependency pattern familiar to Node.js folks. It also increases the opportunity developers will discover your project and use it for themselves.

Cons: The most steps involved to get changes to your library into your other projects.

Did I miss anything? What tips and tricks do you have for sharing modules across multiple projects?

Create PDFs with Node.js and Puppeteer

David Neal — Thu, 06 Feb 2020 17:41:06 +0000

I love to play music, especially in a band. There's something amazing about the synergy of multiple people harmonizing voices and instruments. However, for a band to be successful, everyone needs to be on the same page or it just sounds like a mess.

Come to think of it, I could make a lot of comparisons between a group of people that play well together in a band and a productive, highly-performing software team. But, I digress. Maybe another time!

One way a band to be on the same page is to follow sheet music or chord charts.

I recently updated a personal project named Charter that uses Node.js to convert ChordPro formatted text files into PDF chord charts. It was a lot of fun!

Now, you may be thinking,

"I'm not a musician or singer. Why do I care?"

Regardless of your personal need for chord charts, you might find the source code for this project useful. Here are a few things you might learn:

Create a CLI app using Node.js and Yargs
Load a text file and parse text
Use Jest to test Node.js code
Use handlebars to turn text into HTML
Use Puppeteer to convert HTML into a PDF

Regarding PDF rendering, I tried lots of solutions including wkhtmltopdf, electron-pdf, phantomjs, automating Chrome with command-line switches, and finally landed on using the latest version of Puppeteer. Puppeteer supports a ton of options for generating PDFs. There's a lot of untapped potential here for doing lots of cool things!

Save Any Web Page to PDF using Node.js

Assuming you already have Node.js installed, open your terminal or command line, create a new project folder, and initialize it.

mkdir pdf-test
cd pdf-test
npm init -y

Next, install Puppeteer as a dependency.

npm install puppeteer

Here is an example of how to use Puppeteer to turn the Google home page into a PDF. Create a new file named index.js and paste the following code.

"use strict";

const puppeteer = require("puppeteer");

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto("https://google.com");
  await page.pdf({ path: "./google.pdf", format: "Letter" });
  await browser.close();
})();

Run the application using the following command.

node .

You can change URL to something else, such as the dev.to home page. Keep in mind that some pages load dynamically with JavaScript, so without setting more options, the resulting PDF could appear incomplete.

Convert a Local HTML File to PDF

Puppeteer is not limited to loading web pages. You can also load local HTML files. This is how the Charter application creates a chord chart. The Charter app first parses a ChordPro text file, generates an HTML file, and then uses Puppeteer to render the HTML and save as a PDF.

Create a new file named sample.html and paste the following HTML.

<!DOCTYPE html>
<html>
<head>
  <style>
    * html,
    body {
      font-family: Verdana, Arial, Helvetica, sans-serif;
    }
  </style>
</head>
<body>
  <h1>Hello World!</h1>
  <p>Yay! My own PDF generator!</p>
</body>
</html>

Create a new file named local.js and paste the following code.

"use strict";

const path = require("path");
const puppeteer = require("puppeteer");

(async () => {
  const htmlFile = path.resolve("./sample.html");
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto("file://" + htmlFile);
  await page.pdf({ path: "./sample.pdf", format: "Letter" });
  await browser.close();
})();

Next, run the code from the command line.

node local.js

You should now have your very own "Hello World!" PDF in your project folder!

Create a Chord Chart with Charter

If you have Node.js 12.x or higher installed and want to take the CLI app for a spin, you can use npx to run the application directly. Of course, you will need a ChordPro text file to test. Here's an example, or you can find others on the Internet.

{title: Amazing Grace}
{artist: Words by: John Newton, John P. Rees}
{artist: Music by: William W. Walker, Edwin Othello Excell}
{key: G}  
{tempo: 90}
{time: 3/4 }

{comment: Verse 1}
A - [G]mazing [G/D]grace  [D7]how  [Em]sweet [C]the   [G]sound
That [G]saved a [G/D]wretch  [D/C]like    [G/B]me
I [G]once was [G/B]lost but [C]now am  [G]found
[G/B]Was   [Em]blind but [G/D]now    [D7]I    [G]see

npx will take a little while to download the first time, due to Puppeteer using Chromium.

npx chord-charter -f amazing-grace.chordpro

I hope you find the project useful! Get out there and be awesome!

My Most Embarrassing Mistakes as a Programmer

David Neal — Wed, 30 Oct 2019 20:07:45 +0000

My most embarrassing mistakes as a programmer, in no particular order:

I didn't ask for help
I was afraid of what others would think
I didn't follow through on a promise
I didn't step up and take responsibility
I avoided conflict
I didn't encourage others
I didn't publicly celebrate the success of others

My biggest mistakes had nothing to do with programming.

The most difficult parts of any job, and the most valuable activities of any job, have nothing at all to do with technology.

It's people. How we value ourselves. How we value others.

"Soft skills" is an awful term. The things we call "soft skills," such as listening, communication, team dynamics, empathy, ought to be given so much more priority in our workplaces. These are core skills that apply to anyone in any profession.

Here's the mindset I want.

To be the most effective member of any team, I must first strive to model integrity and work ethic. I need to be respectful, helpful, patient, gracious, trustworthy, and hardworking. I need to be transparent, such as asking for help, owning mistakes, and asking forgiveness, regardless of my fear of the outcome, because it's the right thing to do. When I see a failure in our system, not just in the work we create but also our system of work and treatment of people, I need to take responsibility, speak up, and see it through correction. I need to give people the benefit of the doubt, try to understand their perspective and circumstance, be slow to anger, and be quick to forgive. I need to encourage and lift others up and help them to see their career and life through a bigger lens.

I am a work in progress. I may not achieve these things every day, but that's my goal.

I hope this post gets you thinking of ways you can have a positive impact on the people you work with.

Remember, every day is a fresh start to be more awesome!

A Note of Encouragement

David Neal — Wed, 23 Oct 2019 18:57:02 +0000

Earlier this year, I set up a new computer for my son. In the process, I created an "Easter Egg" for him to find. I left a note on the desktop with some instructions on how to run a command-line interface (CLI) application I created.

> heybuddy

As I hoped, I'll sometimes walk by and see he has a terminal window open and has run the app several times 😊

The source code for this application is on GitHub. It's written in JavaScript and uses Node.js. There are instructions in the readme on how to customize the messages, change the name of the CLI app itself, and install it on someone's computer.

You can certainly take the idea and create your own customized encouragement CLI app, or take it further to create a web, desktop, or mobile application. Or, how about an encouragement robot!

Use the power of technology to make a positive impact on the people you care about! Let me know if there's anything I can do to help 🙂 Thanks for reading, and I hope you have an awesome day!

Respect: The Most Fundamental Principle

David Neal — Tue, 14 May 2019 13:16:08 +0000

Much has been said about "lean" and "agile" approaches to work. Reflecting over more than ten years of personal experience, I have come to this conclusion: Respect for people is the most fundamental principle. When respect is the lens and filter through which decisions are made, there is a much higher chance for success.

Having respect for people:

requires listening, empathy, and deeper understanding
prioritizes health, family, and well-being
promotes connections and relationships
fosters community, commitment, and loyalty
empowers employees to make positive changes

When respect is modeled top-down, leadership is motivated to maximize focus and alignment, minimize wasteful activities, and reduce friction. Leadership is obligated to make better decisions for the sustainability of the company because its people deserve stability, work-life balance, and personal/professional development.

Employees are motivated to do their best work. Mutual respect helps individuals come together as a team, investing in one another, and fighting for each other's success.

When conflicts arise, respect allows people to focus on solving the issue rather than attacking individuals.

People are people. They are not your best "assets." They are not fungible resources.

The "Golden Rule" is still the golden rule.

Makin' Bacon with Node.js, Hapi, and Vue

David Neal — Wed, 18 Jul 2018 16:46:50 +0000

I recently created a new demo for my Node.js Crash Course talk that I've given at several conferences. This application is a "bacon ipsum" generator using Node.js, Hapi, and Vue. I know I'm not the first to come up with the idea of a "bacon ipsum" generator, but I thought it'd be a fun project to create one in Node.js.

API Requirements:

Using a list of bacon names and other associated words...
Return a specified number of paragraphs, maximum of 25
Paragraphs should consist of between 3 to 6 sentences
Each sentence should be capitalized
A sentence should end with random punctuation, weighted towards more frequent use of periods
A sentence should consist of between 4 to 12 unique words

UI Requirements:

Customer can choose to generate 1 to 21 "pounds" of bacon
Customer can easily copy the generated text to their clipboard

See it in action!

When you click on the "Make the Bacon!" button, the Vue application uses Axios to call the API for bacon. When the API call returns, the Vue app updates its state with the array of paragraphs. This triggers re-rendering the UI to list the paragraphs and show the "Copy to the clipboard!" button.

makeTheBacon: function() {
  return axios
    .get( "/api/bacon/" + this.numberOfPounds )
    .then( res => ( this.paragraphs = res.data.paragraphs ) )
},

Vue computed properties

The Vue app uses a computed property, hazBacon, to show/hide the "Copy to the clipboard!" button based on there being any paragraphs of bacon text to display.

When copying text to the clipboard, the Vue app uses another computed property, paragraphText, to join the array of paragraphs together into a single string.

computed: {
  paragraphText: function() {
    return this.paragraphs.join( "\n\n" );
  },
  hazBacon: function() {
    return this.paragraphs.length > 0;
  },
  poundText: function() {
    return this.numberOfPounds == 1 ? "pound" : "pounds";
  }
},

Other dependencies

In addition to Node.js, Hapi, and Vue, here are the dependencies and plugins used by the project. Some of these are my current favorites for building Node.js applications.

Vue-Clipboard2 - Vue component used to copy text to the clipboard
Axios - HTTP client for browsers or Node.js
fs-extra - Promise-based file system module
Joi - Object schema validation plugin for Hapi
ESLint - JavaScript linting
Nodemon - Developer tool that automatically restarts the application when any change is made to source code
Boom - Hapi plugin for returning errors
hapi-pino - Pino logging plugin for Hapi
Inert - Static resource plugin for Hapi
Lab and Code - Test and assertion utilities for Hapi

github.com/reverentgeek/node-bacon-generator

Happy computering!

Choose Your Own Framework: The Curse of JavaScript Fatigue

David Neal — Wed, 13 Jun 2018 17:13:03 +0000

How will your project die? Choose from 2,147,483,647 possible endings!

The MONSTER at the end of this Book

David Neal — Fri, 25 May 2018 22:32:13 +0000

5 Essential Ingredients for an Awesome Tech Talk

David Neal — Mon, 01 Jan 2018 20:27:49 +0000

I believe one of the big reasons people are afraid of public speaking (or writing) is impostor syndrome. You may think…

I’m not an expert! I barely know anything! Everyone will know I’m a fraud!

Psst… here’s a secret: You don’t have to be an expert!

In fact, you have something no one else in the entire world has. Your experience.

Here’s a recipe for turning your experience into an awesome presentation!

1. Why did you choose this technology?

People can argue semantics, “best practices,” architecture, speed, or “Technology A” vs. “Technology B” all day long. But, no one can dispute your experience. Tell people your story. What was your motivation for choosing this technology, or for replacing “Technology A” with “Technology B?” What problems were you trying to solve? Chances are, your reasons “why” will resonate with other people in similar situations.

2. What does this technology do?

Do some research and put together a short list of highlights, features, and capabilities. This is your opportunity to geek out and dive a little deeper into this technology beyond your particular use case. Seek to find other scenarios where this technology is a good fit. This information can help bridge gaps for your audience.

3. How did you make it work?

Give your audience more of your story. They want to hear about the challenges and issues you faced along the way. Most of all, they want your insights! You learned the hard way what worked and what didn’t work, so share the good stuff! Including…

What mistakes did you make?

No way! I already feel like an impostor, and now you want me to remove any doubt?!

You might think admitting your mistakes will harm your reputation or credibility. Nope! Being transparent about your mistakes and what you learned from them adds to your credibility! I don’t know about you, but I make mistakes all the time. I want to hear from real humans doing real work -- people I can relate to.

If you were to do it all over, what would you do differently? Turn your challenges and mistakes into key takeaways for your audience!

Demo, if you must

A good demo can be the final puzzle piece needed to convince someone to try this technology. A working demo is great, but so are screen shots or a recorded video!

For the love of all that is holy, don’t do any live coding unless you are specifically demoing features of an IDE!

Your demo should only exist to reinforce your “why” for choosing this technology. Make it short and to the point, and show them something awesome! Don’t waste your audience’s time showing “how.” They can easily find that information for themselves on the Internet later. Your job is to convince them to go try it!

In my opinion, no demo is better than a bad one.

4. Where to get started?

You did the research. You made it work. Give your audience links to put them on the fast track! Better yet, give them one link where they can go to get your slides, your contact information, and a list of all the resources you recommend.

5. Drop the mic*

Wrap it up. Send them off with a call to action and high-fives!

Bake in the oven at 350 for 45 minutes

Imagine yourself in the future. You just finished giving a talk covering these five essential ingredients. Guess what?

BOOM.

You just gave an awesome talk. Your audience is now walking away with valuable information they could not have found anywhere else.

Now, go make it happen!

*Metaphorically speaking. Real microphones are fragile, and expensive. Just ask Kyle Welch.