PWA

Introducing @this-dot/rxidb

Published Oct 13, 2022

Updated Feb 13, 2023

6 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.

When we are working on PWAs (Progressive Web Applications), we sometimes need to implement features that require us to store data on our user's machine. One way to do that is to use IndexedDb. Using the IndexedDb browser API has its challenges, so our team at This Dot has developed an RxJS wrapper library around it. With @this-dot/rxidb, one can set up reactive database connections and manipulate its contents the RxJS way. It also provides the ability to subscribe to changes in the database and update our UIs accordingly.

In this blog post, I'd like to show you some small examples of the library in action. If you'd like to see the finished examples, please check out the following links:

You can also check our OSS repository for more examples.

Storing data in chronological order

Imagine that you are working on a special text editor app, or something that needs to keep data between page reloads. These kinds of apps usually need to track larger amounts of data. It would be a bad practice to use localStorage for that. In the following example, we will focus on how to store and delete rows in an Object Store that has autoIncrement enabled. For the sake of simplicity, every time the user presses the Add Item button, a timestamp of the event will be stored in the database.

We would also like to be able to remove items from the beginning and the end of this store. We will add two buttons to our UI to deal with that, and we would like them to be disabled if there are no entries in the store. We have a starter HTML that looks like the following:

<h1>@this-dot/rxidb autoincrement example</h1>
<br>
<button id="add-item-btn"> Add item </button>
<button id="remove-first-item-btn"> Remove first item </button>
<button id="remove-last-item-btn"> Remove last item </button>

<hr>
<div id="container"></div>

Initiating the Database

For us to be able to store data in IndexedDb, we need a database connection and an Object Store set up. We want this Object Store to automatically increment, so we don't need to manually keep track of the last key. We do want to listen to every update that happens in the database, so let's set up our listeners for the keys and the key-value pairs using the entries() and the keys() operators.

import {
  addItem,
  connectIndexedDb,
  deleteItem,
  entries,
  getObjectStore,
  keys,
} from '@this-dot/rxidb';

// ...

const DATABASE_NAME = 'AUTO_INCREMENT';

const store$ = connectIndexedDb(DATABASE_NAME).pipe(
  getObjectStore('store', { autoIncrement: true })
);

const keyValues$: Observable<{ key: IDBValidKey; value: unknown }[]> =
  store$.pipe(entries());
const keys$: Observable<IDBValidKey[]> = store$.pipe(keys());

We want to display the contents of the database when they get updated in the #container div. For that, we need to subscribe to our keyValues$ observable. Whenever it emits, we want to update our div.

const containerDiv: HTMLElement = document.getElementById(`container`);

// ...

keyValues$.subscribe((entries) => {
  const content = entries
    .map(({ key, value }) => `<div>${key} | ${value} </div>`)
    .join('\n<br>\n');
  containerDiv.innerHTML = content;
});

Manipulating the data

We have three buttons on our UI. One for adding data to the Object Store, and two for removing data from it. Let's set up our event emitters, using the fromEvent observable creator function from RxJS.

const removeFirstBtn: HTMLElement = document.getElementById(
  'remove-first-item-btn'
);
const removeLastBtn: HTMLElement = document.getElementById(
  'remove-last-item-btn'
);
const addItemBtn: HTMLElement = document.getElementById('add-item-btn');

const addItemBtnClick$ = fromEvent(addItemBtn, 'click');
const removeFirstItemBtnClick$ = fromEvent(removeFirstBtn, 'click');
const removeLastItemBtnClick$ = fromEvent(removeLastBtn, 'click');

We can use the addItem operator to add rows to an automatically incrementing Ojbect Store. When the Add Item button gets clicked, we want to save a timestamp into our database.

addItemBtnClick$
  .pipe(
    map(() => new Date().getTime()),
    switchMap((timestamp) => store$.pipe(addItem(timestamp)))
  )
  .subscribe();

Removing elements from the database will happen on the other two button clicks. We need the keys$ observable so we can delete the first or the last items in the store.

removeFirstItemBtnClick$
  .pipe(
    withLatestFrom(keys$),
    switchMap(([, keys]) =>
      store$.pipe(
        filter(() => !!keys.length),
        deleteItem(keys[0])
      )
    )
  )
  .subscribe();

