Forem: Erik Hanchett

I Tried Vite+ and Replaced My Entire Frontend Toolchain

Erik Hanchett — Thu, 19 Mar 2026 17:02:19 +0000

If you're a frontend developer in 2026, you've probably had to deal with a lot of different tooling. Package managers, linters, formatters, pre-commit hooks, test runners. The list goes on. And every team has opinions on which ones to use.

I've worked on apps where hours if not days went into tweaking, upgrading, and swapping out tooling. And the bikeshedding when someone proposes something new in a meeting? Don't get me started. Earlier in my career I remember spending over an hour debating whether we should add Vitest or keep the old test runner. We ended up not changing anything.

That's why I really like Vite+. Vite+ is a unified toolchain that acts as an entrypoint for web development. It comes out of the team from VoidZero, the company founded by Evan You, the creator of Vite and Vue. You can think of it like a ShamWow for your toolchain. One tool that replaces your linter, formatter, test runner, bundler, and package manager all at once.

I also made a full video walkthrough where I set up a Vue project from scratch, run into the Nuxt issues in real time, and show the formatting and testing in action. If you'd rather watch than read, check it out below!

What's inside Vite+
A few caveats
Getting started
Creating your first app
Important commands
- Checking and linting
- Formatting
- Testing
- Caching with vp run
- Managing Node.js with vp env
Conclusion

What's inside Vite+

Instead of having to worry about building, installing, adding every tool you need when building an app, and dealing with configurations in 10 different files, you can now rely on one Vite powered toolchain. In essence, Vite+ combines all of these tools into one.

Vite as your build tool, now even faster with Vite 8
Vitest for testing
Oxlint for linting, replacing ESLint
Oxfmt for formatting, replacing Prettier and Biome
Rolldown for bundling, replacing ESBuild
tsdown for library bundling
Node.js runtime and package manager built in

Since many of these tools are written in Rust, the performance gains are real. According to VoidZero's announcement, Oxlint runs 50 to 100x faster than ESLint, Oxfmt formats up to 30x faster than Prettier, and production builds with Vite 8 and Rolldown are 1.6x to 7.7x faster than Vite 7. I had to test this out in my own projects, and using the vp check command was finishing in under a second on fairly large code bases.

A few caveats

While having everything in one tool helps, it does have some DX papercuts at this point. For example, while they do support most package managers (pnpm, npm, yarn), they are missing bun. There is also some more work to be done with the vite.config.ts on Nuxt and TanStack Start since the tooling for each aren't quite there yet. Nevertheless it's early days in Vite+, and it's still in alpha, so I'm sure the updates are happening soon.

I'd imagine if you are not sold on the Vite ecosystem, or using toolchains in general, this probably isn't the tool for you. I, like many other developers, have opinions, and often when I create apps I have very bespoke patterns I use. In my case, I use npm create vue@latest for every Vue app, and npm create nuxt@latest for Nuxt apps. The Vue scaffolder does let you opt into ESLint, Prettier, and Vitest during setup, which is nice. But each one gets its own config file, you still have to make sure they play well together, and things like pre-commit hooks are on you to wire up with husky or lint-staged. It adds up. I also have a very specific set of skills and markdown files I use with Kiro, to help me code.

With Vite+, all of that comes out of the box. One vp create vue and I have linting, formatting, testing, and pre-commit hooks ready to go in a single vite.config.ts. That's what sold me on it.

Let's take a look at how to set it up.

Getting started

As described in the Vite+ setup guide you can install it on your macOS/Linux with a simple curl command.

curl -fsSL https://vite.plus | bash

That should be it!

During the install you'll be asked a few questions around how Vite+ should manage your global Node.js runtime and package manager. You can opt-out of this, and use nvm or whatever else you'd like. However, I actually think this is really nice feature. With Vite+ you can use the vp env command to switch between environments really easily.

From here you can either start creating apps, or migrate existing Vite apps over. I've only really tested the creating apps options, so we'll look at that. I have seen a few people using the vp migrate command to do migration. It seems to work OK, but still requires manual intervention. One cool thing from the Vite+ announcement is that they provide a migration prompt you can paste directly into your AI coding agent. So if you're using Kiro or kiro-cli, you could have it handle the migration for you and just review the changes after. Here's the prompt:

Migration prompt: Migrate this project to Vite+. Run vp help to understand Vite+'s capabilities. Migrations can be run using vp migrate. Run vp help migrate for options. After the migration, verify the changes and make sure that type checking, linting, formatting, and tests pass. High-five your human when you are done.

Creating your first app

After installation you can then create a new app using the vp create command. This will then ask a few quick questions on what kind of application you'd like and it will then scaffold it all for you.

As of this blog post it defaults to a non JS Framework solution. While this is fine for a demo, I don't really get it, because I don't think many people today create websites without some sort of framework or library. Instead you can use this command.

vp create <template>

Right now it supports, vite, @tanstack/start, svelte, next-app, nuxt, react-router and vue. As I mentioned earlier with Nuxt they have not combined the nuxt.config.ts and the vite.config.ts together, so while you can use it, it's not quite ready yet. I also had issues with the next-app. I wasn't sure if it was trying to use a Vite-based Next app or the standard one. Either way it wasn't quite working.

After adding a template name it will then setup your app. It should look familiar if you're using something like npm create vite.

After install you'll then have a unified vite.config.ts file that you can then enter all your configurations for linting, formatting and testing. This worked surprisingly well and I was happy not having to worry about where to add each file.

Since Vite+ uses the Oxc set of tools, I added in the official Oxc extension for formatting and linting. This made it even easier so that my IDE was aware of these tools.

Important commands

Beyond vp create you have a number of interesting commands you can run with vp. Here are a few I've found useful. Although, if you'd like a full list please check out the official guide.

Checking and linting

vp check

The vp check is the default command for fast static checks in Vite+. It combines both the formatting with Oxfmt and the linting with Oxlint, and the TypeScript type checks via tsgolint. Combined this is an extremely fast static checker.

Under the hood, tsgolint is powered by tsgo, the official Go port of the TypeScript compiler from Microsoft. This means your type checking is running at native speed, not through Node.js. It's a big reason why vp check feels so fast.

If you like you can have it try to fix the issues.

vp check --fix

In my tests, this still takes a lot of manual intervention as expected. What's nice is that a competent AI coding tool, like Kiro, can knock these type errors out in no time.

Vite+ also has built in pre-commit hook support. When you scaffold a project with vp create, it can set up hooks for you automatically. You can also run vp prepare to install them later, and configure what runs on staged files right in your vite.config.ts. No more husky or lint-staged setup.

Formatting

vp fmt

This will run the Oxfmt formatter. It has full Prettier compatibility and is designed as a drop-in replacement for Prettier.

Personally, I love prettier, but it does have its quirks. What's really nice is you can just go into the vite.config.ts file and add any rules you need.

import { defineConfig } from 'vite-plus';

export default defineConfig({
  fmt: {
    singleQuote: true,
  },
});

When I first setup my app using vp create vue it asked me if I'd like to update the .vscode/settings.json. I'd highly recommend this so if you're using the Oxfmt extension it can find your formatting settings. Otherwise you can manually add it.

{
  "oxc.fmt.configPath": "./vite.config.ts"
}

Testing

I love testing, so running tests with Vitest is great.

vp test

This will kickoff the vitest test runner in your project. There is also a watch and a run --coverage command. And like all the other commands you can edit the configuration in the vite.config.ts file.

import { defineConfig } from 'vite-plus';

export default defineConfig({
  test: {
    include: ['src/**/*.test.ts'],
  },
});

One quick annoyance with running the vp commands is that they do override your package.json scripts. So to run anything in your scripts you must run vp run <command>. Otherwise it will run the built in commands. I was watching a live stream with Theo Browne from T3 and he hated this. I'm on the fence, but maybe they'll change it in the future.

Caching with vp run

Another nice feature is caching.

vp run --cache build

This will cache the build and if nothing changes the output is replayed on the next run. I have not used this command personally but anything to speed up builds I'm all for.

Managing Node.js with vp env

Another really neat feature is the vp env command.

vp env <command>

vp env manages Node.js versions globally and per project. By default, Vite+ runs in managed mode, meaning it controls which Node.js version is used. It stores the runtime and related files in ~/.vite-plus (you can override this with VITE_PLUS_HOME).

If you don't want Vite+ managing your Node.js, you can switch to system-first mode:

vp env off

This tells the shims to prefer your system Node.js and only fall back to the Vite+ managed runtime when needed. If you ever want to switch back, just run:

vp env on

You can also pin a certain Node.js version in the current directory with:

vp env pin

Or install an entirely new version.

vp env install

I really liked all this flexibility with the package manager. I personally use nvm but I like the idea of this being handled by Vite+. One less thing to worry about.

While I haven't tried it, I'm curious to see how well this works in a CI environment. It looks like you can easily set this up in your GitHub actions and run all the checks you need.

- uses: voidzero-dev/setup-vp@v1
  with:
    node-version: '22'
    cache: true
- run: vp install
- run: vp check
- run: vp test
- run: vp build

Conclusion

I could definitely see Vite+ saving me time when I create a new application. Having one configuration file to put everything in, and not having to think about which linter, formatter, or test runner to install, is a nice change. The vp commands are straightforward and the whole thing just works.

With that said, this project is still in alpha, and we'll see how much it catches on. With so much of the frontend ecosystem already using Vite, it makes sense for a tool like Vite+ to exist. Let me know if you would use something like this. I think it's very interesting. Thanks!

5 Things To Avoid When Working With AI Coding Tools

Erik Hanchett — Thu, 12 Mar 2026 21:10:42 +0000

As a software developer in 2026 you can't escape AI. It's everywhere, and almost every company is using some sort of AI coding tool. And as a long time full-stack developer whose roots are in the front-end, I wasn't always convinced.

Over the past two years I've seen both sides of AI. The terrible designs, but also the surprisingly decent ones. Demo apps that used to take me hours, done in minutes. But I've also found myself knee-deep in AI slop, wondering if I actually saved any time at all.

So are these coding tools making me faster or not? I had to look into it more.

Want to watch a video on the subject then read about it? Check this out!

Last year, Model Evaluation and Threat Research, or METR, ran a randomized controlled trial and found that when experienced open source developers used AI tools, it took them 19% longer to complete tasks than without. AI was actually a detriment to their productivity.

On the other hand, GitHub conducted their own controlled trial around the same time and found that developers coded up to 55% faster with AI assistance.

So which is it?

After trying these tools out myself for the last two years, I can confidently say I think both are true. And the difference comes down to the approach used. AI tools, just like any other tool, can be misused. If the only tool you have is a hammer, every problem starts to look like a nail. When I first started using AI, I used it for everything. New features, bug fixes, refactors, brainstorming, all of it. And at first it felt amazing. But I kept running into the same problems over and over. The output looked good on the surface, but I'd spend more time fixing what it gave me than if I'd just written it myself.

Here are 5 ways AI can hurt you instead of help you, especially on the frontend.

No Real Feature Definition

I like jumping into a coding agent right away. I start vibe coding as soon as my fingers reach the keyboard, but this actually isn't a great way to start. The AI will absolutely give me what I ask for, and it might even work, but the problem lies in the details.

The design generated is often not great (I'm looking at you GPT) and the features don't always work. Validation, error handling, responsiveness, and accessibility will often be partially implemented or skipped entirely. That's when things fall apart.

The real issue is that you need to define what success looks like. If you don't, the AI just guesses, and though it gets some of it right, it gets a lot wrong. Ambiguity isn't your friend.

The real issue is that you need to define what success looks like.

Don't get me wrong, you don't need a 15 page requirements document with detailed designs for every use case. However, maybe a few bullet points and some basic acceptance criteria will help. Simply defining what the feature should do and not do is the minimum you should ask. Adding this all to a markdown file before you get started will dramatically improve what the AI generates for you.

Too Much Bad Context

So that means I should put everything into the context window? Use as many AGENTS.md and markdown files as I can before I start, right? Well, yes we need more context but there is more to it than that.

The second problem is putting too much into your context window. Whenever you work with a coding tool, I prefer Kiro so I'll use that as an example, it has a defined amount of space it can handle. This is often influenced by the model you select. Some models have larger context windows, others have smaller.

Either way, stuffing everything you can find into lots of markdown files causes the opposite problem from #1. Now the model has to comb through lots of useless information to find what it needs. We've recently seen research that shows that more is not always better.

Recent research across over 60,000 repos found that context files are often too long, too vague, and are actively making agents worse. In one study, accuracy dropped from 87% to 54% just from context overload.

Context overload doesn't just drop accuracy, it can also increase token cost. When every request sends more information than is needed, you uselessly waste tokens, which in turn hits your pocketbook.

At the end of the day, it's more about quality than quantity when you're dealing with context windows. Think about it like giving directions. If someone asks you how to get to the grocery store and you hand them a 200-page atlas, that's technically more information. But it's not more helpful.

When creating an AGENTS.md file (or steering file if you're using Kiro), only include information that is needed for your project. Constrain it to your coding practices, tabs vs spaces, design system, API contracts and rendering. Make sure to remove unneeded fluff, and keep it up to date. When I use Kiro, I create an agent that automatically updates my markdown files when I make changes to my components. That way I always have the latest updates in my context files.

There's probably a Goldilocks zone of context. Not too little, not too much. Just the stuff that actually matters for the task.

Too Much in One Shot

While having too much or too little in your context is important, you still need to know the limitations of what you're asking your coding agent to do. One common problem I see is that developers will try to one-shot a whole application. I'll see prompts to build a frontend, backend, tests, create all the things at once. It feels like you're making a lot of progress, and it outputs something in just a few minutes.

This could actually work for a quick prototype or demo. However, in production this is not what you want. You'll end up with a lot of AI slop that often takes a lot of rework.

I was reading the other day that a whole industry has popped up to help small teams fix their vibe-coded messes. This should really tell you something about the state of the industry.

The reality is that creating everything at once causes the AI to lose architectural consistency. It may solve the same problem different ways in different files. It creates patterns that are contradictory or nonsensical.

To fix this issue, you need to scope down the tasks. Unless you're running some autonomous agent loop that's going to churn through a large detailed requirements document and tasks for hours, you'll need to break things down. Build this component, refactor these tests. Here are the edge cases for this part of the app. The key, as we'll discuss in the next section, is to check the output. It's a lot easier to catch a problem in 50 lines than 2,000.

This problem has actually been mitigated in a lot of ways with spec-driven development. I use Kiro all the time to break down complex features into requirements, design and tasks. That way you can check the plan before the AI writes any code at all.

Too Much Trust

As hinted in the last paragraph, we should not be trusting the output of AI at face value. And of course, it does look convincing at first. When I started using Claude 4.5 Opus, I really thought coding was a solved problem. The code passed my linter, the types looked ok, and it ran well.

But as I started looking at the code in more detail, I saw some issues and edge cases I didn't like. Maybe one day AI will write 100% accurate code, but we still aren't there yet.

There is no question AI makes writing code faster, but you need to spend more time checking the output. In other words, AI compresses generation time, but it often expands verification time.

AI compresses generation time, but it often expands verification time.

I'll be the first to admit, I love writing code, debugging it, finding clever ways to abstract the logic, and seeing it run for the first time. I'm not as big of a fan of code reviews. Something about reviewing other people's code and giving feedback isn't as fun.

However, when AI is doing the writing, reviewing becomes the most important part of your job. For example, on the frontend I've seen things like weak accessibility, brittle logic, weird abstractions, duplicated behavior, and terrible design. Let me emphasize again that AI is not great at design. It's passable if you love purple and you don't mind generic Tailwind-looking apps. You really need to iterate over it several times to get a good outcome.

AI is not great at design!

To help mitigate these problems you can set up tests, and those help, but sometimes the AI games those too. Really though, there is no better way than having a real life breathing human verify everything along the way. You should read the code, understand it, gauge the design, and test the assumptions.

Speed Over Maintainability

As a developer, I love writing code fast. I remember being a young software developer and learning as many hotkeys and keystrokes as I could. I learned Vim so I would never have to touch the mouse, because I knew that every second I touched it, it would slow me down.

With AI writing your code, speed stops being the hard part. I'll never type faster than a large language model can generate. But that's the trap, just because it's fast doesn't mean it's good.
When code gets cheap to generate, bad abstractions get cheaper too.

When code gets cheap to generate, bad abstractions get cheaper too.

AI will over-generate wrappers, components, abstractions and APIs. These AI tools are like eager interns, they want to show off what they can do. But if you don't monitor them closely they'll go off the rails.

And my cognitive load can only handle so much. I remember one of the first codebases I worked on had so many levels of abstraction, it took me 15 minutes of ctrl-clicking into every class and interface to figure out what it was exactly doing. (Yes this was in Java). If you let AI go off, it will do the same thing.

You end up owning code you didn't fully think through or really understand. Your job is to understand what the AI is creating, because six months from now, someone has to maintain it. And that someone is probably you.

Modern Tooling

So where are we at today? Well, we know that models are getting better all the time, and maybe in a few years most of these problems will be solved.

But we are not there yet.

Tools like Kiro have spec-driven development, and other tools have plan mode, checkpoints, and better workflows. But these tools are only as good as the person driving them and there still is no silver bullet. You still need your judgement, your context, and your code review skills to be successful.

Conclusion

If we go back to our two studies at the start, both things can be true at once. Some developers will see productivity gains with AI tools, many others won't. It really comes down to how you use them in your day-to-day life.

You can't vibe code every app, and every app shouldn't be vibe coded. You need the right amount of context, not too little, not too much. You need to scope your asks. You need to become a better code reviewer. And you need to think about whether what the AI created is something you can actually maintain six months from now.

Let me know in the comments if you agree or disagree. Until next time.

The hosting setup nobody talks about anymore

Erik Hanchett — Fri, 20 Feb 2026 00:15:40 +0000

Ever had this problem?

You're building something real, real-time features, background workers, cron jobs, maybe a database or two. You've outgrown the managed platforms, or you're tired of stitching together five different SaaS subscriptions to get what a single server could give you. You want to understand your infrastructure, not just deploy to it. Let me introduce you to the world of Virtual Private Servers (VPS).

A VPS gives you full control over a private server that you yourself manage. Root access, any library or service you want, no execution limits or timeouts. If something breaks, you can SSH in and fix it, no support tickets, no waiting.

That flexibility comes with a tradeoff: you're responsible for the setup, the security, and the maintenance. Managed platforms abstract that away, which is exactly why they're great for simpler use cases. However when your app needs more than what a platform gives you out of the box, or when you just want to learn how the pieces fit together, running your own server is worth the investment.

The purpose of this tutorial is to walk you through that setup end to end. We'll launch a VPS, configure a web server with a CDN, connect it to a domain, and wire up a deployment pipeline. By the end you'll understand every layer of your stack. Let's jump in!

Heads up — this tutorial gets you to a working deployment. If you plan to serve real user traffic, check the Production Hardening section before going live.

Our Setup
Step-by-step
- Launching your EC2 instance
- Installing nginx and Docker
- Configuring AWS Systems Manager
- Setting up the deploy directory and ECR
- Connecting GitHub with OIDC
- Adding the GitHub Action and Dockerfile
- Testing the deployment
- Setting up CloudFront, SSL, and nginx
- Connecting your domain with Route 53
- Adding cache behaviors
Production hardening
Cleanup
Wrapping up

Want a video instead?

Our Setup

Full disclosure, I'm a Developer Advocate for AWS, so I'll be using AWS services in the tutorial as it's what I'm most familiar with. I've been hosting web apps on VPS for years. Feel free to use whatever VPS provider you'd like though.

In this post we are using an Amazon EC2 T3 Micro instance running Ubuntu with an nginx web server. We'll use AWS Systems Manager to help set up a CI/CD pipeline using GitHub Actions. We'll then configure AWS Certificate Manager with Amazon CloudFront and have it connected to our domain with Amazon Route 53! We'll be using a Vue Nuxt 4 application as our web app.

Here is a high level diagram of our final output.

Prerequisites

Don't worry, you won't need to be an EC2 or AWS expert to follow this post. I'll assume you have some basic knowledge of software development, but that's it. To get started make sure you sign up for a free AWS account. I'll also assume you have some sort of application you want to deploy and it's already on GitHub. In this example we'll be using Nuxt with SSR, but you can use whatever you'd like.

Step-by-step

Typically in enterprise applications you might see infrastructure as code (IAC) building and deploying applications on AWS. However, for this tutorial we'll be going directly to the AWS console. I find this the simplest way to get started.

If you're following along with this tutorial, or skimming it through to get ideas, make sure to download a good agentic IDE like Kiro CLI. Kiro CLI can be installed remotely on your server and help you troubleshoot any production issue you have while setting up your service. I used it extensively while researching this blog post, and you should too!

Launching your EC2 instance

To host our application we'll start by creating a new EC2 instance. Log into the AWS Console to begin. Make sure you're on N. Virginia us-east-1 in the top right-hand corner.

Search for EC2 in your AWS Console. It will bring you to a page where you can click Launch instance.

You'll then be brought to a screen with a lot of options. Don't worry, just fill out the name of your server. In this case I chose My-Web-Server and pick an OS image. I really like Ubuntu for beginners so I chose that.

Next you'll need to select an instance type. We want to keep this server cheap (and free-tier eligible), so let's go with the t3.micro instance that has 2 vCPUs and 1 GiB of memory.

What about traffic?
I know what you're thinking, how much traffic can a t3.micro instance handle? While I can't say for sure, we'll be using a Content Delivery Network (CDN) via Amazon CloudFront and caching as much as possible to help absorb traffic spikes. And if you ever outgrow a single instance, AWS can handle it. An Auto Scaling Group (ASG) can spin up additional EC2 instances once a certain traffic threshold is met, an Application Load Balancer (ALB) can distribute incoming traffic across them, and a Web Application Firewall (WAF) can block malicious or "noisy" traffic. We won't be covering those in this post, but I'd recommend reading up on it here if you're interested.

Click the Create new key pair button. This will send you to a popup to add a new key. Add a new key pair name, leave the rest as default and click Create key pair.

It will then ask you to save the key. This is very important. You'll need this key to SSH into your instance later. Save it somewhere safe.

In the network settings you may see a banner that you don't have a default VPC. Click create a new VPC. On the next page leave everything as default and click Create default VPC.

You should now be able to select your VPC, if it's not already selected.

In the Firewall (security groups) make sure to change the Allow SSH traffic from to only allow traffic from your IP. It should be listed in the dropdown.

At the bottom click on Launch instance and you'll see a nice green Success banner. You can click on your instance i-*** to look at it!

In the next window look for the public IP address. Save it!

Now jump into your favorite terminal. Make sure you're in the same directory as the *.pem file you created earlier. You'll need to set some permissions on it. You'll then be able to SSH into your server. Make sure to replace ip-address with the public IP address you saved from the EC2 instance.

chmod 400 your-pem-file.pem
ssh -i your-pem-file.pem ubuntu@ip-address

🎉 Congrats! You've logged in for the first time!

Installing nginx and Docker

Now that we have our EC2 instance up and running, let's do something with it!

First update and then upgrade Ubuntu to the latest. It may ask you to restart some services. You may consider some best practices when working with EC2 as well.

Let's install nginx. This will be our web server that we'll use as a reverse proxy. It listens on port 80 for incoming traffic and forwards it to our Nuxt app running on port 3000.

sudo apt update && sudo apt upgrade
sudo apt install -y nginx

After nginx is installed we'll need to do some configuration. Let's add a new site under the sites-available directory. We'll call it nuxt.

sudo nano /etc/nginx/sites-available/nuxt

Replace it with the code below.

server {
  listen 80;
  server_name _;

  # (we’ll enable this after CloudFront is created)
  # if ($http_x_origin_verify != "REPLACE_WITH_SECRET") { return 403; }

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

This is a basic setup for nginx. Check out the beginners guide for more information on what each option does. The Upgrade and Connection headers are there so WebSocket connections work correctly — handy if your app uses real-time features.

You may have noticed a comment at the top! Don't worry, we'll come back to this later when we set up CloudFront.

To enable the site we have to create a symbolic link from sites-available to sites-enabled. We'll also do a little cleanup and remove the default nginx site and restart it.

sudo ln -sf /etc/nginx/sites-available/nuxt /etc/nginx/sites-enabled/nuxt
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

If all goes well we'll get a successful message! If not, double-check the nuxt configuration inside nginx. It's easy to copy something wrong.

At this point we have a few options to handle our Nuxt site. We could just copy the dist folder over, install node, and use something like pm2 to manage the node process. While this works, I find it a little brittle.

Running everything on our EC2 instance requires managing dependencies directly on the system, making it harder to ensure consistent environments between development and production. Docker containers provide a better option. They isolate our dependencies, we can roll back easier, and we'll have more predictable deployments since everything your app needs is packaged together.

To install Docker we'll follow the official Docker docs that recommend using the apt repository.

# Add Docker's official GPG key:
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

The above code allows us to install Docker under apt. Let's do so.

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Let's verify it's working. Always use sudo to run docker commands.

sudo systemctl status docker
sudo docker run hello-world

Configuring AWS Systems Manager

AWS Systems Manager (SSM) agent should already be installed on the instance; however, in case it isn't, you can use snap to install it. We'll then run a systemctl command to start the service.

SSM is a comprehensive management service that provides a unified user interface for tracking and resolving operational issues across AWS and hybrid cloud environments.

sudo snap install amazon-ssm-agent --classic
sudo systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service

We can verify it's running by checking the status.

sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service

Back inside the console open up the EC2 instance. Use the Actions menu to modify the attached IAM role.

Make sure to attach the AmazonSSMManagedInstanceCore and AmazonEC2ContainerRegistryReadOnly policies. The AmazonSSMManagedInstanceCore policy allows the EC2 instance to be managed by AWS Systems Manager, enabling remote access and command execution without SSH. The AmazonEC2ContainerRegistryReadOnly policy grants the instance permission to pull Docker images from Amazon Elastic Container Registry (ECR) repositories.

Add the new role and click the Update IAM role button to complete the process.

If you like, you can check Systems Manager in the console to see the EC2 instance connected. Search for Systems Manager -> Fleet Manager and you'll see the instance connected.

Setting up the deploy directory and ECR

For our app deployment, we'll be hosting our images on ECR. We'll need a script that will be triggered by SSM to pull the latest tag and run it.

To do this we'll create a new directory.

sudo mkdir -p /opt/nuxt-app
sudo chown ubuntu:ubuntu /opt/nuxt-app
cd /opt/nuxt-app

Let's create the docker-compose.yml file inside the /opt/nuxt-app folder. Don't worry about the image, we'll replace that later. Also go ahead and create an empty .env file now — Docker Compose will fail if the env_file path doesn't exist.

touch /opt/nuxt-app/.env

services:
  nuxt:
    image: REPLACE_LATER
    ports:
      - "127.0.0.1:3000:3000"
    env_file:
      - /opt/nuxt-app/.env
    restart: unless-stopped

We'll need to install the AWS CLI so we can pull down the deployed image from ECR. Install the latest version from the docs.

sudo apt install unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

As always, make sure it works by running the commands below.

aws --version
aws sts get-caller-identity

This will verify that AWS CLI is working and that the permissions we set earlier in the IAM policy are there.

Let's now configure ECR!

Inside the AWS console head to ECR → Repositories → Create repository.

Add a name and create it. In this case I'll use the postfix ec2/host!

Make sure to write down the full ECR repository name for later.

Connecting GitHub with OIDC

Now let's set up an OIDC provider for GitHub. Later we'll create a GitHub Action that will need access to our AWS account to work. To get more information on how OIDC providers work in GitHub, feel free to check out this guide.

Inside the AWS console head to IAM → Identity Providers → Add provider.

On this page make sure to select OpenID Connect, use the URL https://token.actions.githubusercontent.com and the audience as sts.amazonaws.com. It should look like the screenshot below!

Now let's create a new role for this.

Inside the AWS console head to IAM → Roles → Create role.

Create a new IAM role connecting to this provider. Choose Web identity and make sure to use the new identity provider you just created. Type in the GitHub organization and repository. If you like, you can also select the branch.

Click next a few times and create the role! We aren't done yet though — we need to make sure this role has permissions to ECR so the GitHub Action can trigger our deployment workflow.

Under permissions click the Create inline policy.

Select JSON and copy and paste this in.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ECRAuth",
      "Effect": "Allow",
      "Action": "ecr:GetAuthorizationToken",
      "Resource": "*"
    },
    {
      "Sid": "ECRPush",
      "Effect": "Allow",
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:CompleteLayerUpload",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart",
        "ecr:BatchGetImage"
      ],
      "Resource": "arn:aws:ecr:YOUR-REGION:YOUR-ACCOUNT-ID:repository/YOUR-REPO-NAME"
    },
    {
      "Sid": "SSMRunCommand",
      "Effect": "Allow",
      "Action": "ssm:SendCommand",
      "Resource": [
        "arn:aws:ssm:*:*:document/AWS-RunShellScript",
        "arn:aws:ec2:YOUR-REGION:YOUR-ACCOUNT-ID:instance/i-xxxxxxxxxxxxxxxxx"
      ]
    }
  ]
}

Make sure to update the instance with your instance ID. You can find that in your EC2 console. It starts with i-. You also need to update YOUR-REGION (e.g. us-east-1) and YOUR-ACCOUNT-ID with your account ID. Also update YOUR-REPO-NAME with your ECR repo name. In my case I called it ec2/host.

⚠️ Setting up for production
We're using AWS-RunShellScript here which lets the CI pipeline run any shell command on your instance. That's great for a tutorial, however a compromised GitHub Actions workflow or malicious PR could achieve remote code execution on your host. In production, create a custom SSM document that only runs your deploy script. That way even if the GitHub role is compromised, it can only trigger the specific deployment, not arbitrary commands on your box. A minimal custom document looks like this:
{
  "schemaVersion": "2.2",
  "description": "Deploy Nuxt app",
  "mainSteps": [{
    "action": "aws:runShellScript",
    "name": "deploy",
    "inputs": {
      "runCommand": ["sudo bash /opt/nuxt-app/deploy.sh"]
    }
  }]
}
Then reference your custom document name in the GitHub Action instead of AWS-RunShellScript.

Click create, name it github-deploy-nuxt, and you are good to go.

Make sure to copy the ARN for later!

Now inside our GitHub repo let's add the GitHub variables.

Open up your GitHub repo and head to Settings → Secrets and Variables → Actions → Variables.

Add five new environment variables. These will be used in our GitHub Action.

Add each variable one by one.

AWS_REGION  us-west-2
AWS_ACCOUNT_ID  your account id
ECR_REPO    ec2/host
INSTANCE_ID i-xxxxxx
AWS_DEPLOY_ROLE_ARN role ARN from above

Adding the GitHub Action and Dockerfile

For the deployment to work successfully we need to set up a GitHub Action that will deploy our app. Let's do that now.

In your repo add a new .github/workflows/deploy.yml file. This will be run whenever a push occurs to main.

name: Deploy Nuxt SSR

on:
  push:
    branches: ["main"]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_DEPLOY_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push Docker image
        run: |
          IMAGE_URI=${{ vars.AWS_ACCOUNT_ID }}.dkr.ecr.${{ vars.AWS_REGION }}.amazonaws.com/${{ vars.ECR_REPO }}

          docker build -t $IMAGE_URI:prod .
          docker push $IMAGE_URI:prod

      - name: Deploy via SSM
        run: |
          COMMAND_ID=$(aws ssm send-command \
            --instance-ids "${{ vars.INSTANCE_ID }}" \
            --document-name "AWS-RunShellScript" \
            --parameters '{"commands":["sudo bash /opt/nuxt-app/deploy.sh"]}' \
            --query "Command.CommandId" --output text)

          aws ssm wait command-executed \
            --command-id "$COMMAND_ID" \
            --instance-id "${{ vars.INSTANCE_ID }}"

This action will assume our AWS credentials based on the GitHub role we just created. It will then build a Docker image and push it to ECR. We'll then trigger SSM to run our script that will complete the deployment.

For us to build our Docker image, we'll need a Dockerfile in the root of our repo. Head to the repo and in the root add a new Dockerfile. This will build our Nuxt application.

# --- build stage ---
FROM node:20-bookworm-slim AS build
WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

# --- runtime stage ---
FROM node:20-bookworm-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production

COPY --from=build /app/.output ./.output

EXPOSE 3000
CMD ["node", ".output/server/index.mjs"]

We'll also need a .dockerignore file.

node_modules
.nuxt
.output
.git
.gitignore
.env
.env.*
*.pem
*.md
.vscode
.idea

Before we get too far, let's test it out.

Testing the deployment

We are going to test our deployment, but first let's temporarily open up port 3000 on our EC2 host. We can then connect to the IP address later to see if our deployment works.

Inside the AWS console head to EC2 → Security Groups → Inbound rules.

Click on the security group.

Edit inbound rules and add your IP address on port 3000 on Custom.

Let's head back to the Docker Compose file again. This is important — before you push anything to GitHub, update the docker-compose.yml with your real ECR image URI. If you skip this step the deploy will fail because Docker won't know what image to pull. Add in the ECR image name and set the port to 3000. Make sure to add the :prod tag.

services:
  nuxt:
    image: <account-id>.dkr.ecr.us-east-1.amazonaws.com/ec2/host:prod
    ports:
      - "3000:3000"
    env_file:
      - /opt/nuxt-app/.env
    restart: unless-stopped

For my app I use several secrets; however, as you can see from earlier, our Docker ignore file excludes .env files (for good reason). Create a new .env file with the secrets. This will be injected into our docker image later.

sudo nano /opt/nuxt-app/.env

Next is the deploy script!

nano /opt/nuxt-app/deploy.sh

The GitHub action will run this on every deploy to main.

#!/bin/bash

cd /opt/nuxt-app

aws ecr get-login-password \
--region YOUR_REGION | \
docker login \
--username AWS \
--password-stdin YOUR_ACCOUNT_ID.dkr.ecr.YOUR_REGION.amazonaws.com

docker compose pull
docker compose up -d
docker image prune -f

⚠️ Don't use .env files in production
Plaintext .env files on disk have no rotation, no audit trail, and no access control. For production, use AWS Secrets Manager or Systems Manager Parameter Store (SecureString) to manage application secrets and pull them at runtime. The .env approach shown here is suitable for development and tutorials only. You could also set up a blue/green deployment — spin up the new container, health-check it, then swap traffic only if healthy. For the purpose of this tutorial though, we'll keep it simpler.

Replace the YOUR_ACCOUNT_ID with your account id and YOUR_REGION with your region.

Then make it executable.

chmod +x deploy.sh

We are finally ready to try it all out! Push all your changes from your repo to GitHub and check the Actions tab at the top and see it deploying!

Troubleshooting
If you see errors at this point, you'll need to double-check your GitHub role and that everything is connected. This might be a good time to use Kiro to help troubleshoot the problem!

We can check if everything works by loading up port 3000 with the public IP address of the EC2 instance.

Go to http://<your-ec2-ip-address>:3000

Congrats 🥳! You now have a working deployment pipeline and your container is working!

Setting up CloudFront, SSL, and nginx

Our pipeline is working; however, we need to revert the ports change we made in the docker-compose.yml file.

Change back the /opt/nuxt-app/docker-compose.yml to

services:
  nuxt:
    image: xxxx.dkr.ecr.us-east-1.amazonaws.com/ec2/host:prod
    ports:
      - "127.0.0.1:3000:3000"
    env_file:
      - /opt/nuxt-app/.env
    restart: unless-stopped

Then apply it

cd /opt/nuxt-app
sudo docker compose up -d

⚠️ Remove port 3000 from your security group now. It exposes your raw application server to the internet, bypassing nginx. This was only needed for testing — don't leave it open.

Let's see if it works on the normal port 80.

Open up http://<your-ec2-ip-address>

If all goes well you should be seeing your website! 🎉

But now we need CloudFront to add a Content Delivery Network (CDN) that will cache our static assets globally and improve performance for users worldwide. CloudFront also provides additional security features and helps protect our origin server from direct access.

Let's assume you already have a domain in Route53.

Let's request a public certificate so we can add in SSL.

In the AWS Console head to Certificate Manager → switch region to us-east-1 → Request certificate → Request a public certificate .

Then add your fully qualified domain (e.g. yourdomain.com). And add another for www (e.g. www.yourdomain.com).

Leave everything else defaulted and click Request. Wait a few minutes for the certificate to be issued.

Inside the AWS Console head to CloudFront and create a new distribution.

Click Create Distribution. Choose the free plan. Make sure to enter the distribution name, the domain name, and the Domain to serve (www).

On the next page choose Other. For origin, type in the public DNS of the EC2 instance. You may need to go back to grab it.

Set the origin settings to customize origin settings. Then set an X-Origin-Verify header with a random secret you create.

Why this header matters
The CloudFront Origin Header is extremely important. This ensures that your origin server can only be accessed through CloudFront and not directly from the internet, providing an additional layer of security.

⚠️ Use HTTPS to your origin in production
We're using HTTP for the origin protocol here since CloudFront handles HTTPS for your users. However, the X-Origin-Verify shared secret is transmitted in plaintext over this connection. Even with the security group locked to the CloudFront prefix list, traffic between CloudFront edge nodes and your EC2 instance traverses the public internet and could be intercepted. For production workloads, install a certificate on your instance (a self-signed cert works fine since CloudFront doesn't validate origin certs by default, or use Certbot for a free Let's Encrypt certificate), switch nginx to listen on 443, update CloudFront's origin protocol to HTTPS-only, and move your prefix list security group rule from port 80 to 443. This encrypts the entire path and keeps the shared header as a defense-in-depth measure rather than your primary access control.

For cache settings, choose "CachingDisabled" as we'll configure specific caching behaviors for different content types after creating the distribution.

For the Web Application Firewall (WAF) settings, don't make any additional changes.

On the settings page, select the SSL certificate you created earlier from the dropdown menu. Make sure both your domain and www subdomain are covered.

Review all your configuration settings and click "Create distribution". CloudFront will take several minutes to deploy globally — you'll see the status change from "Deploying" to "Enabled" when it's ready.

After it's enabled, add a new behavior. Click Create behavior. Fill out the Path pattern as /_nuxt/*, set the Origin and origin groups dropdown to the EC2 instance. Make sure to set the Viewer protocol policy to Redirect HTTP to HTTPS and set the Allowed HTTP methods to GET, HEAD.

It should look like this at the end

Now that CloudFront is in place, let's update the nginx configuration with the new secret key we created earlier.

sudo nano /etc/nginx/sites-available/nuxt

server {
  listen 80;
  server_name _;

   if ($http_x_origin_verify != "REPLACE_WITH_SECRET") { return 403; }

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Replace the REPLACE_WITH_SECRET with the variable you set up in CloudFront.

Then reload nginx.

sudo systemctl reload nginx

Now if you test the origin you should get a 403 forbidden.

Go to http://<your-ec2-ip-address>

Lock down port 80
For an extra layer of security, go to your EC2 security group and delete the existing port 80 inbound rule, then add a new one with the source set to the AWS-managed prefix list com.amazonaws.global.cloudfront.origin-facing. This restricts port 80 so only CloudFront's network can reach your instance. Combined with the origin verify header, you now have two layers of protection on your origin.

🔥 We are getting one step closer!

Connecting your domain with Route 53

Now you need to connect your CloudFront distribution to your domain through Route53.

Go to Route53 in the AWS console and navigate to your hosted zone for your domain. Click "Create record" to add a new A record that will point your domain to the CloudFront distribution.

Make sure you add a record. Choose Alias and then choose Alias to CloudFront distribution from the dropdown. Select your CloudFront distribution from the list. Leave the Record name blank for the root domain.

Add another A record, but this time for the www subdomain.

It might take a few minutes for DNS propagation to complete, but your site should be accessible at your domain shortly after creating the A records.

You can test the CloudFront distribution directly using its domain name while waiting for DNS to propagate. Once everything is working, visit your domain and you should see your site served securely over HTTPS!

Go to https://<your-domain> 🎇

You can even open Chrome DevTools and check the Network tab to see CloudFront cache hits in the response headers.

Adding cache behaviors

If you'd like, we can add additional caching to our CloudFront distribution.

/favicon.ico
/robots.txt
/sitemap.xml
/images/*

Each of these files can have their own caching rules. Static assets can be cached for longer periods, while you might want to disable caching entirely for server-side rendered (SSR) routes in Nuxt to ensure dynamic content is always fresh.

To add these behaviors, go back to your CloudFront distribution and create new behaviors for each path pattern, adjusting the cache settings based on how frequently the content changes.

Once everything is working properly, it's also a good security practice to remove SSH access from your EC2 instance's security group. Since we set up AWS Systems Manager earlier, you can still connect to your instance anytime through the SSM Session Manager in the AWS console — no SSH key needed, no port 22 open to the internet. Just head to your EC2 security group, delete the inbound rule for port 22, and save.

Production hardening

What we've built so far is a solid working deployment — but it's tutorial-grade. Before serving real user traffic, here are the things you'll want to tighten up.

Secrets management. Replace the flat .env file with AWS Secrets Manager or SSM Parameter Store (SecureString). This gives you rotation, audit trails, and fine-grained access control instead of plaintext on disk.

Origin encryption. Install a TLS certificate on your instance (self-signed works since CloudFront doesn't validate origin certs by default, or use Certbot for a free Let's Encrypt certificate), switch nginx to listen on 443, and set CloudFront's origin protocol to HTTPS-only. Then move your prefix list security group rule from port 80 to 443. This encrypts the hop between CloudFront and your origin so the X-Origin-Verify header can't be sniffed in transit.

Lock down SSM. Replace AWS-RunShellScript with a custom SSM document that only runs your deploy script. This limits the blast radius if your GitHub Actions role is ever compromised. See the example earlier in this post.

Security group hygiene. Remove SSH (port 22) access entirely — you have SSM Session Manager for shell access. Restrict port 80/443 ingress to the CloudFront managed prefix list (com.amazonaws.global.cloudfront.origin-facing) so only CloudFront can reach your origin.

Monitoring and detection. Set up CloudWatch alarms for CPU, memory, and disk usage. Enable VPC Flow Logs to capture network traffic metadata. Consider enabling AWS WAF on your CloudFront distribution to filter malicious requests. Without these, a breach or resource issue could go undetected indefinitely.

Zero-downtime deploys. Set up a blue/green deployment — spin up the new container, health-check it, then swap traffic only if healthy. Your deploy script can pull the new image, start it on a different port, verify it responds, then update nginx and stop the old container.

Scaling. If you outgrow a single instance, add an Auto Scaling Group with an Application Load Balancer to distribute traffic across multiple instances.

Cleanup

If you're done experimenting and want to tear everything down, here's the order I'd go in:

Head to Route 53 and delete the A records you created for your domain and www.
Go to CloudFront, disable your distribution, wait about 5 to 10 minutes, then delete it.
Delete the ACM certificate in Certificate Manager.
Head to ECR and delete your repository.
Terminate your EC2 instance and delete the security group and key pair you created.
Clean up the IAM roles and the OIDC identity provider for GitHub.

Going in this order avoids dependency issues, CloudFront needs to be disabled before you can delete the certificate, and Route 53 records need to be removed before disabling the distribution.

Wrapping up

Remember the problem we started with? Too many subscriptions, serverless timeouts, and no real control over your stack. We just solved all of that with a single EC2 instance.

Here's what we built: a t3.micro instance running Ubuntu with nginx as a reverse proxy, Docker for containerization, a CI/CD pipeline with GitHub Actions and ECR, CloudFront as our CDN with SSL via Certificate Manager, and Route 53 pointing our domain to it all.

This gives you a working foundation you can build on. Check the Production Hardening section above to close the gaps before serving real traffic — but the hard part is done. You own your stack, you understand every piece of it, and you can evolve it on your terms.

If this helped you out, drop a comment below and let me know what you're deploying. Until next time!

From Chat to Specs: A Deep Dive into AI-Assisted Development with Kiro

Erik Hanchett — Tue, 15 Jul 2025 16:57:38 +0000

This article was originally published on the Kiro blog from Ryan Yanchuleff.

As developers, we've all been there. You have a brilliant idea for a feature or application, you fire up your favorite AI coding assistant, and then... you spend the next hour going back and forth, refining requirements, clarifying edge cases, and watching your context window fill up with exploratory conversations before you even write a single line of code.

Kiro, a new IDE, fundamentally changes how we approach AI-assisted development through Spec-Driven Development.

Limitations of current AI coding assistants

Limitations of current AI coding assistants tend to follow a predictable and inefficient pattern. When a developer provides a high-level prompt, the AI immediately jumps into code generation, often before fully understanding the requirements. This premature action leads to a cycle where the developer must repeatedly clarify their intentions with "actually, I meant..." statements, as the initial requirements weren't sufficiently clear. As this exploratory dialogue continues, the context window becomes increasingly cluttered with back-and-forth discussions, leaving limited space for the final code generation. This constrained context space ultimately impacts the quality and completeness of the final output, making the entire process less efficient than it could be. This approach treats the LLM as a code generator first, when it should be considered a thinking partner throughout the entire development lifecycle.

Spec-driven development: Bridging design intent and implementation

If you're working on a challenging feature, Kiro serves as your intelligent sounding board to help you understand your codebase, define your problem clearly, and reach a quality solution efficiently. You can collaborate with Kiro on creating concise specifications that include clear requirements, system architecture, tech stack considerations, and implementation approach. Kiro helps make all requirements and constraints explicit, then uses these specifications as context to complete tasks with fewer iterations and higher accuracy. This is the power of spec-driven development. Let's dive deeper into some of the key benefits of Kiro's approach:

1. Understand your existing codebase

Before starting new development, Kiro analyzes your existing code and generates three foundational documents: structure.md (codebase architecture), tech.md (technical stack and patterns), and product.md (business context and requirements). This gives you and your team a clear baseline understanding that informs all subsequent specification work. Existing codebases can now take advantage of this new paradigm.

2. Analyze and plan your project

When you provide a project prompt in spec mode, Kiro's AI doesn't immediately start coding. Instead, it performs deep analysis to understand your requirements, identifies potential challenges, and creates comprehensive planning documents.

3. Generate comprehensive planning documentation

From a simple prompt, Kiro creates detailed specification files including:

Requirements Analysis - Breaking down your prompt into specific, actionable requirements
Technical Design - Architecture decisions, technology choices, and implementation approach
Task Breakdown - Granular development tasks with clear acceptance criteria

4. Collaborate with AI effectively

Kiro saves specification files in your project directory as readable markdown files. You can review, edit, and refine them before any code is written. This creates natural checkpoints for collaboration with team members or stakeholders.

5. Maximize coding context and efficiency

When it's finally time to write code, Kiro references these specification files rather than cluttering your context window with exploratory conversation. This means maximum context space is available for the actual coding task.

The power of spec-driven development

Spec-driven development delivers key advantages that fundamentally improve how teams design, build, and maintain software. Rather than treating planning as overhead, it becomes your competitive advantage. Here's how this approach transforms the development process:

Catch problems before they're expensive

Rather than discovering requirements issues mid-development, Kiro identifies and resolves ambiguities upfront. This prevents costly rewrites and provides alignment before coding begins.

Stay in control of your project's direction

The specification phase creates natural pause points where humans can review, modify, and approve the direction before resources are invested in implementation.

Iterate without losing your progress

If you make a mistake in defining your requirements, no problem. You can modify the specification files and regenerate the implementation plan without losing your entire conversation history.

Keep your AI focused on what matters

By externalizing the planning phase to files, Kiro keeps the active context focused on the immediate coding task, leading to higher quality code generation.

Enable seamless team collaboration

Specification files serve as living documentation that team members can review, comment on, and contribute to using standard development workflows.

Build institutional knowledge

Every decision and requirement is documented, creating a clear audit trail of why certain technical choices were made and preserving context for future team members.

Let’s see Kiro specs in action

The best way to understand spec-driven development is to see it in practice. Whether you're starting fresh or working with an existing codebase, Kiro's systematic approach enables you to build on a solid foundation. Here's how a typical workflow unfolds, from initial concept to implementation-ready specifications.

Step 1: Initiating your project

Before diving into new features, establish context for your project:

User: "Set up steering for this project"

Kiro analyzes your existing codebase and generates three foundational documents:

structure.md - Current architecture, key components, and code organization
tech.md - Technology stack, patterns, and technical constraints
product.md - Business context, existing features, and user workflows

This gives you a clear baseline understanding of what you're building upon.

Step 2: Generating your project specs

Now start laying out the details for the project that you want to build.

User: "I want to build a task management app for small teams with real-time collaboration features"

This is where the magic of spec-driven development becomes apparent. Rather than jumping straight into framework selection or database design, Kiro takes a step back to fully understand what you're trying to accomplish. It considers your prompt in the context of the steering documents, identifying how this new feature fits within your existing architecture and constraints.

Kiro creates a series of documents in sequential order, building from requirements through to actionable tasks:

requirements.md - Detailed feature breakdown including user stories and acceptance criteria
design.md - Architecture and technology decisions including frameworks, architecture diagrams, and structure
tasks.md - Development phases and tasks to be executed in a sequential order

Step 3: Reviewing and refining

You review the specifications, perhaps adding:

## Additional Requirements
- Integration with Slack for notifications
- Mobile-responsive design priority
- GDPR compliance considerations

Step 4: Informed Development

Now when Kiro begins coding, it references these comprehensive specifications rather than trying to infer requirements from conversation history. Every implementation decision is grounded in documented requirements and design choices.

The future of development is here—and it starts in the specs

Spec-driven development represents a shift from reactive coding to proactive specification that isn't just a workflow improvement—it's a fundamental evolution in how we partner with AI to build software. Instead of treating AI as a sophisticated autocomplete tool, spec-driven development positions it as your strategic thinking partner, helping you make better decisions before they become expensive to change. The result? Faster development cycles, higher quality code, fewer surprises, and documentation that actually stays current because it's integral to the process, not an afterthought. The next time you have a feature to build, try leading with specification instead of code. Your future self (and your teammates) will thank you for the clarity, and you might just discover that the best code is the code you plan before you write.

Ready to experience the difference? Kiro is now available and free during preview with generous usage limits. Download it and get started today!

What I Learned from Vibe Coding

Erik Hanchett — Wed, 26 Mar 2025 21:13:50 +0000

You may have heard this term called “vibe coding”. It’s a new way of thinking about creating software using AI. It was coined by Andrej Karpathy, and he describes vibe coding as “Giving into the vibes, embrace exponentials, and forget that code even exists”. Karpathy uses an AI coding assistant and he adopts the philosophy of “accepting all”, assuming the AI coding assistant will write and fix the software he’s creating.

While this way of coding sounds tempting, does it produce accurate enough results given today’s large language model limitations (LLM) and the overall changing landscape? Can you vibe code a complete application without issues? Can you have it create tests, and how does it handle inconsistencies with design? Is this a fad or a real long term strategy developers should learn and adopt?

I had these same questions too, so I decided to create an experiment for myself. Without any prior knowledge I wanted to update my old, and frankly out of date personal blog.

I’d vibe my way into a new, and hopefully better looking and functional website. The guard rails I set for myself was that I could NOT go into the code and make any changes. Everything would have to be done by using a prompt and the coding assistant. Additionally, I would try my best to assume no knowledge of web development. Spoiler, I broke the second rule - we’ll chat more about that later.

If you'd like to follow along, I created a full video of the experience!

Let's jump into how to set up this experiment!

Full disclosure - I'm a Senior Developer Advocate for AWS!

Setup

For this experiment I am using Amazon Q CLI as my coding assistant. This command line interface (CLI) tool will be my agent, and I’ll prompt it to create my new personal website. I am a huge fan of CLI tools, and this will work perfectly for my experiment. If you'd like to follow along, Q CLI is easy to install and supports several different operating systems, including my favorites MacOS, WSL and Linux. You can even set it up over SSH if needed. Also, don’t forget to sign up for Builder ID, it’s a free to sign-up and you’ll need it to sign in with the CLI.

To speed things up a bit, I created a brand new application using Nuxt 3 with Tailwind CSS 4. I followed the procedures on the Nuxt installation guide and then chose the Nuxt UI installation that includes Tailwind CSS 4. I cleared out the starter files and began with a simple index.vue file to start.

Here is my starting point.

It’s worth mentioning that even though I used Nuxt which uses Vue.js, I’m almost certain this experiment would have worked the same way or even better with React, Angular, or even Svelte.

Building My Personal Website

One thing I know about prompting, is that you should try to be specific. So I started with a basic prompt.

This prompt was explicitly written to generate a personal website, with spring colors, and animations. I then listed out that I wanted a blog, contact me, profile picture and bio page. For good measure I added in that I was using Tailwind CSS 4 and it was configured already. Although not necessary I always try to be polite with my prompts, and I was sure to include please and thank you. 😊

After entering the prompt in and hitting enter I noticed that Q CLI read my directory and summarized what it was going to do. This was nice to see that things were going in the right direction.

At this point Q CLI started creating pages and I started blindly accepting ‘y’ for each change.

It’s worth noting you can set Q CLI to accept all changes by using the /acceptall configuration or -a argument when you begin q chat. However, in this example I decided to just manually accept all changes.

Missing image

After a few times of pressing ‘y’ on my keyboard, and accepting all the changes, I noticed a small issue with the bio.vue page that was just created.

No problem! I told Q to fix the file, and it continued on it’s way!

Nuxt config update

As I was continuing on confirming all changes a message came up to confirm a new update to the nuxt.config.ts file.

One of my goals for this experiment was to assume no knowledge of web development and blindly "accept all" to all changes. However, to save time, and to fix an obvious issue, I stopped Q CLI when it tried to make modifications to the nuxt.config.ts file. One of the primary responsibilities of this file is to add modules. Q CLI wanted to remove my nuxt-ui module which would have broken all my Tailwind CSS in the app.

Looking at the output, I believe Q CLI was confused and wanted to add in some PostCSS configuration, which is more often used with Tailwind CSS 3. To be safe here I typed no here and reminded Q CLI that I was using a module and that I didn’t need this configuration. It continued on without issue, and did not update this file.

First iteration of website

After a few more minutes of accepting more changes and fixing the minor mistakes mentioned earlier, my new personal website appeared! 🎉

It included most of the features I was expecting including a featured projects section. One thing that was not working was the blog section. So I went back and asked for it to create it.

Within a few minutes it added an interactive blog. It even added in pagination, tags, and search functionality!

Overall it did a good job with the blog. It created separate dynamic routes for each page, and the tag filtering and search worked as well. The only concerns I had were with a few small design issues with mobile responsiveness.

Adding more updates

I continued on for another few minutes cleaning up the design. I asked Q CLI to update all the place holder images with images from Unsplash. I then had it clean up a few minor visual issues. This definitely made the site look a little cleaner.

I then had it commit the changes into it’s own branch using git. It's important having an easy way to roll back or change between commits. As an added bonus from doing this, Q CLI started committing all my changes without me having to ask after every update.

Testing

Testing is really important for any software you create. It’s a great way to ensure you don’t break anything while making updates to a code base. When working with AI coding assistants this is even more important. By creating tests AI agents can check that their changes didn’t break anything, and if they do fix the issue.

To help test this philosophy I asked Q CLI to make some simple tests for each page in the application. With in seconds it installed vitest, and test-utils and began creating tests for each page.

One thing surprised me is that after creating all these tests, they didn’t pass. Q CLI went back and made changes 3-4 times until every test passed. I was impressed that it was able to self correct itself without additional prompting. Afterwards I quickly checked the tests out and they looked fine for this project.

Conclusion

The goal was to vibe code, and this was a success. I was able to create a profesional, nice looking, personal website that featured a blog, contact page, and bio. I never once had to fix anything in the code myself, and I was able to prompt my way through all the errors and problems that occurred.

That said, if I hadn't known anything about web development, it would have been a different experience. Q CLI got Tailwind CSS 3 and 4 mixed up and it would have caused an issue if I blindly accepted all the change. On the other hand, I’m confident I could have prompted my way to fix it, it would have just taken longer. This issue may be certainly fixed by the time you read this, but just realize when you are working with the latest libraries, your favorite coding assistant may not be up to date.

Is vibe coding a fad? I don’t think so. This is a perfectly valid way of creating software, and as LLMs and AI coding assistants get better the number of corrections or errors will decrease. Vibe coding is certainly not a substitute for a real software developer, and I can imagine as you try to vibe code into a much more complicated app, it won’t work as well. You’ll always need to have a developer to help out where the LLM lacks. As for me, I’ll be looking to update my personal site with this new code soon! After I vibe code a few more updates. 😉

How To Create A Fullstack TypeScript App Using AWS Amplify Gen 2

Erik Hanchett — Fri, 31 May 2024 19:06:37 +0000

AWS Amplify Gen 2 is a brand new way to create fullstack applications on AWS. In this tutorial, we’ll explore how to get started creating a fullstack TypeScript application with Next.js! We’ll add storage and then connect it to our Amplify connected UI component library to upload files.

With Gen 2 we focused our efforts on creating a great developer experience. We wanted to make sure that you could focus on your frontend code instead of worrying about setting up your backend infrastructure. In this new version we created a brand new TypeScript safe DX that supports fast local development, and is backed by AWS Cloud Development Kit (CDK).

We recently released Gen 2 for general availability. Feel free to let us know what you think and leave a comment below.

With that said, before you get started makes sure your familiar with TypeScript, VSCode and Git. You'll also need a GitHub account and make sure Git is installed locally on the command line. We'll be using Next.js, however you don't need to be an expert in React to try out this tutorial.

What Are We Building Today?

We will be creating an app that allows you to create todos with pictures. You’ll be using the Amplify Next Starter template and have it deployed to the AWS Amplify console. We'll create and connect to AWS AppSync, our managed GraphQL service, and use Amazon Cognito, our customer identity and access management service, to authenticate and authorize users. Additionally, we'll use S3 for file storage of our images.

In this tutorial I'll walk you through step-by-step on how to create a new AWS Amplify Gen 2 app using the console, cloning that app, opening it in VSCode and adding in some additional features. We'll then deploy our changes back to the Amplify Gen 2 console to our hosted environment.

Setup

We need to first have an AWS account ready. If you are not signed up, try out the AWS Free Tier! This will give you plenty of free resources to try out AWS and many of it's services. Keep in mind, all the services we'll work with today are on-demand and you'll only get charged when you are using them.

We will be using the Next.js Amplify starter template as described in the Quickstart guide. Clone the repository using the Amplify Next.js Template into your own Github account to get started.

Afterwords, sign into the AWS management console. Search at the top for AWS Amplify, and click it.

In the Amplify Console choose Create new app.

Select GitHub as the Git provider.

In the next page you'll see a popup asking to connect to your Github account. This will give Amplify access to your account so it can connect to the Next.js repo you just created in the previous step from the starter template.

Select your app from the App name field and click next. If you don’t see your app click the Update Github permissions button and re-authorize with Github. On the next page leave all the default settings and click next. On the last page click Save and deploy. Amplify will now begin to deploy your new app!

The deployment may take several minutes. It will host your Next.js frontend and create infrastructure for your Amazon Cognito and AWS AppSync service backend. We’ll discuss this more later, and how we can make updates and changes to it. Until then, let's jump into VSCode and setup the frontend!

Updating the frontend

Let's take a look at our app, and make some updates.

Open up your favorite terminal and clone the Github repo you just created in the previous section.

git clone <The_Copied_Githhub_URL>

Open up VSCode to that cloned project and open a terminal to the project’s root folder. Run the following command.

npm i @aws-amplify/ui-react-storage

This will install the Amplify UI component library. We'll use this later to add a file uploader, called Storage Manager, to our frontend to help with uploading pictures.

If you look at the app folder structure you'll notice an amplify folder. This folder houses all the resources and files that will help us connect to our backend.

By convention, the starter template will create an Amazon Cognito instance, and configure it for email login. The configuration for this will be in the resources file at amplify/auth/resource.ts. For more information on the auth resource please checkout the docs.

It also creates an AWS Appsync instance with a Todo schema in the amplify/data/resource.ts file.

Update the data/resource.ts to match the code below. The only difference is we are adding a new key to the model.

// amplify/data/resource.ts

const schema = a.schema({
  Todo: a
    .model({
      content: a.string(),
      key: a.string(),
    })
    .authorization((allow) => [allow.publicApiKey()]),
});

export type Schema = ClientSchema<typeof schema>;

export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: "apiKey",
    apiKeyAuthorizationMode: {
      expiresInDays: 30,
    },
  },
});

This schema does a few things.

Adds a new Todo model with all the resolvers needed CRUDL (Create, Read, Update, Delete, List) and connects it to a new DynamoDB instance.
The Todo model will have a content and a key fields - both are strings.
Adds public authorization rules so all users can create, read, update and delete, as long as they have the public api key.
Sets a default authorization mode of apiKey and sets the expiration for 30 days. This is the public key.
Exports a Schema that can be used by the frontend to ensure type safety end-to-end.

This resource data pattern is very powerful by allowing the user to completely configure the backend data schema all in code using TypeScript.

For the sake of this tutorial we will leave the default resource file unchanged for auth in the amplify/auth/resources.ts file.

Adding Storage

We need to be able to upload images and retrieve them. We can do this using the Amplify Storage Category.

Create a new folder at amplify/storage. Inside this folder create a resource.ts file. Copy the following code.

// amplify/storage/resource.ts

import { defineStorage } from "@aws-amplify/backend";

export const storage = defineStorage({
  name: "todosStorage",
  access: (allow) => ({
    "media/*": [
      allow.guest.to(["read", "write", "delete"]), // additional actions such as "write" and "delete" can be specified depending on your use case
    ],
  }),
});

This will create a public bucket for users to upload our images too. Users will be able to upload images to the media folder and they’ll have access to read, write, and delete them.

Next, let’s add this storage resource to our backend.ts file. Open the backend.ts file and add a new storage import. The complete file is below.

//amplify/backend.ts

import { defineBackend } from "@aws-amplify/backend";
import { auth } from "./auth/resource.js";
import { data } from "./data/resource.js";
import { storage } from "./storage/resource.js";

defineBackend({
  auth,
  data,
  storage,
});

All our backend resource should be ready to go!

Starting the Sandbox

To test locally we'll create a new ephemeral environment using Amplify tooling.

If you've never setup AWS on the command line you'll need to run a few commands here to make sure your environment can connect to your account. Please follow the Set up your AWS Account section section in our docs before continuing on.

npx ampx sandbox

This command will create an environment in AWS based on the resources you configured in your amplify folder. In this case it will create a Amazon Cognito, S3 Storage and AWS AppSync service. At any time you can stop this command, and it will delete all the resources it just created.

It will also create an amplify_outputs.json file in the root of your app. We'll need this file in the next section to setup our client aws-amplify library so it can talk to the backend services.

This will take a few minutes to run, after it completes continue onto the next section.

Update page.tsx

The starter template has a built in todos app in it. Let’s modify the page.tsx file so we can upload files and connect them with our todos.

Inside the page.tsx app add an import for StorageManager, StorageImage and to our Amplify UI components library.

// app/page.tsx
...

import { StorageImage, StorageManager } from "@aws-amplify/ui-react-storage";
import { Card, Flex, Text, Button } from "@aws-amplify/ui-react";

The UI components, Card, Flex, Text and Button are used to style our app. The StorageImage and StorageManager will allow us to add images and show them.

We need to be able to delete todos. Add the following function under the listTodos().

// app/page.tsx

...
 function deleteTodo(id: string) {
    client.models.Todo.delete({ id });
 }

We’ll need to update the createTodo function. It will now take in two arguments, key and content.

// app/page.tsx

...
  function createTodo({ key, content }: { key: string; content: string }) {
    client.models.Todo.create({
      content,
      key,
    });
  }

We’ll now do a few updates to the return statement. We’ll add a new StorageImage that will display our images. We’ll also add in the StorageManager. This will display a component so we can upload images.

Update the return so it matches below.

// app/page.tsx

return (
    <main>
      <h1>My todos</h1>
      <ul>
        {todos.map((todo) => (
          <li key={todo.id} onClick={() => deleteTodo(todo.id)}>
            <Flex justifyContent="space-between">
              <Text>{todo.content}</Text>
              {todo.key ? (
                <StorageImage
                  path={todo.key}
                  alt={todo.content || ""}
                  width="100px"
                />
              ) : null}
            </Flex>
          </li>
        ))}
      </ul>
      <StorageManager
        path="media/"
        acceptedFileTypes={["image/*"]}
        maxFileCount={1}
        onUploadStart={({ key }) => {
          const content = window.prompt("Todos content");
          if (!key || !content) return;
          createTodo({ key, content });
        }}
        components={{
          Container({ children }) {
            return <Card variation="elevated">{children}</Card>;
          },
          FilePicker({ onClick }) {
            return (
              <Button variation="primary" onClick={onClick}>
                Add Todo and Choose File For Upload
              </Button>
            );
          },
        }}
      />
    </main>
  );

You may notice some props on the StorageManager. The components prop can be used to completely override the look and feel of the component. In this case we changed the container slightly to add a card around it. We also changed the FilePicker so we can use a different kind of button to upload.

We added an event listener called onUploadStart. This will trigger whenever an upload begins. It will first ask the user for the todos content. It will then call the createTodo which will create the todo in the database.

Here is the complete app/page.tsx file.

"use client";
import { useState, useEffect } from "react";
import type { Schema } from "@/amplify/data/resource";
import { generateClient } from "aws-amplify/data";
import { StorageImage, StorageManager } from "@aws-amplify/ui-react-storage";
import { Card, Flex, Text, Button } from "@aws-amplify/ui-react";
import React from "react";
import { Amplify } from "aws-amplify";
import outputs from "@/amplify_outputs.json";
import "@aws-amplify/ui-react/styles.css";
Amplify.configure(outputs);
const client = generateClient<Schema>();

export default function App() {
  const [todos, setTodos] = useState<Array<Schema["Todo"]["type"]>>([]);

  function listTodos() {
    client.models.Todo.observeQuery().subscribe({
      next: (data) => setTodos([...data.items]),
    });
  }

  function deleteTodo(id: string) {
    client.models.Todo.delete({ id });
  }

  useEffect(() => {
    listTodos();
  }, []);

  function createTodo({ key, content }: { key: string; content: string }) {
    client.models.Todo.create({
      content,
      key,
    });
  }

  return (
    <main>
      <h1>My todos</h1>
      <ul>
        {todos.map((todo) => (
          <li key={todo.id} onClick={() => deleteTodo(todo.id)}>
            <Flex justifyContent={"space-between"}>
              <Text>{todo.content}</Text>
              {todo.key ? (
                <StorageImage
                  path={todo.key}
                  alt={todo.content || ""}
                  width="100px"
                />
              ) : null}
            </Flex>
          </li>
        ))}
      </ul>
      <StorageManager
        path="media/"
        acceptedFileTypes={["image/*"]}
        maxFileCount={1}
        onUploadStart={({ key }) => {
          const content = window.prompt("Todo content");
          if (!key || !content) return;
          createTodo({ key, content });
        }}
        components={{
          Container({ children }) {
            return <Card variation="elevated">{children}</Card>;
          },
          FilePicker({ onClick }) {
            return (
              <Button variation="primary" onClick={onClick}>
                Add Todo and Choose File For Upload
              </Button>
            );
          },
        }}
      />
    </main>
  );
}

Trying it out

Go ahead and start the app.

npm run dev

The front page will load. Go ahead and click the Add Todo and Choose File for Upload button.

Choose a todo name and then choose a file. You’ll see the upload occur and a new todo displayed.

You can go ahead and add a few more. You can also click any todo for them to delete.

Good job! You've created a full stack app!

Deploy to Production

In the first steps we created a new Next.js app using a starter template, we then cloned it down to edit it locally. We can now commit our changes and have it deployed back to our AWS Gen 2 console that will trigger a new branch build .

If you like, you can go ahead and stop the sandbox environment. Just go to the terminal where it's running and hit Ctrl/Cmd C. If for some reason you accidentally closed the terminal, you can always stop any sandbox environments by going back to the Amplify Gen 2 console and choosing the Manage Sandboxes button in the All apps page.

The sandbox environments are for testing only, and can be started or stopped at any time. The production environments are attached to your git branches that you pushed to Github. In this case the main branch is the production environment. If we choose to do so, we can create multiple environments if needed based on any branch we create and connect them to the AWS Gen 2 console.

To deploy our changes with the new frontend updates, all we'll need to do is a git commit and push. Open the terminal in your project and paste the following commands.

git add .
git commit -m "Updated todos App"
git push origin main

This will push all our changes to the Amplify Gen 2 console and trigger another build. After a few minutes click on the domain listed in the Amplify console to see it in action!

Conclusion

In this tutorial we learned how to get started with AWS Amplify Gen 2. We used the Amplify Next.js starter template to create a new Amplify hosted app with our backend. We then made a todo app with photo storage, used the sandbox environment to test, and then pushed it to production to see the changes!

To clean up this environment, make sure to stop the sandbox environment and then go back into the amplify console, click on our app, then go to App settings → General Settings.

Click on the Delete app button.

If you'd like to learn more make sure to check our the official docs!

Five Tutorials To Create Your Fullstack Apps Using AWS Amplify Gen 2

Erik Hanchett — Fri, 01 Mar 2024 18:16:59 +0000

AWS Amplify Gen 2 is the next generation of tooling from Amplify! It’s a new code-first developer experience that helps frontend developers create fullstack applications on AWS. You can now author your frontend and backend definition completely in TypeScript, create ephemeral sandbox environments to test against, and deploy to production using Git branch-based environments.

Since we’ve entered into developer preview at the end of last year a lot of content has been created! Let’s jump in!

Introducing The Next Generation of AWS Amplify’s Fullstack Development Experience

Amplify has unveiled a code-first way to develop fullstack applications. This post deep dives into why we decided to go this direction and how to get started. If you are looking for a overview of Gen 2, here is the place!

The guide to set up NextJS Authentication and data fetching with AWS Amplify Gen2

This post describes how to add auth and data to your application using Amplify Gen 2. This step-by-step tutorial covers creating a new Next.js 14 application, adding in Gen 2, and setting up authentication. It also shows how to use middleware to protect routes and use the generateClient API to add and list data from the backend.

How To Create A Full Stack Typesafe App With No Knowledge! Using AWS Gen2 and Next.js 14!

This video describes how to create a fullstack application using Gen 2 with Next.js 14. In it, Erik creates a protected Next.js 14 application using auth. The application helps you store titles and allows multiple users to leave comments. Viewers will learn how to create, update, list, and delete comments and titles, as well as how to setup dynamic routes. All of this backed by Gen 2, and AWS AppSync.

The future of web development: AWS Amplify’s Code First Approach

This extended article describes what Amplify Gen 2 is, the problems frontend developers face with fullstack applications, and how to resolve them. Christian uses several code examples to illustrate how to use Gen 2, extend its functionality and how to use it in your next project.

How To Add A Social Login To Your Website Using AWS!

This advanced tutorial describes how to extend Amplify Gen 2’s functionality to add a Github social login. It deep dives into OAuth, OIDC, authorization and authentication. It describes how AWS Amplify Cognito, as well as identity providers can work together with Gen 2 to create social logins.

Conclusion

There you have it! Five different tutorials on how to use AWS Amplify Gen 2! Please leave a comment below if you’ve tried Gen 2! Thanks

Secrets of Styling Forms (Using AWS Amplify Studio)

Erik Hanchett — Mon, 17 Jul 2023 21:37:19 +0000

Forms are deceptively difficult. When you create a form for your website you need to make a lot of decisions. You have to worry about validation, structure, and how to send the data to your backend. You need to figure out how to handle errors, and how to style and configure your form. You’ll need to make sure your forms are accessible. With this in mind, AWS Amplify Studio with its form builder can help!

In this post I’ll discuss how to add a new form using Amplify Studio that is connected to an AWS Appsync data source. We’ll look at how to customize that form by adding in a dark/light mode. We’ll look at how we can further customize the validation rules and edit the error messages! We’ll then test our submissions by displaying the results using Amplify’s JavaScript GraphQL API library.

If you'd like to see the completed code. Please check out this repo!

Getting Started

We’ll create a basic Todo form using Amplify studio.

To begin, sign into your AWS Console and search for AWS Amplify and click on it. If this is the first time using Amplify, choose Get Started and click on the Get started again under Amplify Studio. If you’ve already created an Amplify app in this region you can click New app → Build an app. Choose an app name, click Confirm deployment. Afterwords click Launch Studio to begin!

If you are an existing Amplify Studio user, Launch Studio from your existing application. This feature is available to all.

Data

Inside Amplify Studio let’s create a data source that we can use with our form. Click on Data in the menu.

Click Add model and create Todo. Add the completed and the title fields.

After adding these models make sure you click the Save and Deploy button in the top right hand corner. It may take a few minutes to deploy.

After the model is deployed you’ll see a page with some instructions to pull the latest client config into your React application. Make sure to copy the pull command.

Next.js App Setup

Now that we have our data and forms in place we can pull the information into our existing application. I’ll assume that you’ve already created a new Next.js application. If not, and you are starting a new Next.js application, make sure the App router turned off.

Open up your app and install these libraries with your favorite package manager.

$ npm install @aws-amplify/ui-react aws-amplify react-icons

If not already installed, make sure you also install the Amplify CLI globally.

$ npm install @aws-amplify/cli -g

If this is the first time using Amplify in a while, make sure you upgrade to the latest version of the CLI.

$ amplify upgrade

Next, take the command you copied from the last section and paste it into your terminal running it in the root of your Next.js project.

$ amplify pull --appId <replace-this-with-your-id> --envName <replace-with-env-name>

You should now see a few new files and directories in your project.

Since we are dealing with AppSync, you’ll need to generate some GraphQL query files.

$ amplify codegen add

This will generate some helpful GraphQL query/subscription/mutation files that we’ll use later on in this tutorial.

Let’s setup Amplify so we can use our new forms!

Note: If you are using Next.js with the app router or using Vite, you may need some small additional configuration. Please follow the Next.js or Vite usage guide.

Adding Our Form and Customizing it

Let’s begin setting up our Next application so it can talk to our AppSync backend.

Inside your main entry point file in your application, add these lines to configure Amplify with the correct styles.

import { Amplify } from "aws-amplify";
import awsExports from "../aws-exports";
Amplify.configure(awsExports);
import "@aws-amplify/ui-react/styles.css";

Next, we’ll be adding in a special theme file. This file is used to customize global themes throughout your application. In our case we will us to to override the default theme of our forms to support a dark mode. The defaultDarkModeOverride will add this for us.

Create a new file called theme.tsx in your src folder.

import { Theme, defaultDarkModeOverride } from "@aws-amplify/ui-react";

export const theme: Theme = {
  name: "theme",
  overrides: [defaultDarkModeOverride],
};

Next, we’ll add this Theme provider to a new Layout file. In the src/components folder create a new Layout.tsx file. Inside this file we’ll add a new colorMode useState variable that we’ll use to change the color of the theme.

The ThemeProvider surrounds our application and provides theming capabilities with design tokens to our app. These tokens can completely override the look and feel of our application. The official documentation discuss this in more detail.

import { theme } from "@/theme";
import { ColorMode, ThemeProvider } from "@aws-amplify/ui-react";
import React from "react";


export default function Layout({ children }: React.PropsWithChildren) {
  const [colorMode, setColorMode] = React.useState<ColorMode>("light");
  return (
    <ThemeProvider theme={theme} colorMode={colorMode}>
        {children}
    </ThemeProvider>
  )
}

Let’s add in a toggle button so users can select between dark and light mode. We’ll be using the react-icons/md set for these icons.

import { theme } from "@/theme";
import { MdOutlineDarkMode, MdOutlineLightMode } from "react-icons/md";
import { ColorMode, Flex, ThemeProvider, ToggleButton, ToggleButtonGroup } from "@aws-amplify/ui-react";
import React from "react";


export default function Layout({ children }: React.PropsWithChildren) {
  const [colorMode, setColorMode] = React.useState<ColorMode>("light");
  return (
    <ThemeProvider theme={theme} colorMode={colorMode}>
      <Flex direction="column" gap="0" width="100vw" height="100vh" backgroundColor="background.primary">
          <ToggleButtonGroup
            value={colorMode}
            size="small"
            isExclusive
            onChange={(value) => setColorMode(value as ColorMode)}
          >
            <ToggleButton value="light">
              <MdOutlineLightMode />
            </ToggleButton>
            <ToggleButton value="dark">
              <MdOutlineDarkMode />
            </ToggleButton>
          </ToggleButtonGroup>
        {children}
      </Flex>
    </ThemeProvider>
  )
}

The ToggleButtonGroup is from a set of UI primitives offered by the @aws-amplify/ui-react library. It creates a nice looking toggle button. On every click of the toggle button the colorMode is set, and is updated in the ThemeProvider. This will cause the screen to change between dark and light mode.

Finally, we’ll add in an AppHeader component to help sticky this layout to the top left hand corner. We’ll also add a nice icon using the Icon component primitive.

import { theme } from "@/theme";
import { MdOutlineDarkMode, MdOutlineLightMode } from "react-icons/md";
import {
  ColorMode,
  Flex,
  Icon,
  ThemeProvider,
  ToggleButton,
  ToggleButtonGroup,
} from "@aws-amplify/ui-react";
import React from "react";

function AppHeader({ children }: React.PropsWithChildren) {
  return (
    <Flex
      as="header"
      direction="row"
      justifyContent="space-between"
      alignItems="center"
      padding="1rem"
      boxShadow="small"
      position="sticky"
      top="0"
      left="0"
      width="100%"
      backgroundColor="background.primary"
    >
      {children}
    </Flex>
  );
}

export default function Layout({ children }: React.PropsWithChildren) {
  const [colorMode, setColorMode] = React.useState<ColorMode>("light");
  return (
    <ThemeProvider theme={theme} colorMode={colorMode}>
      <Flex
        direction="column"
        gap="0"
        width="100vw"
        height="100vh"
        backgroundColor="background.primary"
      >
        <AppHeader>
          <Icon
            color="brand.primary.60"
            fontSize="xl"
            paths={[
              {
                d: "M10.8484 4.19838C10.7939 4.2926 10.7939 4.40867 10.8484 4.50288L21.3585 22.6711C21.413 22.7653 21.5138 22.8233 21.6228 22.8233H23.9901C24.225 22.8233 24.3718 22.5696 24.2543 22.3666L12.5605 2.15225C12.4431 1.94925 12.1495 1.94925 12.0321 2.15225L10.8484 4.19838Z",
              },
              {
                d: "M15.2084 22.6711C15.2629 22.7653 15.3636 22.8233 15.4726 22.8233H17.8461C18.081 22.8233 18.2278 22.5696 18.1104 22.3666L9.48857 7.46259C9.37113 7.25959 9.07755 7.25959 8.96011 7.46259C6.09213 12.4203 3.21732 17.4003 0.336955 22.3816C0.219574 22.5846 0.366371 22.8383 0.601212 22.8383H11.7185C11.9533 22.8383 12.1001 22.5846 11.9827 22.3816L10.8455 20.4158C10.791 20.3216 10.6903 20.2635 10.5813 20.2635H4.8952C4.77776 20.2635 4.70437 20.1367 4.76308 20.0352L9.0912 12.5534C9.14991 12.4519 9.29671 12.4519 9.35542 12.5534L15.2084 22.6711Z",
              },
            ]}
          />
          <ToggleButtonGroup
            value={colorMode}
            size="small"
            isExclusive
            onChange={(value) => setColorMode(value as ColorMode)}
          >
            <ToggleButton value="light">
              <MdOutlineLightMode />
            </ToggleButton>
            <ToggleButton value="dark">
              <MdOutlineDarkMode />
            </ToggleButton>
          </ToggleButtonGroup>
        </AppHeader>
        {children}
      </Flex>
    </ThemeProvider>
  );
}

We’ll need to update the _app.tsx file so our new layout surrounds the application.

...
export default function App({ Component, pageProps }: AppProps) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  );
}

Toggle the dark mode and see it in action.

Before:

After:

Adding our form and customizing them

Let’s now add in our form to the main route index.tsx file in our Next.js application.

Import the form onto the page.

import TodoForm from "@/ui-components/TodoCreateForm";

export default function Home() {

return <TodoForm/>

}

By convention this form is already connected to the AppSync model we created earlier. Under the covers it uses something called DataStore to sync and send data to the backend.

We can customize this form to our liking. Let’s update the validation rule first. Assume that we don’t want users to enter in empty spaces. We’ll add a check for that and display a custom error message.

 <TodoForm
    padding="0"
    onValidate={{
       title: (value, validateResponse) => {
         if (value.trim().length === 0) {
             return {
             hasError: true,
               errorMessage: "Please enter a value!",
             };
          }
          return validateResponse;
       },
     }}
  />

With this validation in place, users won’t be able to submit a blank input in without getting an error. The forms logic will handle the rest and will disable the input as well.

Imagine we want to show a message every time the user successfully submit a todo. The generated forms have event handlers that you can hook into and listen for. In this example, we’ll create a showSuccess variable that we can use to trigger an alert message, that fades after two seconds.

const [showSuccess, setShowSuccess] = useState(false);
  ...
        <TodoForm
          padding="0"
          onValidate={{
            title: (value, validateResponse) => {
              if (value.trim().length === 0) {
                return {
                  hasError: true,
                  errorMessage: "Please enter a value!",
                };
              }
              return validateResponse;
            },
          }}
          onSuccess={() => {
            setShowSuccess(true);
            setTimeout(() => {
              setShowSuccess(false);
            }, 2000);
          }}
        />
        {showSuccess && <Alert variation="success">Todo added!</Alert>}

The onSuccess handler will trigger as soon as the form has submitted successfully. We can then show an alert! This Alert is another @aws-amplify/ui-react UI primitive.

Now that we have a way to add todo’s, we will need a way to show them.

Let’s add a method that grabs all the todos. This will use the Amplify JS library GraphQL API.

import { API, graphqlOperation } from "aws-amplify";
import { GraphQLQuery, GraphQLSubscription } from "@aws-amplify/api";
import { ListTodosQuery, Todo, OnCreateTodoSubscription } from "@/API";
import { listTodos } from "@/graphql/queries";
...
const [todos, setTodo] = useState<Todo[]>([]);


const getTodos = async () => {
    const allTodos = await API.graphql<GraphQLQuery<ListTodosQuery>>({
      query: listTodos,
    });

    const filteredTodos = allTodos.data?.listTodos?.items
      .filter((todo) => !todo?._deleted)
      .sort(
        (a, b) =>
          new Date(a?.createdAt!).getTime() - new Date(b?.createdAt!).getTime()
      );

    setTodo(filteredTodos as Todo[]);
  };

Since we created our application using Studio and form builder, by convention our forms uses DataStore and conflict resolution turned on in the background. Conflict resolution creates a versioned data source that enhances the object data model with metadata. At this time, you cannot turn this off when using Form Builder and studio.

What that means is that our Data model has a few extra meta fields including _deleted and _version . These are automatically added to our data model when the model was created. When you delete a record, it doesn’t get deleted, the way you normally may expect. Instead, the _deleted field gets set to true and the record remains. Keep this in mind when dealing with data with conflict resolution turned on. This is why we must filter out records with _deleted set to true in our code, that way we don’t accidentally show deleted data.

It’s good to know that if you decide to make updates or deletions to any record using the Amplify GraphQL API, you must also include the _version in the GraphQL input since conflict resolution is turned on. The _version field will increment on every change that occurs to the record. You’ll need to keep track of this _version field when you make updates or delete an item.

To guarantee the correct order, we sort by the createdAt time.

Now that we have a way to grab data, we’ll create a GraphQL subscription that will load as soon as the application loads using a useEffect.

import { API, graphqlOperation } from "aws-amplify";
import { GraphQLQuery, GraphQLSubscription } from "@aws-amplify/api";
import { ListTodosQuery, Todo, OnCreateTodoSubscription } from "@/API";
import { onCreateTodo } from "@/graphql/subscriptions";
import { useEffect, useState } from "react";
...

const [todos, setTodo] = useState<Todo[]>([]);

useEffect(() => {
    getTodos();
    const sub = API.graphql<GraphQLSubscription<OnCreateTodoSubscription>>(
      graphqlOperation(onCreateTodo)
    ).subscribe({
      next: ({ provider, value }) => {
        setTodo((prevValue) => [
          ...prevValue,
          value.data?.onCreateTodo as Todo,
        ]);
      },
      error: (error) => console.warn(error),
    });

    return () => sub.unsubscribe();
  }, []);

We first trigger the getTodos and then run our subscription. As soon as a new Todo is created, the subscription is triggered. We can then use our setTodo to save the data into the array. Alternatively, we could call getTodos again on every subscription change, however for the sake of this post we’ll manipulate the todos array and add the new todo to it instead.

Let’s put this all together into one file. I’ve added a few more UI primitives to make things easier including a Collection component that is used with the array to display data in a nice row.

import {
  Alert,
  Card,
  Collection,
  Flex,
  Heading,
  Text,
  useTheme,
} from "@aws-amplify/ui-react";
import TodoForm from "@/ui-components/TodoCreateForm";
import { API, graphqlOperation } from "aws-amplify";
import { GraphQLQuery, GraphQLSubscription } from "@aws-amplify/api";
import { ListTodosQuery, Todo, OnCreateTodoSubscription } from "@/API";
import { listTodos } from "@/graphql/queries";
import { onCreateTodo } from "@/graphql/subscriptions";
import { useEffect, useState } from "react";

export default function Home() {
  const [showSuccess, setShowSuccess] = useState(false);
  const [todos, setTodo] = useState<Todo[]>([]);

  const getTodos = async () => {
    const allTodos = await API.graphql<GraphQLQuery<ListTodosQuery>>({
      query: listTodos,
    });

    const filteredTodos = allTodos.data?.listTodos?.items
      .filter((todo) => !todo?._deleted)
      .sort(
        (a, b) =>
          new Date(a?.createdAt!).getTime() - new Date(b?.createdAt!).getTime()
      );

    setTodo(filteredTodos as Todo[]);
  };

  useEffect(() => {
    getTodos();
    const sub = API.graphql<GraphQLSubscription<OnCreateTodoSubscription>>(
      graphqlOperation(onCreateTodo)
    ).subscribe({
      next: ({ provider, value }) => {
        setTodo((prevValue) => [
          ...prevValue,
          value.data?.onCreateTodo as Todo,
        ]);
      },
      error: (error) => console.warn(error),
    });

    return () => sub.unsubscribe();
  }, []);

  const { tokens } = useTheme();

  return (
    <Flex
      direction="row"
      height="100%"
      width="100%"
      justifyContent="stretch"
      gap="0"
    >
      <Flex
        direction="column"
        gap="medium"
        padding="xxl"
        backgroundColor="background.primary"
      >
        <Text>New ToDo</Text>
        <TodoForm
          padding="0"
          onValidate={{
            title: (value, validateResponse) => {
              if (value.trim().length === 0) {
                return {
                  hasError: true,
                  errorMessage: "Please enter a value!",
                };
              }
              return validateResponse;
            },
          }}
          onSuccess={() => {
            setShowSuccess(true);
            setTimeout(() => {
              setShowSuccess(false);
            }, 2000);
          }}
        />
        {showSuccess && <Alert variation="success">Todo added!</Alert>}
      </Flex>
      <Flex
        direction="column"
        flex="1"
        padding="xxl"
        backgroundColor="background.secondary"
      >
        <Heading level={3}>List of Todos</Heading>

        <Collection gap="small" type="list" items={todos}>
          {(todo) => (
            <Card
              variation="elevated"
              color={tokens.colors.brand.primary[100]}
              marginTop="1rem"
              padding="1rem"
              key={todo.id}
              textDecoration={todo?.completed ? "line-through" : ""}
            >
              {todo?.title}
            </Card>
          )}
        </Collection>
      </Flex>
    </Flex>
  );
}

Let’s take a look at it in action:

And with dark mode, after clicking the dark mode icon!

There is a lot more we could do here. We could add a way to take already existing todos and delete them and mark them complete. I’ll leave that exercise for you!

Deletion

Once you’re done with your application you can delete all your resources by running amplify delete.

Conclusion

In this blog post we’ve learned about Amplify Studio forms, how to customize them and how to add additional validation error messages. If you’d like to learn more about Amplify in general please check out the official docs. You can also check the Amplify Studio tutorial for more information on how to use it.

Please let me know if you have any questions, I’m at ErikCH on Twitter!

Front End Flash from AWS Amplify

Erik Hanchett — Wed, 24 May 2023 15:31:28 +0000

Hello and welcome to the AWS Amplify community roundup post!

Amplify is a set of tools for frontend and mobile developers to build, ship, and host full-stack applications on AWS.

This post is meant to be a place where you can find the latest information on Amplify, AppSync - our fully managed GraphQL service, and all things frontend and mobile! We’ll be showcasing our latest tutorials, guides, conference talks and some future plans we have in place.

Why a Post?

Many internal and external teams at Amplify create great content. From our developer advocate team to marketing, docs, solution architects and our community members. This content has an amazing amount of insight that I'd like to share with all of you!

This post will help highlight that content, and hopefully help educate you on what we offer.

Feedback

If you have a minute please complete this short survey. This will really help us make this post better!

Creating SaaS Applications With AppSync and Amplify!

Have you ever imagined creating a software as a service (Saas) startup? Did you know Amplify has all the tools you need to get started? Check out this tweet from Ryan!

It’s really nice to see real people using AWS Amplify to solve their problems. I really liked how Ryan used Amplify and the AWS Free Tier with AWS Startups to get thousands of free credits!

Michael Liendo talked about this very subject recently during the AWS Developer Innovation Day!

Build a full-stack, fully typed app with GraphQL and AWS AppSync (fast forward to 01:26:50)

Make sure you watch some of the other talks too, you’ll get a good idea of many of the innovations that AWS provides.

He also open source his contributions so you can take a look at his code on Github!

MicroSaas Backend

Building Modern Apps With Amplify

The non-stop innovations in the web space amazes me. Every month there is a new library or framework that I must try out! Here at AWS we want to meet developers where their at. We want you to build on modern tooling and frameworks and not worry about the infrastructure. Here are some tutorials and guides that follow these principles.

Astro, SolidJS and Data With Amplify

Have you tried out Astro or SolidJS? Christian Nwamba recently published two excellent tutorials on how to deploy a SolidJS and Astro Blog to Amplify hosting!

Deploy a SolidJS App With AWS Amplify

and

Deploy an Astro Blog With AWS Amplify

Christian also created an excellent video on how to work with data APIs, and how to get the correct types from the backend to the frontend using AWS AppSync.

Better Developer Experience When Working With Data APIs

Sign In With Google With Amplify Authenticator

A very common use case that we often see in modern web development is logging in with Google. This allows customers with a Google account to login with a few clicks.

Amplify supports this feature, and in the following shorts Erik Hanchett shows how you can add this to your website in minutes!

Add A Sign In With Google To Your Website Part 1

Add A Sign In With Google To Your Website Part 2

Erik has also been busy live streaming building a full-stack app! He’s been using a modern stack including, Amplify services, Next.js, AppSync, lambdas and more! You can find him live streaming weekly on his YouTube channel on Fridays, or you can watch his last two videos on demand!

Building a full-stack app with Authenticator Live streamed April 6

Building a full-stack app with Authenticator Live streamed April 14

Flutter and Cross Platform Development

Did you know we have a Flutter library that works directly with Amplify services? And we just recently updated our docs site with instructions on how to create a budget tracking app?

In this video Muhammed Salih Güler talks about cross platform development, how how the Amplify Flutter library works!

CB Community Flutter

Salih has also been busy live streaming! Check out his last live stream on using the Flame Engine with Flutter!

Flame Engine Live Stream Livestream April 6

Storage Manager and Liveness

In April we launched our new Storage Manger UI and Face Liveness components!

The Liveness component helps deter fraud by using our Amazon Rekognition service. You may want to use a service like this for an ID verification system or for fraud detection. This is built into our React, Flutter, Android and Swift libraries.

The Amplify UI StorageManger has been released for general availability! This file uploader makes it straight forward to upload files directly to S3, with only a few lines of boilerplate code!

Where in the World is Amplify ✈️ ?

The developer advocate team has been busy traveling!

Muhammed Salih Güler will be giving a talk on June 2 at Flutter Connection in Paris! Stop on by and find Salih so you can learn about Amplify and Flutter! He'll also be at the AWS Summit in Amsterdam on June 1st and Flutter Berlin on June 7th.

From May 31 - June 2, Michael Liendo and Erik Hanchett are giving talks at RenderATL in Atlanta! Amplify will be sponsoring the conference so please look for our AWS booth and say hi if you’re at the conference

Erik will also be giving a talk on May 24 - 26 - at VueConf US 2023 in New Orleans! Erik will have some stickers on him, so feel free to stop him and grab some.

If you’re a part of the community builders program with AWS, you can also here Michael Liendo give a talk on MicroSaaS architecture on May 24th! We are always looking for more community developers so feel free to signup and you might be chosen!

Thanks

As you can see we’ve had a busy few months! What content would you like to see? Leave a comment or tweet me at @ErikCH! Thanks

5 New Features For Amplify UI and Studio You Should Try Today

Erik Hanchett — Wed, 22 Feb 2023 20:19:23 +0000

For the last two years I've been working as a front-end engineer on the AWS Amplify UI team. On that team I saw the creation of the Authenticator component for Vue, React and Angular. We created a components library for React and a complete theming system as well. It was a very busy two years!

At the end of last year we launched several new exciting features! In this post I'll be going over each new feature we've recently launched, and how it can benefit you.

Please, follow me on Twitter at ErikCH for more updates on new Amplify features and if you have any questions!

If you're new to Amplify and stumbled on the blog post, welcome! Feel free to check out my last post on Getting Started with Auth!

As of this writing the Account Settings, File Uploader, and React Native Authenticator features are all in developer preview.

1. Account Settings

The Account Settings connected component adds a straight forward way to change settings for users. For the preview launch we targeted deleting users and changing passwords for logged in users.

Imagine a user is signed in and wants to delete their account. The Account Settings component can be added into any page to add this functionality in.

import React from 'react';
import { AccountSettings } from '@aws-amplify/ui-react';

function App() {
  const handleSuccess = () => {
    alert('user has been successfully deleted')
  }

  return (
    <AccountSettings.DeleteUser onSuccess={handleSuccess} />
  );
}

Another common scenario is for users to change their account password, after signing in. The change password component can be added in with a few lines of code.

import React from 'react';
import { AccountSettings } from '@aws-amplify/ui-react';

function App() {
  const handleSuccess = () => {
    alert('password is successfully changed!')
  }

  return (
    <AccountSettings.ChangePassword onSuccess={handleSuccess}/>
  );
}

Each of these components can be completly overriden and customized.

2. File Uploader

Uploading files to S3 has never been more straight forward than with the File Uploader connected component. This component adds a way to upload files to S3 by drag-and-drop or by clicking the Browse files button.

import { FileUploader } from '@aws-amplify/ui-react'; 

import '@aws-amplify/ui-react/styles.css'

export const DefaultFileUploaderExample = () => {
  return (

    <FileUploader
      acceptedFileTypes={['image/*']}
      accessLevel="public"
    />

  );
};

A file preview window will appear after a file is selected to allow for renaming, adding or removing files if needed.

As with many of our other connected components, we have included an extensive API that includes many ways to customize the File Uploader experience including limits on max number of files, max size, resuming of files, displaying image preview, and a lot more!

3. React Native Support For Authenticator

The Authenticator component adds a complete authentication flow to your application with minimal boilerplate. What that means is you can add the Authenticator to your application, and get a sign in, sign up, and federated identities all with a few lines of code!

This component is now in developer preview for React Native. Like our other implementations of the Authenticator for web, we have included in React Native the same rich set of API configurations and settings. This includes changing sign up attributes, login mechanisms, and headless usage with sub component overrides! Sub component overrides just means that you can override any component inside the Authenticator to customize it to your liking.

import React from 'react';
import { Button } from 'react-native';

import { Amplify } from 'aws-amplify';
import {
  useAuthenticator,
  withAuthenticator,
} from '@aws-amplify/ui-react-native';

import awsconfig from './aws-exports';
Amplify.configure(awsconfig);

function SignOutButton() {
  const { signOut } = useAuthenticator();
  return <Button onPress={signOut} title="Sign Out" />;
}

function App() {
  return <SignOutButton />;
}

export default withAuthenticator(App);

4. Form Builder

A common use case in web development is creating forms and connecting those forms to backend data sources. The Amplify Studio's Form Builder makes this chore a snap.

With Form Builder you can connect any data model, any JSON object, or create forms from scratch using our visual builder.

Let's imagine you want to create a form with a JSON object. You can paste the object into the builder and it will generate the form.

{
  "basics": {
    "firstName": "Wesley",
    "emailAddress": "wpeck@amazon.com"
  },
  "favoriteThings": {
    "animals": ["Cats", "Snakes", "Quokka"],
    "month": "December",
    "number": 17
  },
  "active": true,
  "enabled": false
}

You can then download the form into your project, by using the Amplify Pull command. We auto generate all the code for you using our Amplify UI Components library. You can then connect this form anywhere you want in your application.

5. Data Management

Inside Amplify Studio, we added a new Data Management view. This gives you a tabular view of the backend data for an application.

This can be used by technical and non-technical team members the abality to create and update an applications data in real-time instead of building admin views.

I find this feature particularly helpful to seed my database for testing purposes, which is another feature of the Data Management view.

Bonus

One of our biggest launches recently is the addition of Next 12, 13 with SSR and ISR support for Amplify Hosting.

We now support API routes, middleware, and image optimization! We've also improved hosting with faster builds, Amazon Cloudwatch integration with a better fully managed hosting infrastructure.

Conclusion

We've been working hard on adding more features that you want! If you have an idea for a feature or a bug that needs fixing, add an issue.

Add Auth To Your Nuxt 3 App in Minutes With Amplify

Erik Hanchett — Fri, 03 Feb 2023 23:19:42 +0000

Nuxt is an intuitive framework that takes your Vue applications and brings it to a new level! It can take your Vue 2/3 app and add static site generation, and server side rendering! In addition, it supports API routes, file system routing, data fetching and more!

Amplify, on the other hand, is a set of tools that allows full-stack web and mobile developers the ability to create and build apps using AWS services.

With these two together you can build some really powerful apps!

Want to get started now? Check out my video and jump on in!

What Are We Building?

Today we are building a Nuxt 3 application with authentication backed by Amplify!

We'll imagine that we need our entire application protected, and only authorized users can access it. We'll allow users to login and create an account!

Setup

We are going to assume you are starting a Nuxt app from scratch without any prior knowledge of Amplify. Feel free to jump to the next section if this is not the case!

Let's begin by creating a brand new app

npx nuxi init nuxt3-app

After the app is generated change directory to the newly created folder.

cd nuxt3-app

Install the aws-amplify and @aws-amplify/ui-vue dependencies.

npm i @aws-amplify/ui-vue aws-amplify

If this is the first time using Amplify you'll need to install the Amplify CLI. This tool will help us setup and add Amplify's services.

npm i @aws-amplify/cli

Next, we'll run configure. This will connect our CLI tool with our AWS account.

Don't have an AWS account? Sign up and get 12 months free!

amplify configure

Finally, we'll run an init command to setup our project!

amplify init

Hit enter through all the defaults and you should be ready to go!

Adding Authentication

Adding authentication to your application with Amplify only takes one command on the CLI.

amplify add auth

Make sure to follow the prompts. Choose Email and the Default configuration.

Do you want to use the default authentication and security configuration? Default configuration
Do you want to use the default authentication and security configuration? Default configuration
 Warning: you will not be able to edit these selections. 
 How do you want users to be able to sign in? Email
 Do you want to configure advanced settings? No, I am done.

Now we can push our changes to Amplify!

amplify push

Choose Y!

? Are you sure you want to continue? (Y/n) y

If you look inside your folder structure in your Nuxt app, you may notice some new folders. Don't worry, these are configuration files for Amplify, we won't need to touch them for this tutorial.

We are done with the command line for now. Let's setup the Nuxt app so it can use this new authentication resource.

Nuxt Setup

Let's jump into our nuxt.config.ts file and add some configurations for Amplify.

// nuxt.config.ts
export default defineNuxtConfig({
  alias: {
    "./runtimeConfig": "./runtimeConfig.browser"
  },
  vite: {
    define: {
      "window.global": {}
    }
  }
});

Nuxt uses vite under the covers as a build tool. These options will help Nuxt and Vite properly build.

Let's create a plugin for Amplify. This plugin file will configure Amplify and make it available throughout the app.

Create a new plugins folder in the root of the project and add a amplify.ts file to it.

import { defineNuxtPlugin } from "#app";
import { Amplify, Auth } from "aws-amplify";
import aws_exports from "../src/aws-exports";

export default defineNuxtPlugin((nuxtApp) => {
  Amplify.configure(aws_exports);

  return {
    provide: {
      auth: Auth,
    },
  };
});

The aws_exports file was generated after you ran amplify push. This file holds all the keys needed for the Amplify JavaScript library to access all the resources you created. By adding the provide you can now access auth with $auth anywhere in your app.

We are now ready to add the Authenticator to our application. This will be in our app.vue file.

<script setup lang="ts">
import { Authenticator } from "@aws-amplify/ui-vue";
import "@aws-amplify/ui-vue/styles.css";
</script>
<template>
  <div>
    <Authenticator>
      <template v-slot="{ user, signOut }">
        <h1>Hello {{ user.username }}!</h1>
        <button @click="signOut">Sign Out</button>
      </template>
    </Authenticator>
  </div>
</template>

Don't forget to add the import for styles as seen above! Otherwise your Authenticator will not render properly.

In the code example above anything between the opening and closing brackets inside the template will only appear after the user is logged in.

Test It Out!

Go ahead and start your Nuxt app

npm run dev

Congratulations! You now have created a Nuxt.js application with authentication!

Go ahead and try to create an account, and sign in. Make sure to put in a valid email address, so you can verify your account during the sign up process.

After signing in you'll see a message like this!

Conclusion

In this post we've created a new Nuxt 3 application, added in Amplify with authentication, and setup our app to use Amplify with the Authenticator connected component!

So your next question probably is, where do we go from here? Well, with Amplify setup we can now add in authenticated apis backed by Lambda, storage, and even AppSync our managed GraphQL service!

Leave a comment below on what you'd like to learn next! Or tweet me at @ErikCH with what you learned and I'll pick someone at random for a special prize!

React Signup/Login/Account Settings application With Amplify

Erik Hanchett — Mon, 16 Jan 2023 17:59:18 +0000

Hi, I’m Erik, I’m a front-end engineer on the Amplify UI team and I wanted to share with you how to create a React application with authentication. Then we’ll look at how we can add in some nice features, like deleting users and updating passwords with our new Account Settings components.

If you want to jump in right away, check out my YouTube video to get started below.

What Is Amplify?

Amplify is a set of tools that allows full-stack web and mobile developers to create and build apps. It makes using AWS services, like our Cognito identity and access management service, or our managed GraphQL service AppSync, much simpler and straightforward to use.

What Are We Building?

Imagine you need to create a dashboard application, that only logged in users are able to access. Let's say you want to add a way for users to change their password after logging in, or completely delete their account. Let's take a look at that scenario!

In this tutorial we’ll use our Amplify UI component library, with the Authenticator and Account Settings connected components to create a full stack authenticated application.

Setup

To begin we’ll create a new application. We'll use Create React App!

npx create-react-app my-auth-app

If you'd like to use Vite instead you can run the following command.

npm create vite@latest

If you are using Vite, make sure to follow these additional steps to get setup!

cd my-auth-app

Next up, let’s install a few libraries to get up and running!

npm i aws-amplify @aws-amplify/ui-react

If you don’t already have it installed, we’ll be using Amplify CLI to create our app.

If you’re familiar with Amplify CLI, you can skip this part and jump over to the init command below. You can alternately use Amplify Studio to setup your backend.

npm i -g @aws-amplify/cli

Let’s setup Amplify CLI! Run the configure command, and follow the prompts. It will make you log into your AWS console and create a user. If you need to, you can sign up for a free AWS account. This should only take a few minutes. You can click next through all the prompts to continue.

amplify configure

Let’s configure Amplify for our app. Run the init command and hit enter through the prompts.

Having a problem? Check out the official getting started guide.

amplify init

Let’s add auth, run this command next. Choose email as your login type.

amplify add auth

Let’s push the changes! Run the push command.

amplify push

Adding Authentication To Your React Application

Now that everything is setup, we can dive into code and add React!

Fire up VSCode, or your editor of choice and open the index file and add an import for aws_exports Amplify, and the styles! Then make sure to add a configure command.

The aws-exports file is generated after adding auth to your app and pushing your changes to AWS. You may also notice a amplify folder. This will have all your configuration files in it.

import { Amplify } from "aws-amplify";
import aws_exports from "./aws-exports";
import '@aws-amplify/ui-react/styles.css'

Amplify.configure(aws_exports);

Inside your App file import the Authenticator. You’ll be surrounding your application with it. We’ll render a signOut and user so the user information can be displayed and a logout button can be added.

The Button is a component from our UI component library!

import { Authenticator, Button } from '@aws-amplify/ui-react';

export default function App() {
  return (
    <Authenticator>
      {({ signOut, user }) => (
        <main>
          <h1>Hello {user.username}</h1>
          <Button onClick={signOut}>Sign out</Button>
        </main>
      )}
    </Authenticator>
  );
}

Go ahead and start your application and you’ll see a login page.

npm start

From here you can create an account using the Create Account tab and login. It will then prompt you to check your email to enter a code in. Go ahead and try it out, create a few users and after logging in, and try to log out.

Need to customize the look and feel? Check out out our customization docs.

Account Settings

The Account Settings components are currently in Developer Preview! We are working hard on finalizing it soon.

The Account Settings component allows an already logged in user to change passwords as well as deleting a user. Let’s begin to see how to change a user.

Change Password

Inside the App file in between the opening and closing brackets of the Authenticator add the AccountSettings.ChangePassword component.

We’ll also add a handleSuccess callback that will be triggered after a change password action occurs.


import React from 'react';
import { Authenticator, Button, AccountSettings } from '@aws-amplify/ui-react';

function App() {
  const handleSuccess = () => {
    alert('password is successfully changed!')
  }

  return (
  ...
    <AccountSettings.ChangePassword onSuccess={handleSuccess}/>
  ...
  );
}

After logging in you’ll see a page like this. Go ahead and change your password. You can see from the console that the password was changed.

Logout and back in again and test the functionality with your new password.

Delete User

Go back into your App file and remove the change password component. Let’s look at the AccountSettings.DeleteUser component instead. We’ll also add a handleSuccess callback that will be called as soon as the user is deleted.


import React from 'react';
import { Authenticator, Button, AccountSettings } from '@aws-amplify/ui-react';

function App() {
  const handleSuccess = () => {
    alert('user has been successfully deleted')
  }

  return (
  ...
    <AccountSettings.DeleteUser onSuccess={handleSuccess} />
  ...
  );
}

Log into one of your existing accounts and you should see this page. Go ahead and delete a user, it will log you out. Check the console and you’ll see the success message.

Customization

A powerful feature of the Account Settings component are its levels of customization. Beyond CSS and design tokens, you can override nearly every component with your own look and feel.

Let’s override the delete button. In the AccountSettings.DeleteUser component add a components prop. Inside that props you’ll create a DeleteButton object. This will override the delete button on the DeleteUser component.

function App() {
  const components = {
    DeleteButton: (props) => (
      <AccountSettings.DeleteUser.DeleteButton {...props}>Custom Delete Account Button</AccountSettings.DeleteUser.DeleteButton>
    ),
  }

  return (
  ...
    <AccountSettings.DeleteUser components={components} />
  ...
  );
}

You’ll see a page that looks like this, with the new deleted button component after logging back in!

Conclusion and Next Steps!

In this tutorial we learned how to add authentication to our React app. We’ve learned about the new Account Settings connected component and how to use it to delete, and change password.

This is just the beginning of what you can do with the Amplify. Check out our protected routes and our AppSync tutorial for some more information!

If you’ve read all the way to the bottom, leave a comment and let me know what you’d like to see next in the world of Amplify! Thanks!

Forem: Erik Hanchett

I Tried Vite+ and Replaced My Entire Frontend Toolchain

Table of Contents

What's inside Vite+

A few caveats

Getting started

Creating your first app

Important commands

Checking and linting

Formatting

Testing

Caching with vp run

Managing Node.js with vp env

Conclusion

5 Things To Avoid When Working With AI Coding Tools

No Real Feature Definition

Too Much Bad Context

Too Much in One Shot

Too Much Trust

Speed Over Maintainability

Modern Tooling

Conclusion

The hosting setup nobody talks about anymore

Table of Contents

Our Setup

Prerequisites

Step-by-step

Launching your EC2 instance

Installing nginx and Docker

Configuring AWS Systems Manager

Setting up the deploy directory and ECR

Connecting GitHub with OIDC

Adding the GitHub Action and Dockerfile

Testing the deployment

Setting up CloudFront, SSL, and nginx

Connecting your domain with Route 53

Adding cache behaviors

Production hardening

Cleanup

Wrapping up

From Chat to Specs: A Deep Dive into AI-Assisted Development with Kiro

Limitations of current AI coding assistants

Spec-driven development: Bridging design intent and implementation

1. Understand your existing codebase

2. Analyze and plan your project

3. Generate comprehensive planning documentation

4. Collaborate with AI effectively

5. Maximize coding context and efficiency

The power of spec-driven development

Catch problems before they're expensive

Stay in control of your project's direction

Iterate without losing your progress

Keep your AI focused on what matters

Enable seamless team collaboration

Build institutional knowledge

Let’s see Kiro specs in action

Step 1: Initiating your project

Step 2: Generating your project specs

Step 3: Reviewing and refining

Step 4: Informed Development

The future of development is here—and it starts in the specs

What I Learned from Vibe Coding

Setup

Building My Personal Website

Missing image

Nuxt config update

First iteration of website

Adding more updates

Testing

Conclusion

How To Create A Fullstack TypeScript App Using AWS Amplify Gen 2

What Are We Building Today?

Setup

Updating the frontend

Adding Storage

Starting the Sandbox

Update page.tsx

Trying it out

Deploy to Production

Conclusion