Learn Aws, Clojure and Cypress

Amazon Web Services (AWS) is a powerful expansive cloud infrastructure platform for building modern web applications.

AWS provides services for data, presentation, authentication, security, video encoding, and much more. Offering over 175 fully-featured services from data centers globally, AWS powers a large percentage of the internet.

Deploying a "static" website on AWS is surprisingly tricky - it requires managing S3, CloudFront, the security between them, and more. Luckily, we don't have to do everything ourselves - in this lesson we're going to learn how to use a 3rd party [cdk-website](https://github.com/symphoniacloud/cdk-website) construct available on npm in order to host our application on AWS.

Deploy a Site with HTTPS Support Behind a CDN with AWS CDK

When experimenting with CDK it's possible to deploy a service which is outside of free tier (since nearly all AWS services are supported) and it's useful to be able to delete an entire CDK stack if necessary.

We're going to learn how to delete an entire AWS CDK stack with CDK destroy command.

Destroy an AWS CDK Stack

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Our serverless backend and infrastructure (that we both created and deployed ourselves with CDK!) are ready so we can connect it to our React app.

We're going to learn how to connect the React app from the source code of this course to our API as well as how to add appropriate CORS headers to our API response.

Connect React App to a Serverless Backend Deployed with AWS CDK and Fix CORS Issues

Now that we have successfully created our AWS Lambda functions, it's time to expose them using an API Gateway REST API. In this lesson, we're going to learn how to create, deploy, and test an API Gateway REST API with AWS CDK.

Create an API Gateway REST API with AWS CDK

The best kind of todo is the one we already completed and we can delete it from the list 🎉

In this quick lesson, we're going to learn how to delete an item from our DynamoDB table.

Delete an Item from a DynamoDB table in AWS CDK with DELETE Operation

In this quick lesson we're going to create a createTodo AWS Lambda function which will allow us to add new items to our DynamoDB table.

Add Data to a DynamoDB Table with PUT Operation use AWS CDK

At the end of the last lesson we've managed to create a Lambda function which we want to use to get data from DynamoDB table using the scan operation.

Unfortunately, after calling the AWS Lambda function we get a following response:

```
"message": "User: arn:aws:sts::696785635119:assumed-role/TodoAppStack-TodoDatabaseTodoHandlerServiceRole991-152UNT6KUIOG2/TodoAppStack-TodoDatabaseTodoHandlerDD6198FE-CPTO6AAJJU5W is not authorized to perform: dynamodb:Scan on resource: arn:aws:dynamodb:eu-central-1:696785635119:table/TodoAppStack-TodoDatabaseTodoTable29EA4913-E6Z09XSAAHF8",
```

In this quick lesson we're going to learn how to allow an AWS Lambda function to access data from a DynamoDB table with grantReadData function (in a single line of code!)

Debug Permission Issues and Allow an AWS Lambda Function to Access Data from DynamoDB

Now we're getting somewhere 🎉

In this lesson we're going to create a new lambda function that will read data from our new TodoTable.

Get All Items from a DynamoDB Table using ScanCommand

Amazon DynamoDB is a fully managed non-relational (NoSQL) database service that provides fast and predictable performance with seamless scalability.

In other words - DynamoDB is entirely managed by AWS (so it's scaled for us, even if our startup has millions of users), it's a NoSQL database so we don't have to start by defining a detailed schema like in a relational database and it's used by companies like AirBnB, Lyft and Samsung in production.

In this quick lesson we're going to learn how to create a brand new DynamoDB table from scratch with AWS CDK.

Create a DynamoDB Table with AWS CDK

Now that we know a lot about shipping cloud resources with CDK it's time to start creating a serverless backend for our todo application.

We could add the database and new AWS Lambda functions to our main stack but after a while it might get difficult to maintain.

Instead, in this lesson we're going learn how to create our very own custom CDK construct.

Learn more about CDK constructs [here](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html).

Create a Custom AWS CDK Construct

Amazon AWS is one of the most popular cloud providers in the world, but it can also be daunting to learn thanks to the alphabet soup of service acronyms.

Once you've figured out which subset of services to use, you've got a lot of clicking around to do in order to get things configured.

Not anymore!

With the AWS Cloud Development Kit (CDK v2), you are able to configure AWS services from your terminal & editor.

Even better, you can do your configuration, frontend, and backend all with the same language.

In this course, Tomasz Łakomy will guide you through using TypeScript to complete the lifecycle of an application powered by AWS CDK v2. You'll see how to start a project, develop it locally, deploy it globally, and then tear it all down when you're done.

The services & development approach Tomasz demonstrates in this course are used by countless companies around the world.

Is yours next?

Full Stack TypeScript with AWS Cloud Development Kit v2

Serverless technologies like AWS Lambda allow us to build our applications out of small, independent functions that can be called based on events such as an API call.
By default, it's not possible to call an AWS Lambda function from the Internet - it's safely stored within AWS cloud, following the principle of least privilege.
In order to create a REST API to call an AWS Lambda function we need to use API Gateway. Luckily, with AWS CDK, we can create a LambdaRestApi in 3 lines of code and this is exactly what we're going to learn in this quick lesson!

Attach an API Gateway to an AWS Lambda Function Deployed with AWS CDK

Every resource we deploy to AWS with CDK has some default values configured for us so that we don't have to configure everything ourselves.
This comes in handy because it allows us to focus on building our infrastructure and solving our problems instead of configuring everything.
With that being said - CDK allows us to configure various properties of our resources! In this quick lesson we're going to learn how to configure the memory size and timeout of an AWS Lambda function.

Change the Properties of an AWS Lambda Function Deployed with AWS CDK

It's time to start building our serverless backend!
In this quick lesson we're going to use the `NodejsFunction` construct provided by CDK in order to build, deploy and test a 'Hello World!' AWS Lambda function.
You can find out more about what kind of constructs are available in AWS CDK construct library [here](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html)

Create and Deploy a Node.js AWS Lambda Function with AWS CDK

In this quick lesson we're going to clear out the SQS Queue and SNS Topic that was created for us when we created a CDK app with cdk init in order for us to be able to start building our app from scratch.

Clear an Initial AWS CDK Stack to Start Building an App From Scratch

Now that our initial stack has been deployed it's time to dig into AWS Console to see what exactly did we deploy.
Cloud Development Kit is built on top of CloudFormation which is an AWS service that allows you to describe a stack in AWS using a static file (either YAML or JSON).
In essence - it's going to convert our code written in TypeScript, to JavaScript, which will be then converted to CloudFormation and CloudFormation will be used to deploy our infrastructure.
Sounds complicated, right? Luckily CDK abstracts a lot of things away from us, so we get to focus on solving our problems instead of writing YAML by hand.
In this lesson we're going to learn how to review an AWS CDK stack deployment in CloudFormation console.

Review an AWS CloudFormation Stack Deployed with AWS CDK

Now that our initial AWS CDK project has been created, it's time to deploy it!
In this quick lesson we're going to learn:
where do we define an AWS CDK stack
what is a CDK construct (you can read more about CDK constructs [here](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html))
how to bootstrap a CDK environment with cdk bootstrap
how to use `cdk diff` command in order to see the difference between our currently deployed stack and the stack we're about to deploy
how to use `cdk deploy` in order to deploy a CDK stack to AWS

Build and Deploy a Sample AWS Cloud Development Kit Stack to AWS

All amazing projects have to start somewhere and AWS CDK is no exception.
In this quick lesson we're going to learn how to install AWS CDK command line interface with npm as well as how to use cdk init in order to create our very first CDK project :partying_face:

Install AWS Cloud Development Kit (CDK) and Create a New Project

Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is very easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.

Some components render differently based on the route they are rendered on. To use router within component tests, it is best to define its default values in `cy.mount()` function. Since we can customize this in any way we’d like, we can create a custom `path` attribute where we can pass our own routes and test our component behavior against them.

Test a Component Rendering Within Different Router Locations in Cypress Component Test

Every component test that uses Pinia needs to have Pinia imported and initialized. Instead of doing this separately for each test you can customize your `cy.mount()` command to automatically use a default store. You can further then customize it to use your own store in case you want to change its state.

Rewrite Cypress mount() Command to Provide a Default Store to all Components

Instead of calling an action function to change the state, we can choose to change it directly by importing the attributes from our store. In order to not loose reactivity while destructuring properties we can use `storeToRefs()` function.

Mutate Application State Properties Directly with Pinia’s storeToRefs()

Hardcoding your script to search for only one type of file (like `.md`) is a major limitation. This lesson shows you how to make your script smarter by teaching it to infer the desired file type directly from the user's natural language prompt.

You'll implement a two-stage AI process. The first stage analyzes the user's request to determine the file extension they're interested in (e.g., `md`, `txt`). The second stage then uses that file type to dynamically search the file system, find the relevant files, and execute the command.

**Workflow demonstrated in this lesson:**

* Add a preliminary `generateObject` call to extract a `fileType` from the user's initial prompt.
* Define a list of supported `fileTypes` (e.g., `['md', 'txt']`) and use a detailed prompt to guide the AI, instructing it to choose from the list or use a default.
* Dynamically construct the `globby` pattern using the inferred `fileType` (e.g., `*.$[fileType]`).
* Implement error handling to inform the user if they request an unsupported file type or if no files of the specified type are found.
* Demonstrate how the script defaults to searching for Markdown files but can correctly search for other types when specified (e.g., "summarize my profile from my pdf").

This technique adds a significant layer of intelligence to your script, allowing it to adapt its behavior based on the user's intent and making it a far more flexible and intuitive command-line tool.

John Lindquist

Dynamically Inferring File Types from User Prompts in Local AI Scripts

Hardcoding command logic and prompts directly into your script makes it rigid and difficult to extend. This lesson demonstrates a more flexible and powerful pattern: defining your script's commands as individual Markdown files in a dedicated directory.

This approach allows you to easily add, remove, or modify commands without touching the core script logic. You'll learn how to dynamically load these command files, present them as options to the AI, and inject the corresponding instructions into your prompt, creating a truly modular and extensible tool.

**Workflow demonstrated in this lesson:**

* Create a `commands` directory to house your command definitions (e.g., `summarize.md`, `translate.md`).
* In each file, write the specific prompt or instructions for that command.
* Use `globby` to discover all available command files at runtime.
* Create a `commandMap` that maps the filename (e.g., "summarize") to its file content.
* Update the Zod schema to use an `enum` of the dynamically discovered command names.
* Dynamically construct the final text generation prompt by injecting the instructions from the user-selected command file.
* Add a `profile.md` file to demonstrate how the script can act on user-created content with the new file-based commands.

By the end of this lesson, your script will be architected for easy expansion, allowing you to build a robust library of custom commands simply by adding new text files.

Creating Dynamic, File-Based Commands for Local AI Scripts

AI models won't always give you the answer you expect; sometimes they'll return invalid data or "hallucinate" a response that doesn't fit your schema. This lesson teaches you how to make your local AI script more robust by implementing essential error handling for user commands.

You'll learn how to validate the AI's output against a predefined list of valid commands and gracefully catch errors when the model generates an unexpected response, ensuring your script fails predictably and provides helpful feedback to the user.

**Workflow demonstrated in this lesson:**

* Define a list of `validCommands` (e.g., `summarize`, `translate`, `review`) to constrain the AI's choices.
* Wrap the `generateObject` call in a `try...catch` block to handle cases where the AI's output doesn't match the Zod schema.
* Implement a type guard function (`isValidCommand`) to check if the command returned by the AI is in your list of valid commands.
* Provide clear error messages to the user, indicating what went wrong and what the valid commands are.
* Test the script with invalid commands (like "taco" or "delete") to confirm that the error handling works as expected.

By adding these checks, you make your script significantly more reliable and user-friendly, preventing it from crashing on bad input and guiding the user toward correct usage.

Handling Invalid Commands and AI Errors in Local Scripts

Once your script can understand a user's command and identify a target file, the next step is to perform an action. This lesson shows you how to use the Vercel AI SDK's `generateText` function to process a file's content and produce a relevant, AI-generated response.

You'll learn how to read the content from the file path you've already identified, combine it with the inferred command into a new, more detailed prompt, and then pass it back to your local AI model to generate a final text output, such as a summary or a review.

**Workflow demonstrated in this lesson:**

* Import the `generateText` function from the `ai` SDK.
* Read the file content from the `filePath` returned by `generateObject`.
* Construct a new, structured prompt that includes the original command (e.g., "summarize") and the full content of the file.
* Pass this new prompt to the `generateText` function.
* Log the resulting AI-generated text to the console.
* Run the script with commands like "Summarize our TypeScript config" or "Review my package file" to see the full, context-aware output.

This lesson completes the core cycle of your AI script: understanding a command, reading the relevant context, and generating a useful, text-based result, all on your local machine.

Generating Text with a Local AI Model Based on File Content

A command is useless without knowing what to act upon. This lesson elevates your local AI script by giving it context from your project's file system. You'll learn how to find all relevant files and empower the AI to intelligently select the correct one based on your prompt.

The core technique involves using the `globby` package to scan for files and then feeding that list into a Zod `enum`. This constrains the AI's choices to a valid set of files, allowing it to accurately determine which file you're referring to in a natural language command.

**Workflow demonstrated in this lesson:**

* Install and import the `globby` library to find files based on a pattern (e.g., all `.json` files).
* Add a `filePath` field to your Zod schema.
* Define the `filePath` as `z.enum(files)`, where `files` is the array of file paths returned by `globby`.
* Pass a natural language prompt like "Summarize our typescript config" to the script.
* Observe how the AI correctly identifies `tsconfig.json` from the list of available JSON files and returns it as structured data.

This lesson is a crucial step toward building powerful, context-aware tools that can intelligently interact with your project's files based on simple, human-readable commands.

Providing File System Context to Local AI Scripts with Globby and Zod Enums

Hardcoded prompts are great for testing, but a truly useful script needs to respond to dynamic user input. This lesson shows you how to make your local AI script interactive by capturing command-line arguments.

You'll learn how to use Node.js's built-in `parseArgs` utility to take a user's natural language command directly from the terminal and pass it to your local language model for processing.

**Workflow demonstrated in this lesson:**

* Import the `parseArgs` function from the `node:util` module.
* Configure `parseArgs` to accept positional arguments from the command line.
* Replace the static, hardcoded prompt with the dynamic input provided by the user.
* Run the script with different sentences (e.g., `"Download a file"` or `"I want to download a file"`) to demonstrate that the AI can correctly infer the core command regardless of the phrasing.

By the end of this short lesson, your script will be able to accept and process commands directly from the user, making it a flexible and reusable command-line tool.

Processing Dynamic User Input in Local AI Scripts

While command-line chats with local AI models are useful, the real power comes from scripting. This lesson walks you through the initial setup for creating powerful, local AI-driven scripts by combining Ollama, the Vercel AI SDK, and Zod.

You'll learn how to take a natural language command, like "Concatenate all of the markdown files in my Downloads folder into a single file," and use the `generateObject` function to intelligently extract structured, actionable data from it.

**Workflow demonstrated in this lesson:**

* Install and set up the `ollama-ai-provider`, `ai`, and `zod` packages.
* Create a local AI model instance using Ollama and the Gemma 3 model.
* Define a Zod schema to specify the exact data structure you want to extract (e.g., `{ command: string }`).
* Use `generateObject` to pass a natural language prompt to the local model and receive a structured JSON object that matches your schema.
* Run the script using `bun` to see the local model successfully infer the "concatenate" command from a full sentence.

This foundational lesson unlocks the ability to build sophisticated, automated workflows by translating human language into machine-readable commands, all running entirely on your local machine.

Scripting Local Language Models with Ollama and the Vercel AI SDK

### **Build Powerful, Local AI-Driven Command-Line Scripts**

Go beyond simple AI chats and unlock the true potential of local language models by learning to script them. This course will guide you step-by-step through the process of building a flexible and intelligent command-line tool that can understand natural language, interact with your file system, and automate complex tasks—all running entirely on your local machine.

Starting with a blank TypeScript file, you'll learn how to combine the power of **Ollama**, the **Vercel AI SDK**, and **Zod** to create a script that's not just functional, but smart. We'll begin by teaching the AI to parse a simple command from a sentence. From there, we'll progressively add layers of sophistication: processing dynamic user input, making the script aware of your project's files, and generating meaningful text-based output.

You'll also learn critical patterns for building robust and extensible tools. We'll cover how to handle invalid commands and unexpected AI responses gracefully. Then, you'll refactor the script to use a modular, file-based system for its commands, allowing you to easily add new functionality without touching the core logic. Finally, we'll add a layer of intelligence that allows your script to infer exactly what you mean, right down to the type of file you want it to process.

By the end of this course, you will have built a powerful, personalized AI assistant and gained the foundational skills to create sophisticated local automations for any task you can imagine.

**What You'll Learn:**

* How to script local language models using Ollama and the Vercel AI SDK.
* To parse and process dynamic user input from the command line.
* To use Zod schemas, including `enums`, to validate and structure AI model output.
* Techniques for providing file-system context to your scripts with `globby`.
* How to generate context-aware text based on file content.
* Robust error handling for invalid user commands and unexpected AI responses.
* To build a modular and extensible tool by defining commands in separate files.
* To intelligently infer user intent, such as dynamically determining file types from a prompt.

Build a local AI-powered command-line assistant from scratch. Learn to use Ollama, Vercel AI SDK & Zod to parse input, automate tasks, and run scripts offline.

This lesson demonstrates how to give Cursor direct access to your terminal output using the [Nx MCP extension](https://nx.dev/getting-started/ai-integration?utm_source=youtube&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI), enabling automatic error detection and fixing in monorepo projects.

**Workflow demonstrated in this lesson:**

- Encounter a runtime error when serving a Vite application in an Nx monorepo
- Install and configure the Nx Console extension with MCP integration
- Ask Cursor to check your terminal for errors and fix the underlying issues
- Watch as the AI accesses running task details and terminal output through Nx MCP tools
- Observe how it analyzes workspace relationships to identify incorrect imports and missing dependencies

**Key benefits:**

- Seamless Error Handling: AI gains direct access to terminal output and running task information
- Automatic Diagnosis: Accurately identify the root cause of errors without manual copying
- Context-Aware Fixes: Leverage workspace knowledge to implement proper solutions
- Reduced Context Switching: Eliminate the need to manually relay information between terminal and AI



Juri Strumpflohner

Enable Cursor to directly access the terminal to read the output and fix issues

See how Nx MCP gives AI coding assistants direct access to terminal output and running tasks, enabling automatic error detection and fixing.

This lesson demonstrates how to solve the predictability problem when using AI to generate code in monorepos by combining Cursor with Nx generators.

**Workflow demonstrated in this lesson:**

- Explore how Nx generators provide predictable scaffolding for new libraries
- Set up [Nx Console with MCP](https://nx.dev/features/enhance-AI?utm_source=egghead&utm_medium=videos&utm_campaign=Nx-AI&utm_id=Nx-AI) integration to expose generator capabilities to Cursor
- Use the AI assistant to brainstorm a new feature with the help of the Nx MCP tools
- Have Cursor leverage the Nx MCP tools to trigger the appropriate Nx generator for creating a React-based feature library
- Observe how the AI assistant takes the generated library and further integrates it into the codebase

**Key benefits:**

- **Predictable Code Structure**: Ensure generated libraries follow your project's and organization's conventions
- **Consistent Setup**: Maintain uniform configuration across TypeScript projects and package.json files
- **Guided Implementation**: Combine AI instructions with structured, predictable code generation

Enable Cursor to generate predictable project setups

Learn how to combine Cursor AI with Nx generators for predictable library creation in monorepos, ensuring consistent structure across your codebase.

Search

Search Results