removeLastItemBtnClick$
  .pipe(
    withLatestFrom(keys$),
    switchMap(([, keys]) =>
      store$.pipe(
        filter(() => !!keys.length),
        deleteItem(keys[keys.length - 1])
      )
    )
  )
  .subscribe();

Toggling button states

The last feature we want to implement is toggling the remove buttons' disabled state. If there are no entries in the database we disable the buttons. If there are entries, we enable them. We can easily listen to the keyValues$ with the tap operator.

const keyValues$: Observable<{ key: IDBValidKey; value: unknown }[]> =
  store$.pipe(
    entries(),
    tap(toggleRemoveButtons)
  );

// ...

function toggleRemoveButtons(
  keys: { key: IDBValidKey; value: unknown }[]
): void {
  if (keys.length) {
    removeFirstBtn.removeAttribute('disabled');
    removeLastBtn.removeAttribute('disabled');
  } else {
    removeFirstBtn.setAttribute('disabled', 'true');
    removeLastBtn.setAttribute('disabled', 'true');
  }
}

Real-world use cases for autoIncrement Object Stores

An automatically incrementing object store could be useful when your app needs to support offline mode, but you also need to log certain events happening on the UI to an API endpoint. Such audit logs must be stored locally and sent when the device comes online the next time. When the device goes offline, every outgoing request to our logging endpoint can instead put the data into this Object Store, and when the device comes online, we just read the events and send them with their timestamps.

Storing objects

Have you ever needed to fill out an extremely long form online? Maybe even that form was part of a wizard? It is a very bad user experience when you accidentally refresh or close the tab, and you need to start over. Of course, it could be implemented to store the unfinished form in a database somehow, but that would mean storing people's sensitive PII (Personal Identifiable Information) data. IndexedDb can help here as well because it stores that data on the user's machine.

In the following example, we are going to focus on how to store data in specific keys. For the sake of simplicity, we set up some listeners and automatically save the information entered into the form. We will also have two buttons, one for clearing the form, and the other for submitting. Our HTML template looks like the following:

<div id="app">
  <h1>@this-dot/rxidb key-value pair store example</h1>

  <hr />

  <h2>Address form</h2>
  <form id="example-form" method="POST">
    <label for="first-name">First Name:</label>
    <br />
    <input id="first-name" required placeholder="John" />
    <br />
    <br />
    <label for="last-name">Last Name:</label>
    <br />
    <input id="last-name" required placeholder="Doe" />
    <br />
    <br />
    <label for="city">City:</label>
    <br />
    <input id="city" required placeholder="Metropolis" />
    <br />
    <br />
    <label for="address-first">Address line 1:</label>
    <br />
    <input id="address-first" required placeholder="Example street 1" />
    <br />
    <br />
    <label for="address-second">Address line 2 (optional):</label>
    <br />
    <input id="address-second" placeholder="4th floor; 13th door" />
    <br />
    <br />
    <div style="display: flex; justify-content: space-between; width: 153px">
      <button id="clear-button" type="button">Clear form</button>
      <button id="submit-button" type="submit" disabled>Submit</button>
    </div>
  </form>
</div>

Based on the above template, we do have a shape of how the object that we would like to store would look like. Let's set up a type for that, and some default constants.

type UserFormValue = {
  firstName: string;
  lastName: string;
  city: string;
  addressFirst: string;
  addressSecond: string;
};

const EMPTY_FORM_VALUE: UserFormValue = {
  firstName: '',
  lastName: '',
  city: '',
  addressFirst: '',
  addressSecond: '',
};

Set up the Object Store and the event listeners

Setting up the database is done similarly as in the previous example. We open a connection to the IndexedDb and then create a store. But this time, we just create a default store. This way, we have full control over the keys. With this form, we want to write the value of the USER_INFO key in this Object Store. We also want to get notified when this value changes, so we set up the suerInfo$ observable using the read() operator.

import {
  connectIndexedDb,
  deleteItem,
  setItem,
  read,
  getObjectStore,
} from '@this-dot/rxidb';
// ...

const DATABASE_NAME = 'KEY_VALUE_PAIRS';
const FORM_DATA_KEY = 'USER_INFO';

const store$ = connectIndexedDb(DATABASE_NAME).pipe(getObjectStore('store'));
const userInfo$: Observable<UserFormValue | null> = store$.pipe(
  read(FORM_DATA_KEY)
);

To be able to write values into our Object Store and update the data on our UI, we need some HTML elements. We set up constants that point towards our form, the two buttons, and all of the inputs inside the form.

const exampleForm = document.getElementById('example-form') as HTMLFormElement;
const submitButton = document.getElementById(
  'submit-button'
) as HTMLButtonElement;
const clearButton = document.getElementById(
  'clear-button'
) as HTMLButtonElement;

const firstNameInput = document.getElementById(
  'first-name'
) as HTMLInputElement;
const lastNameInput = document.getElementById('last-name') as HTMLInputElement;
const cityInput = document.getElementById('city') as HTMLInputElement;
const addressFirstInput = document.getElementById(
  'address-first'
) as HTMLInputElement;
const addressSecondInput = document.getElementById(
  'address-second'
) as HTMLInputElement;

And finally, we set up some event listener Observables to be able to act when an event occurs. Again, we use the fromEvent creator function from rxjs.

const formInputChange$ = fromEvent(exampleForm, 'input');
const formSubmit$ = fromEvent(exampleForm, 'submit');
const clearForm$ = fromEvent(clearButton, 'click');

Set up some helper methods

Before we set up our subscriptions, let's think through what behaviour we want with this form and the buttons.

It is certain that we need a way to get the current value of the form that matches the UserFormValue type. We also want to set the input fields of the form, especially when we reload the page and there is data saved in our Object Store. If there is no value provided to this setter method, it should use our predefined EMPTY_FORM_VALUE constant.

function getUserFormValue(): UserFormValue {
  return {
    firstName: firstNameInput.value,
    lastName: lastNameInput.value,
    city: cityInput.value,
    addressFirst: addressFirstInput.value,
    addressSecond: addressSecondInput.value,
  };
}

function setInputFieldValues(value: UserFormValue = EMPTY_FORM_VALUE): void {
  firstNameInput.value = value.firstName || '';
  lastNameInput.value = value.lastName || '';
  cityInput.value = value.city || '';
  addressFirstInput.value = value.addressFirst || '';
  addressSecondInput.value = value.addressSecond || '';
}

The UI should block the user from certain interactions. The submit button should be disabled while the form is invalid, and while a database write operation is still in progress. For handling the submit button state, we need two helper methods.

function disableSubmitButton(): void {
  submitButton.setAttribute('disabled', 'true');
}

function removeSubmitButtonDisabledIfFormIsValid(): void {
  const isFormValid = exampleForm.checkValidity();
  if (isFormValid) {
    submitButton.removeAttribute('disabled');
  }
}

Now we have every tool that we need to implement the logic.

Setting up our subscriptions

We would like to write the form data into the Object Store as soon as the form changes, but we don't want to start such operations on every change. To mitigate this, we are going to use the debounceTime(1000) operator, so it waits for 1 second before starting the write operation. We use our getUSerFormValue() helper method to get the actual data from the input fields and we use the setItem() method on the store$ observable, inside a switchMap operator to write the values. We also want to disable the Submit button when the form changes and re-enable it if the form is valid and the write operation is finished.

formInputChange$
  .pipe(
    tap(() => disableSubmitButton()),
    debounceTime(1000),
    map<unknown, UserFormValue>(getUserFormValue),
    switchMap((userFormValue) =>
      store$.pipe(setItem(FORM_DATA_KEY, userFormValue))
    ),
    tap(() => removeSubmitButtonDisabledIfFormIsValid())
  )
  .subscribe();

We also want to set the values of the input fields, for example, when we refresh the page. We also handled the submit button state and we set the values only if there are values to set. We use our setInputFieldValues() method to update the UI.

userInfo$
  .pipe(
    tap(() => disableSubmitButton()),
    filter((v: UserFormValue | null): v is UserFormValue => !!v),
    tap((storedValue: UserFormValue) => {
      setInputFieldValues(storedValue);
      removeSubmitButtonDisabledIfFormIsValid();
    })
  )
  .subscribe();

When we submit the form, we will probably want to do something asynchronously. When that succeeds, we want to clear our Object Store, so we don't keep the submitted data on our user's machine. We also want to update the UI and clear the input fields. In this example, our form would send a POST request when we press the submit button. Therefore, we call event.preventDefault() on the submit event, so we stay on the page.

formSubmit$
  .pipe(
    // We prevent the native HTML submit event to run, so it won't send a post request for the sake of the example.
    tap((event: SubmitEvent) => {
      event.preventDefault();
      disableSubmitButton();
    }),
    map(getUserFormValue),
    // this is the point where we could do anything with the current form values, for example, send them to the server, etc.
    switchMap(() => store$.pipe(deleteItem(FORM_DATA_KEY))),
    tap(() => setInputFieldValues())
  )
  .subscribe();

And when we want to clear the form, we need to do the same with the data stored in our Object Store.

clearForm$
  .pipe(
    switchMap(() => store$.pipe(deleteItem(FORM_DATA_KEY))),
    tap(() => setInputFieldValues())
  )
  .subscribe();

Real-world use cases for Key-Value pair Object Stores

Having persistent forms between page refreshes is just one useful feature you can do with IndexedDb. Our example above is very simple, but you can have a multi-page form. One could store the progress on such forms and allow the user to continue with the forms later. Keeping the constraints of IndexedDb in mind, one very cool feature is storing data for offline use.

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

Exploring Angular Forms: A New Alternative with Signals

Exploring Angular Forms: A New Alternative with Signals In the world of Angular, forms are essential for user interaction, whether you're crafting a simple login page or a more complex user profile interface. Angular traditionally offers two primary approaches: template-driven forms and reactive forms. In my previous series on Angular Reactive Forms, I explored how to harness reactive forms' power to manage complex logic, create dynamic forms, and build custom form controls. A new tool for managing reactivity - signals - has been introduced in version 16 of Angular and has been the focus of Angular maintainers ever since, becoming stable with version 17. Signals allow you to handle state changes declaratively, offering an exciting alternative that combines the simplicity of template-driven forms with the robust reactivity of reactive forms. This article will examine how signals can add reactivity to both simple and complex forms in Angular. Recap: Angular Forms Approaches Before diving into the topic of enhancing template-driven forms with signals, let’s quickly recap Angular's traditional forms approaches: 1. Template-Driven Forms: Defined directly in the HTML template using directives like ngModel, these forms are easy to set up and are ideal for simple forms. However, they may not provide the fine-grained control required for more complex scenarios. Here's a minimal example of a template-driven form: ` ` 2. Reactive Forms: Managed programmatically in the component class using Angular's FormGroup, FormControl, and FormArray classes; reactive forms offer granular control over form state and validation. This approach is well-suited for complex forms, as my previous articles on Angular Reactive Forms discussed. And here's a minimal example of a reactive form: ` ` Introducing Signals as a New Way to Handle Form Reactivity With the release of Angular 16, signals have emerged as a new way to manage reactivity. Signals provide a declarative approach to state management, making your code more predictable and easier to understand. When applied to forms, signals can enhance the simplicity of template-driven forms while offering the reactivity and control typically associated with reactive forms. Let’s explore how signals can be used in both simple and complex form scenarios. Example 1: A Simple Template-Driven Form with Signals Consider a basic login form. Typically, this would be implemented using template-driven forms like this: ` ` This approach works well for simple forms, but by introducing signals, we can keep the simplicity while adding reactive capabilities: ` ` In this example, the form fields are defined as signals, allowing for reactive updates whenever the form state changes. The formValue signal provides a computed value that reflects the current state of the form. This approach offers a more declarative way to manage form state and reactivity, combining the simplicity of template-driven forms with the power of signals. You may be tempted to define the form directly as an object inside a signal. While such an approach may seem more concise, typing into the individual fields does not dispatch reactivity updates, which is usually a deal breaker. Here’s an example StackBlitz with a component suffering from such an issue: Therefore, if you'd like to react to changes in the form fields, it's better to define each field as a separate signal. By defining each form field as a separate signal, you ensure that changes to individual fields trigger reactivity updates correctly. Example 2: A Complex Form with Signals You may see little benefit in using signals for simple forms like the login form above, but they truly shine when handling more complex forms. Let's explore a more intricate scenario - a user profile form that includes fields like firstName, lastName, email, phoneNumbers, and address. The phoneNumbers field is dynamic, allowing users to add or remove phone numbers as needed. Here's how this form might be defined using signals: ` > Notice that the phoneNumbers field is defined as a signal of an array of signals. This structure allows us to track changes to individual phone numbers and update the form state reactively. The addPhoneNumber and removePhoneNumber methods update the phoneNumbers signal array, triggering reactivity updates in the form. ` > In the template, we use the phoneNumbers signal array to dynamically render the phone number input fields. The addPhoneNumber and removePhoneNumber methods allow users to reactively add or remove phone numbers, updating the form state. Notice the usage of the track function, which is necessary to ensure that the ngFor directive tracks changes to the phoneNumbers array correctly. Here's a StackBlitz demo of the complex form example for you to play around with: Validating Forms with Signals Validation is critical to any form, ensuring that user input meets the required criteria before submission. With signals, validation can be handled in a reactive and declarative manner. In the complex form example above, we've implemented a computed signal called formValid, which checks whether all fields meet specific validation criteria. The validation logic can easily be customized to accommodate different rules, such as checking for valid email formats or ensuring that all required fields are filled out. Using signals for validation allows you to create more maintainable and testable code, as the validation rules are clearly defined and react automatically to changes in form fields. It can even be abstracted into a separate utility to make it reusable across different forms. In the complex form example, the formValid signal ensures that all required fields are filled and validates the email and phone numbers format. This approach to validation is a bit simple and needs to be better connected to the actual form fields. While it will work for many use cases, in some cases, you might want to wait until explicit "signal forms" support is added to Angular. Tim Deschryver started implementing some abstractions around signal forms, including validation and wrote an article about it. Let's see if something like this will be added to Angular in the future. Why Use Signals in Angular Forms? The adoption of signals in Angular provides a powerful new way to manage form state and reactivity. Signals offer a flexible, declarative approach that can simplify complex form handling by combining the strengths of template-driven forms and reactive forms. Here are some key benefits of using signals in Angular forms: 1. Declarative State Management: Signals allow you to define form fields and computed values declaratively, making your code more predictable and easier to understand. 2. Reactivity: Signals provide reactive updates to form fields, ensuring that changes to the form state trigger reactivity updates automatically. 3. Granular Control: Signals allow you to define form fields at a granular level, enabling fine-grained control over form state and validation. 4. Dynamic Forms: Signals can be used to create dynamic forms with fields that can be added or removed dynamically, providing a flexible way to handle complex form scenarios. 5. Simplicity: Signals can offer a simpler, more concise way to manage form states than traditional reactive forms, making building and maintaining complex forms easier. Conclusion In my previous articles, we explored the powerful features of Angular reactive forms, from dynamic form construction to custom form controls. With the introduction of signals, Angular developers have a new tool that merges the simplicity of template-driven forms with the reactivity of reactive forms. While many use cases warrant Reactive Forms, signals provide a fresh, powerful alternative for managing form state in Angular applications requiring a more straightforward, declarative approach. As Angular continues to evolve, experimenting with these new features will help you build more maintainable, performant applications. Happy coding!...

Oct 4, 2024

5 mins

AngularJavaScript

Fly.io for Easier Cloud Deployment with Annie Sexton

Annie Sexton, Developer Advocate at Fly.io, to discuss Fly.io’s approach to simplifying cloud deployment. Annie shares Fly.io's unique position as a public cloud that offers the flexibility of infrastructure control with a streamlined developer experience. They explore Fly.io’s private networking and distributed app capabilities, allowing developers to deploy applications close to users worldwide with ease. Annie also addresses common challenges in distributed systems, including latency, data replication, and the balance between global reach and simple, single-region projects. Chapters: - 00:00 - 01:32 Introduction to the Modern Web Podcast and Guests - 01:33 - 04:00 Overview of Fly.io and Annie’s Role as Developer Advocate - 04:01 - 06:35 What Makes Fly.io Stand Out Among Cloud Platforms - 06:36 - 08:57 Distributed Applications: Benefits and Use Cases - 08:58 - 11:28 Understanding Distributed Web Servers and Private Networking - 11:29 - 13:49 Challenges in Distributed Data and Replication Techniques - 13:50 - 16:12 Fly.io’s Unique Solutions for Data Consistency - 16:13 - 18:34 When to Consider a Distributed Setup for Your Application - 18:35 - 20:35 Tools and Tips for Evaluating Geographical Distribution Needs - 20:36 - 22:22 Simplifying Global Deployment with Fly.io’s Command Features - 22:23 - 24:18 Considerations for Latency and Performance Optimization - 24:19 - 26:45 Balancing Simplicity with Advanced Control for Developers - 26:46 - 29:04 Easy Deployment for Hobbyists and Smaller Projects - 29:05 - 31:27 Getting Started on Fly.io with Fly Launch - 31:28 - 33:48 Developer Advocacy and Meeting Diverse Needs in the Cloud - 33:49 - 36:15 Catering to Beginners and Experienced Developers Alike - 36:16 - End Closing Remarks and Where to Find Fly.io and the Hosts Follow Annie Sexton on Social Media Linkedin: ⁠https://www.linkedin.com/in/annie-sexton-11472a46/⁠ Github: ⁠https://github.com/anniebabannie⁠ Sponsored by This Dot: thisdot.co...

Nov 6, 2024

2 mins

Software EngineerJavaScript

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

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau

In this episode of the Modern Web Podcast, Danny Thompson sits down with Ferdinand Como and Baptiste Leproux from Nuxt Labs to uncover the story behind Nuxt Studio, a tool that's transforming how developers and non-technical users interact with Nuxt applications. Ferdinand and Baptiste share how Nuxt Studio bridges the gap between developer customization and user-friendly content management. Built to empower agencies, freelancers, and their clients, Nuxt Studio combines powerful features like live previews, Vue component integration, and schema-driven forms to make managing content seamless. The conversation also explores the broader mission of Nuxt Labs—building sustainable open-source tools that enhance developer experience and meet real-world needs. With insights into the future of Nuxt Studio and its potential to scale for larger organizations, this episode is a must-listen for anyone passionate about innovation in web development. Chapters 1. Introduction and Setting the Stage (00:00:00) 2. The Vision Behind Nuxt Studio (00:03:10) 3. Nuxt Studio’s Core Features (00:08:45) 4. Challenges in Building Nuxt Studio (00:16:20) 5. Target Audience and Use Cases (00:22:35) 6. Sustainability in Open Source (00:29:00) 7. The Future of Nuxt Studio (00:35:10) 8. Nuxt Studio’s Role in the Nuxt Ecosystem (00:42:30) 9. Closing Thoughts and What’s Next (00:48:00) 10. Sponsor Shoutout and Wrap-Up (00:53:20) Follow Baptiste Leproux and Ferdinand Coumau Baptiste Twitter: https://x.com/_larbish Ferdinand Twitter: https://x.com/CoumauFerdinand Baptiste Linkedin: https://www.linkedin.com/in/baptiste-leproux-618842b0/ Ferdinand Linkedin: https://www.linkedin.com/in/ferdinand-coumau-nuxt/ Sponsored by This Dot: thisdot.co...

Nov 20, 2024

2 mins

VueNuxtJS

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.

Introducing @this-dot/rxidb

Storing data in chronological order

Initiating the Database

Manipulating the data

Toggling button states

Real-world use cases for autoIncrement Object Stores

Storing objects

Set up the Object Store and the event listeners

Set up some helper methods

Setting up our subscriptions

Real-world use cases for Key-Value pair Object Stores

Balázs Tápai

You might also like

Exploring Angular Forms: A New Alternative with Signals

Fly.io for Easier Cloud Deployment with Annie Sexton

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

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau

Let's innovate together!

You might also like

Exploring Angular Forms: A New Alternative with Signals

Fly.io for Easier Cloud Deployment with Annie Sexton

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

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau