JS Marathon

Functional testing with Cypress

Published Mar 31, 2021

Updated Feb 14, 2023

5 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Functional testing with Cypress

When I was a junior developer, I had an important feature assigned to me. I did the implementation, wrote several unit tests, and it worked on my machine. It went through the reviews, and got merged. And the next day, when I presented my changes to the stakeholders, everything went poorly. It turned out that somebody forgot to scope their CSS, and my layout was destroyed.

That disaster couldn't have been avoided by only writing unit tests. The team's only manual tester did not have time to go through everything in the staging environment. Automated e2e tests might have caught the issues, but those tests were already slow, and adding CSS verification would have slowed them further. And we only tested the happy-paths against the full system anyways.

What is functional testing?

Functional testing is a quality assurance process and a type of black-box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input, and examining the output, and internal program structure is rarely considered. Wikipedia

Functional tests verify how parts of a system function in isolation. It tests the components, and how they interact with each other in an environment, with high-level dependencies mocked. You can test an API functionally by sending requests to its endpoints, but testing a complete UI requires a lot of stubbing.

I wrote my first functional tests not long after that incident, but those were not better than the e2e tests. For it to work, I needed to write a mock server. The goal was to run these tests in our CI pipeline, but it was not easy, and it required a large infrastructure, running a dev-server, a mock server, and a Selenium server, and the test runner requires some "metal".

How can Cypress help you?

The tests ran, and helped us develop a more stable application. But after a while, the more tests we had, the more failures we had in CI. Sadly, while the tests ran on our well-equipped developer machines, in CI, there were memory issues and the whole environment was flaky. After a while, we started to spend more and more time investigating, and trying to fix flaky test-runs than on features.

Later, I was working on another project when I heard about Cypress. Cypress is a modern testing tool. It is an all-in-one testing framework, and assertion library, with mocking and stubbing, and without Selenium. Suddenly, I was able to set up working functional tests in a CI/CD pipeline in 3 hours, and it has been running ever since.

Cypress has a lot of features, like video recording, time travel, and the devtools. It is also framework agnostic, so we don't need to rewrite our tests if we need to rewrite the application in another framework. How does it make it easier to write functional tests? We no longer need to create mock servers, Cypress handles it for us with network request stubbing.

If you would like to play around with the demo application and the Cypress tests, feel free to check out the git repository.

How to intercept network requests?

Cypress' intercept command works with all types of network requests, including the Fetch API, page loads, XMLHttpRequests, resource loads, etc. The good thing about interceptors is that they can let the request through for e2e testing, but you can also stub their responses. When you write functional tests, every request made to the API should be stubbed.

You can stub responses by using fixtures. Fixtures are static files inside the fixtures folder. Since the intercept command can work with all types of network requests, you can stub images, JSON responses, or even mp3 files.

In our example, we are going to write some functional tests on a pizza ordering page. It is a very simple webpage, written in Angular. We have a pizza-list component that fetches the list, and handles error scenarios. The template and the component look like the following:

// subscribes to the pizzaList$ observable with the async pipe. If the emitted value is null, it displays the networkError template
<ng-container *ngIf='pizzaList$ | async as pizzas; else networkError'>

// If the returned list is an empty array, that means there is no delivery, and displays a message
  <h2 data-test-id='no delivery' *ngIf='!pizzas.length'>Sorry, but we are not delivering pizzas at the moment.</h2>

// Display our pizzas
  <cat-pizza-display *ngFor='let pizza of pizzas; trackBy: trackBy'
                     [attr.data-test-id]='pizza.name'
                     [pizza]='pizza'>
  </cat-pizza-display>
</ng-container>

// When a network error occurs, display this instead of the above ng-container
<ng-template #networkError>
  <h2 data-test-id='server error' class='server-error'>Sorry, an unexpected error occurred!</h2>
</ng-template>

@Component({
  selector: 'cat-pizza-list',
  templateUrl: './pizza-list.component.html',
  styleUrls: ['./pizza-list.component.css'],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class PizzaListComponent {

  // we fetch the pizzas
  readonly pizzaList$ = this.http.get<Pizza[]>('/api/pizza/list')
    .pipe(
      // If an error occurrs, we return an observable which emits 'null'
      catchError(e => {
        console.error(e);
        return of(null);
      })
    );

  constructor(private http: HttpClient) { }

  // ...
}

We have several scenarios to test:

When there is no delivery, the Sorry, but we are not delivering pizzas at the moment. message is displayed
When there is a delivery, the pizzas are displayed
When any kind of network error occurs, Sorry, an unexpected error occurred!

No delivery

Let's start with the no-delivery message test. We need to intercept the /api/pizza/list call and return an empty array as its body. Then we have to retrieve the message container by its data-test-id property, and assert that it exists in the DOM, is visible, and contains the above-mentioned message.

describe(`Pizzas page`, () => {
  describe(`When there is an empty pizza list response`, () => {
    beforeEach(() => {
      // We intercept the request, and we return an empty array as the body
      cy.intercept('GET', '/api/pizza/list', { body: [] }).as('emptyList');
      cy.visit('/pizza');
      // As a good practice, we wait for the response to arrive to avoid flaky tests.
      cy.wait('@emptyList');
    });

    it(`a message should be displayed`, () => {
      // We select the 'no delivery' text by its defined data-test-id property
      cy.get(`[data-test-id="no delivery"]`)
        .should('exist')
        .and('be.visible')
        .and('contain', 'Sorry, but we are not delivering pizzas at the moment.');
      });
  });
});

With pizzas present

Now, what happens when we do want to interact with pizzas? First, we have to add a pizzas.json file to our /fixtures folder, and use that as a static response. When the test is properly set up, we can interact with the displayed pizzas. Please note that cy.intercept() calls cannot be overridden. Therefore, separating our test cases into separate describe-blocks is essential.

Let's start with our pizzas.json file:

[
  {
    "id": 1,
    "name": "Margherita",
    "price": 1290,
    "imageUrl": "/api/pizza/images/1.jpg",
    "description": "Tomato sauce, mozzarella, basil"
  }
]

Then, we continue with our test:

describe(`Pizzas page`, () => {
  describe(`when there is a proper pizza list response`, () => {
    beforeEach(() => {
      // We intercept the request, and we return with the above defined .json file
      cy.intercept('GET', '/api/pizza/list', { fixture: 'pizzas.json' }).as('pizzas');
      cy.visit('/pizza');
      // We wait for the response
      cy.wait('@pizzas');
    });

    it(`should display the Margherita pizza`, () => {
      cy.get(`[data-test-id="Margherita"]`) // we retrieve our mocked pizza
        .should('be.visible')               // we assert it is visible 
        .find(`img`)                        // we look for the image
        .should('exist')                    // the image should be in the DOM
        .and('be.visible')                  // and it should be visible
        // and have the attribute we've specified in our json file.
        .and('have.attr', 'src', '/api/pizza/images/1.jpg');
    });
  });
});

But this test fails. The image while existing in the DOM, it is not visible. If we check our imageUrl property more closely, it is an API call as well, and we didn't stub it. So let's add an image to our fixtures folder, and fix our beforeEach hook.

// ...
    beforeEach(() => {
      // We intercept the request, and we return with the above defined .json file
      cy.intercept('GET', '/api/pizza/list', { fixture: 'pizzas.json' }).as('pizzas');
      // We also intercept all requests for pizza images, and return our pizza.jpg
      cy.intercept('GET', '/api/pizza/images/*.jpg', { fixture: 'pizza.jpg' }).as('pizzaImage');
      cy.visit('/pizza');
      // We wait for the response
      cy.wait('@pizzas');
    });
// ...

Network and server errors

We want to test edge cases as well. What happens when the server is unreachable, or the request returns an unexpected error? According to our component template, the Sorry, an unexpected error occurred! message should be displayed on the page. Let's write our tests.

// ...
  describe(`when an error occurs`, () => {
    it(`as an unknown server error`, () => {
      // First we simulate a server error with our interceptor
      cy.intercept('GET', '/api/pizza/list', { statusCode: 500 }).as('serverError');
      cy.visit('/');
      cy.wait('@serverError');

      // We get the error message, and make sure it exists, visible and contains the proper text
      cy.get(`[data-test-id="server error"]`)
        .should('exist')
        .and('be.visible')
        .and('contain', 'Sorry, an unexpected error occurred!');
    });

    it(`as a network error`, () => {
      // Here we simulate a network error
      cy.intercept('GET', '/api/pizza/list', { forceNetworkError: true }).as('networkError');
      cy.visit('/');
      cy.wait('@networkError');

      // We get the error message, and make sure it exists, visible and contains the proper text
      cy.get(`[data-test-id="server error"]`)
        .should('exist')
        .and('be.visible')
        .and('contain', 'Sorry, an unexpected error occurred!');
    });
  });
// ...

Conclusion

Using Cypress' intercept feature helps us with testing our application in a controlled environment. This way, we can test its functionality and how its components communicate with each other. Cypress is also framework agnostic, you can replace the underlying implementation of your state management, and these tests will make sure that your app still works the same. You can even replace your whole application, and rewrite it in another framework if you have to.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Balázs Tápai
He is a Software Engineer with a passion for automated testing. He loves Angular on the Front-End and NestJS on the Back-End. He also uses Cypress to reduce developer anxiety before demo meetings.
@TapaiBalazs @TapaiBalazs

Learning Paths for Next.JS Developers with Ankita Kulkarni

In this video, Rob Ocel and co-hosts Tracy Lee, Adam Rackis, and Danny Thompson talk with tech educator Ankita Kulkarni about her journey from engineering leader to full-time educator. Ankita shares insights on teaching Next.js, bridging practical knowledge gaps, and helping developers tackle real-world challenges. They discuss Next.js as a React-based framework, its benefits, and the challenges it presents for beginners. Chapters - Introduction to the Podcast and Guests 00:01 - Meet Ankita Kulkarni, Tech Educator 00:26 - Ankita's Transition to Full-Time Education 01:41 - Teaching Practical Knowledge in Next.js 03:19 - Effective Methods for Teaching Next.js 05:27 - Challenges of Being a Full-Time Educator 07:48 - Balancing Broad and Specific Examples 09:54 - Embracing Mistakes as a Teaching Tool 12:13 - Pair Programming and Mentorship 14:00 - Discussion on Next.js and Framework Adoption 16:48 - Advantages and Challenges of Next.js 18:12 - Choosing the Right Framework for Your Needs 20:35 - Impact of Next.js in React Documentation 22:26 - Learning Paths for New Developers 23:24 - The Rise of Full-Stack Web Development 25:09 - Benefits of Frameworks Abstracting Complexity 26:27 - OpenNext and Deployment Flexibility 28:06 - Ankita's Excitement for New Next.js Features 30:35 - The Future of Next.js Without Vercel 32:16 - Final Thoughts and Where to Find Everyone Online 34:21 Follow Ankita Kulkarni on Social Media Twitter: https://x.com/kulkarniankita9 YouTube: https://www.youtube.com/@kulkarniankita Sponsored by This Dot: thisdot.co...

Nov 12, 2024

2 mins

NextJSJavaScript

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

How to host a full-stack JavaScript app with AWS CloudFront and Elastic Beanstalk Let's imagine that you have finished building your app. You have a Single Page Application (SPA) with a NestJS back-end. You are ready to launch, but what if your app is a hit, and you need to be prepared to serve thousands of users? You might need to scale your API horizontally, which means that to serve traffic, you need to have more instances running behind a load balancer. Serving your front-end using a CDN will also be helpful. In this article, I am going to give you steps on how to set up a scalable distribution in AWS, using S3, CloudFront and Elastic Beanstalk. The NestJS API and the simple front-end are both inside an NX monorepo The sample application For the sake of this tutorial, we have put together a very simple HTML page that tries to reach an API endpoint and a very basic API written in NestJS. The UI The UI code is very simple. There is a "HELLO" button on the UI which when clicked, tries to reach out to the /api/hello endpoint. If there is a response with status code 2xx, it puts an h1 tag with the response contents into the div with the id result. If it errors out, it puts an error message into the same div. ` The API We bootstrap the NestJS app to have the api prefix before every endpoint call. ` We bootstrap it with the AppModule which only has the AppController in it. ` And the AppController sets up two very basic endpoints. We set up a health check on the /api route and our hello endpoint on the /api/hello route. ` Hosting the front-end with S3 and CloudFront To serve the front-end through a CMS, we should first create an S3 bucket. Go to S3 in your AWS account and create a new bucket. Name your new bucket to something meaningful. For example, if this is going to be your production deployment I recommend having -prod in the name so you will be able to see at a glance, that this bucket contains your production front-end and nothing should get deleted accidentally. We go with the defaults for this bucket setting it to the us-east-1 region. Let's set up the bucket to block all public access, because we are going to allow get requests through CloudFront to these files. We don't need bucket versioning enabled, because these files will be deleted every time a new front-end version will be uploaded to this bucket. If we were to enable bucket versioning, old front-end files would be marked as deleted and kept, increasing the storage costs in the long run. Let's use server-side encryption with Amazon S3-managed keys and create the bucket. When the bucket is created, upload the front-end files to the bucket and let's go to the CloudFront service and create a distribution. As the origin domain, choose your S3 bucket. Feel free to change the name for the origin. For Origin access, choose the Origin access control settings (recommended). Create a new Control setting with the defaults. I recommend adding a description to describe this control setting. At the Web Application Firewall (WAF) settings we would recommend enabling security protections, although it has cost implications. For this tutorial, we chose not to enable WAF for this CloudFront distribution. In the Settings section, please choose the Price class that best fits you. If you have a domain and an SSL certificate you can set those up for this distribution, but you can do that later as well. As the Default root object, please provide index.html and create the distribution. When you have created the distribution, you should see a warning at the top of the page. Copy the policy and go to your S3 bucket's Permissions tab. Edit the Bucket policy and paste the policy you just copied, then save it. If you have set up a domain with your CloudFront distribution, you can open that domain and you should be able to see our front-end deployed. If you didn't set up a domain the Details section of your CloudFront distribution contains your distribution domain name. If you click on the "Hello" button on your deployed front-end, it should not be able to reach the /api/hello endpoint and should display an error message on the page. Hosting the API in Elastic Beanstalk Elastic beanstalk prerequisites For our NestJS API to run in Elastic Beanstalk, we need some additional setup. Inside the apps/api/src folder, let's create a Procfile with the contents: web: node main.js. Then open the apps/api/project.json and under the build configuration, extend the production build setup with the following (I only ) ` The above settings will make sure that when we build the API with a production configuration, it will generate a package.json and a package-lock.json near the output file main.js. To have a production-ready API, we set up a script in the package.json file of the repository. Running this will create a dist/apps/api and a dist/apps/frontend folder with the necessary files. ` After running the script, zip the production-ready api folder so we can upload it to Elastic Beanstalk later. ` Creating the Elastic Beanstalk Environment Let's open the Elastic Beanstalk service in the AWS console. And create an application. An application is a logical grouping of several environments. We usually put our development, staging and production environments under the same application name. The first time you are going to create an application you will need to create an environment as well. We are creating a Web server environment. Provide your application's name in the Application information section. You could also provide some unique tags for your convenience. In the Environment information section please provide information on your environment. Leave the Domain field blank for an autogenerated value. When setting up the platform, we are going to use the Managed Node.js platform with version 18 and with the latest platform version. Let's upload our application code, and name the version to indicate that it was built locally. This version label will be displayed on the running environment and when we set up automatic deployments we can validate if the build was successful. As a Preset, let's choose Single instance (free tier eligible) On the next screen configure your service access. For this tutorial, we only create a new service-role. You must select the aws-elasticbeanstalk-ec2-role for the EC2 instance profile. If can't select this role, you should create it in AWS IAM with the AWSElasticBeanstalkWebTier, AWSElasticBeanstalkMulticontainerDocker and the AWSElasticBeanstalkRoleWorkerTier managed permissions. The next step is to set up the VPC. For this tutorial, I chose the default VPC that is already present with my AWS account, but you can create your own VPC and customise it. In the Instance settings section, we want our API to have a public IP address, so it can be reached from the internet, and we can route to it from CloudFront. Select all the instance subnets and availability zones you want to have for your APIs. For now, we are not going to set up a database. We can set it up later in AWS RDS but in this tutorial, we would like to focus on setting up the distribution. Let's move forward Let's configure the instance traffic and scaling. This is where we are going to set up the load balancer. In this tutorial, we are keeping to the defaults, therefore, we add the EC2 instances to the default security group. In the Capacity section we set the Environment type to Load balanced. This will bring up a load balancer for this environment. Let's set it up so that if the traffic is large, AWS can spin up two other instances for us. Please select your preferred tier in the instance types section, We only set this to t3.micro For this tutorial, but you might need to use larger tiers. Configure the Scaling triggers to your needs, we are going to leave them as defaults. Set the load balancer's visibility to the public and use the same subnets that you have used before. At the Load Balancer Type section, choose Application load balancer and select Dedicated for exactly this environment. Let's set up the listeners, to support HTTPS. Add a new listener for the 443 port and connect your SSL certificate that you have set up in CloudFront as well. For the SSL policy choose something that is over TLS 1.2 and connect this port to the default process. Now let's update the default process and set up the health check endpoint. We set up our API to have the health check endpoint at the /api route. Let's modify the default process accordingly and set its port to 8080. For this tutorial, we decided not to enable log file access, but if you need it, please set it up with a separate S3 bucket. At the last step of configuring your Elastic Beanstalk environment, please set up Monitoring, CloudWatch logs and Managed platform updates to your needs. For the sake of this tutorial, we have turned most of these options off. Set up e-mail notifications to your dedicated alert e-mail and select how you would like to do your application deployments. At the end, let's configure the Environment properties. We have set the default process to occupy port 8080, therefore, we need to set up the PORT environment variable to 8080. Review your configuration and then create your environment. It might take a few minutes to set everything up. After the environment's health transitions to OK you can go to AWS EC2 / Load balancers in your web console. If you select the freshly created load balancer, you can copy the DNS name and test if it works by appending /api/hello at the end of it. Connect CloudFront to the API endpoint Let's go back to our CloudFront distribution and select the Origins tab, then create a new origin. Copy your load balancer's URL into the Origin domain field and select HTTPS only protocol if you have set up your SSL certificate previously. If you don't have an SSL certificate set up, you might use HTTP only, but please know that it is not secure and it is especially not recommended in production. We also renamed this origin to API. Leave everything else as default and create a new origin. Under the Behaviors tab, create a new behavior. Set up the path pattern as /api/* and select your newly created API origin. At the Viewer protocol policy select Redirect HTTP to HTTPS and allow all HTTP methods (GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE). For this tutorial, we have left everything else as default, but please select the Cache Policy and Origin request policy that suits you the best. Now if you visit your deployment, when you click on the HELLO button, it should no longer attach an error message to the DOM. --- Now we have a distribution that serves the front-end static files through CloudFront, leveraging caching and CDN, and we have our API behind a load balancer that can scale. But how do we deploy our front-end and back-end automatically when a release is merged to our main branch? For that we are going to leverage AWS CodeBuild and CodePipeline, but in the next blog post. Stay tuned....

Sep 11, 2023

12 mins

NestJSAWSTypeScriptNodeJS

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

In this JS Drop, Danny Thompson is joined by YouTuber Jack Herrington to explore a unique TypeScript and AI project that lets you recognize TV show characters in real time. Just point your camera at a character, and instantly get their details or even chat with them as if they were real! Jack walks through the tech, explaining how client-side face recognition and server-side AI work together to make this possible using the Versal AI library. They discuss prompt engineering, building efficient APIs, and ensuring smooth, interactive AI responses. Jack also shares potential real-world applications, from entertainment to security. Chapters - 0:32 Project Overview – Jack explains the AI-powered character recognition project - 2:17 Setting Up the Project – Overview of how the application is structured and initial setup - 3:04 Client-Side AI – How face detection and character recognition work on the client side - 5:12 Switching to Server Side – Jack demonstrates server-side AI and setting up API endpoints - 8:20 Explaining AI Tooling – How tools and prompts are used to give context to the AI - 10:01 Detailed Prompt Structure – Breaking down the prompt and character context for AI responses - 12:40 Client-Server Interaction – Using the Versal AI library to manage streaming responses - 15:09 Handling Character Data – Training the AI on specific character images and details - 18:15 Practical Use Cases – Discussing potential real-world applications for the face recognition tool - 21:34 Challenges and Lessons Learned – Jack shares obstacles he faced and how he overcame them - 25:45 Building the API – Tips and considerations for creating reliable API endpoints - 28:40 Handling User Inputs – Testing unexpected questions and how the AI responds - 32:00 Using Advanced AI Models – Jack talks about choosing GPT-4 and issues with smaller models - 35:47 Introducing ProNextJS.dev – Jack discusses his new Next.js course, covering advanced topics - 37:20 Closing Thoughts – Danny and Jack wrap up with final thoughts and a link to the GitHub repo Follow Jack Herrington on Social Media Twitter: https://x.com/jherr Linkedin: https://www.linkedin.com/in/jherr/ YouTube: https://www.youtube.com/@jherr Sponsored by This Dot: thisdot.co...

Nov 11, 2024

2 mins

AIArtificial Intelligence

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Functional testing with Cypress

Functional testing with Cypress

What is functional testing?

How can Cypress help you?

How to intercept network requests?

No delivery

With pizzas present

Network and server errors

Conclusion

Balázs Tápai

You might also like

Learning Paths for Next.JS Developers with Ankita Kulkarni

Introduction to Zod for Data Validation

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

Let's innovate together!

You might also like

Learning Paths for Next.JS Developers with Ankita Kulkarni

Introduction to Zod for Data Validation

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington