Javascript

Introduction to LoopBack

Published Aug 4, 2021

Updated Feb 14, 2023

8 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 one wants to implement a Node.js-based backend API, the first framework that usually comes to mind is Express. This is, perhaps, the most popular web framework for Node.js. This framework is also usually the top choice for demonstration purposes such as proof of concepts, or tutorials, which further contributes to its popularity. A framework such as LoopBack is usually not the first option, even though this is a relatively mature and stable framework, and backed by an IBM company called StrongLoop.

As part of this blog post, we'll demonstrate the basic functionalities of LoopBack by building a small REST API.

Features at a Glance

LoopBack uses Express under the hood, but there are several noticeable features that make LoopBack stand out from other API frameworks:

First-Class Support for TypeScript If you like TypeScript, then you'll definitely want to consider LoopBack. It can be a great companion to other TypeScript-based frameworks such as Angular, as frontend and backend teams will use the same programming language for the entire stack.
OpenAPI-Driven APIs The OpenAPI standard is becoming widely adopted, and LoopBack makes it easy to create OpenAPI-based REST APIs.
Great CLI Tool LoopBack comes with its CLI tool, which is great for scaffolding initial projects, or generating additional code. Many can get a project running within minutes.
Loads of Connectors There are numerous connectors written for LoopBack, from REST/SOAP connectors, to database connectors for relational and NoSQL databases. This way, you can easily integrate your application with other APIs without much custom code.
Dependency Injection LoopBack has a DI-based context at its core, allowing for writing loosely coupled code. Your components declare dependencies on other components, and it's up to LoopBack to wire them up.

Getting Started

Now that we know what LoopBack is about, let's try to implement an application that will demonstrate the usage of two common functionalities that most API backends have, such as saving to a database, and invoking an external API. For this purpose, we'll build a small application that acts like a proxy towards the GitHub issue API, but with local caching. It will expose an endpoint where you can fetch a specific issue, and then this issue will be fetched from the local cache, or from GitHub if it's not cached.

Scaffolding the Project

To start off, install the LoopBack CLI which is used to scaffold projects quickly:

$ npm install -g @loopback/cli

Now that you have the CLI installed, start by scaffolding your application:

$ lb4 loopback-demo

The CLI tool will ask you a couple of questions about the project, and allow you to select which features you will be using. Let's select all features, for now, just to see everything that you can get out of the box:

? Project description: Demonstration of basic features of LoopBack.
? Project root directory: LoopBackDemoApplication
? Application class name: LoopbackDemoApplication
? Select features to enable in the project (Press <space> to select, <a> to toggle all, <i> to invert selection)
>(*) Enable eslint: add a linter with pre-configured lint rules
 (*) Enable prettier: install prettier to format code conforming to rules
 (*) Enable mocha: install mocha to run tests
 (*) Enable loopbackBuild: use @loopback/build helpers (e.g. lb-eslint)
 (*) Enable vscode: add VSCode config files
 (*) Enable docker: include Dockerfile and .dockerignore
 (*) Enable repositories: include repository imports and RepositoryMixin

At this point, we already have the application running with a sample REST endpoint, but let's do a couple of additional steps first that will make our development easier. At the moment, the LoopBack starter project does not come with a hot restart functionality, so let's add that first:

$ npm install -D tsc-watch

Then add this line under your "scripts" tag in package.json:

"start:watch": "tsc-watch --target es2017 --outDir ./dist --onSuccess \"node .\"",

LoopBack does not output many logs by default, unfortunately. Log output is controlled via the DEBUG environment variable, which determines the scope of the logs. To set this variable in a cross-platform manner and output some useful logs, we will use cross-env:

npm install -D cross-env

Now, add the following command, which adds some basic logging to standard out:

"start:watch:debug": "cross-env DEBUG=loopback:connector:*,loopback:rest:* npm run start:watch",

Running the Project

Running the project is now easy- simply execute npm run start:watch:debug, and the application process will automatically restart on every code change. Open http://localhost:3000/ping in your browser, and you should see something like this:

{"greeting":"Hello from LoopBack4","date":"2021-07-23T13:33:28.014Z","url":"/ping","headers":{"host":"localhost:3000","connection":"keep-alive","cache-control":"max-age=0","sec-ch-ua":"\"Chromium\";v=\"92\", \" Not A;Brand\";v=\"99\", \"Google Chrome\";v=\"92\"","sec-ch-ua-mobile":"?0","upgrade-insecure-requests":"1","user-agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9","sec-fetch-site":"none","sec-fetch-mode":"navigate","sec-fetch-user":"?1","sec-fetch-dest":"document","accept-encoding":"gzip, deflate, br","accept-language":"en-US,en;q=0.9"}}

That's it! You now have a LoopBack application running at http://localhost:3000/.

Project Structure

The project is organized into several layers, where each layer has its own subdirectory within the root project tree. The first layer that you'll probably notice, and the first layer that you reached by executing the GET request in the previous chapter, is the controllers layer. A controller is where you would implement your API endpoint, and place your business logic. The controller will authenticate the incoming request, parse and validate the request, as well as orchestrate calls to services and repositories. There are no services in the starter project, but services provide you with interfaces to invoke local and remote operations. Repositories, on the other hand, handle all CRUD operations on your models, which represent domain objects.

LoopBack comes with dependency-injection (DI) out of the box, and components such as controllers, services, and repositories are registered automatically to the DI context. There's no need to wire them up manually. In fact, they are detected automatically when the application is booted.

Developing Our Cache Application

The cache will have the following flow:

A GET request is sent to /issues to retrieve a GitHub issue.
This will look in the internal cache if issue already exists.
- If exists, it will return the cached issue.
- If not, it will retrieve the relevant issue from GitHub using GitHub's REST API, and cache it locally.

For the actual cache, we'll use an in-memory database, which is persisted to disk.

Implementing Basic Controller

To start, we can implement just a basic controller that will accept a request and reflect it back in the response. First, use the lb4 model command to create a CachedIssue model, an instance of which will be a response from the controller. When creating a new model, the CLI tool will typically ask you whether you want to create an instance of a Model, or an instance of an Entity. The difference between the two is that an Entity is saved to a database (therefore it must have a unique ID), while a Model is typically not saved to a database, and can be used for data transfer objects (DTOs) on the API level.

Our CachedIssue will eventually be saved to our database (cache), so we'll choose the Entity option, with the following properties:

issueNumber: number
repositoryOwner: string
repositoryName: string
title: string
reporter: string
state: string

Once the model is created, now we can generate a controller that will use it. Execute the lb4 controller command to generate an empty controller. Implement the following endpoint in the controller:

import {get, getModelSchemaRef, param} from '@loopback/rest';
import {CachedIssue} from '../models';

export class IssueController {
  constructor() {}

  @get('/issues/{repositoryOwner}/{repositoryName}/{issueNumber}', {
    responses: {
      '200': {
        content: {
          'application/json': {
            schema: getModelSchemaRef(CachedIssue),
          },
        },
      },
    },
  })
  async getIssue(
    @param.path.string('repositoryOwner') repositoryOwner: string,
    @param.path.string('repositoryName') repositoryName: string,
    @param.path.number('issueNumber') issueNumber: number,
  ): Promise<CachedIssue> {
    return {
      issueNumber: issueNumber,
      repositoryOwner: repositoryOwner,
      repositoryName: repositoryName,
    } as CachedIssue;
  }
}

It's a simple controller that accepts three properties, specified using the @param annotation, and reflects them back in the response, just to verify that it's working. Even on this simple example, you can see one of the benefits that LoopBack gives you out of the box, and that is a validation of requests. For example, if you send a request that doesn't conform the request specification, LoopBack will throw an error, and inform why the validation failed.

Now execute a GET request towards http://localhost:3000/issues/strongloop/loopback/1553 - this should return an instance of CachedIssue, containing the following properties:

{"issueNumber":1553,"repositoryOwner":"strongloop","repositoryName":"loopback"}

At this point, we have a functioning controller.

Integrating with GitHub

To integrate with an external API, we need to generate two things: a datasource and a service.

Generate a datasource using the command lb4 datasource, name it GitHubApi, and use the REST services connector. This will place the datasource configuration in the git-hub-api.datasource.ts, and LoopBack will use this file to auto-configure the datasource on startup. Be sure to place the following configuration in the datasource after it has been generated.

const config = {
  name: 'GitHubApi',
  connector: 'rest',
  options: {
    headers: {
      accept: 'application/json',
      'content-type': 'application/json',
      'User-Agent': 'LoopBack', // GitHub API requires User-Agent header
    },
  },
  operations: [
    {
      template: {
        method: 'GET',
        url: 'https://api.github.com/repos/{repositoryOwner}/{repositoryName}/issues/{issueNumber}',
      },
      functions: {
        // The service that uses this datasource will need to have these functions in its interface
        getIssue: ['repositoryOwner', 'repositoryName', 'issueNumber'],
      },
    },
  ],
};

This configuration specifies general configuration of the connector (such as the user agent used), however it also specifies the operations that we will expose internally towards the controllers, the GitHub API URL for each operation, and parameters for each operation. There is plenty of other configuration properties for the REST connector, but we'll keep it simple for the purposes of this tutorial.

Controllers normally access datasources through services, and the next step is to generate a service. Use the lb4 service command to generate a service named "GitHubApi". Choose the Remote service proxy backed by a data source option and choose the GitHubApiDatasource datasource. Once the service is generated, create an interface that will match the operations specified in the configuration of the REST connector:

import {inject, Provider} from '@loopback/core';
import {getService} from '@loopback/service-proxy';
import {GitHubApiDataSource} from '../datasources';

/**
 * This class is used for representing the response from GitHub API. Only a subset of returned properties is used.
 */
export class GitHubIssueResponse {
  'number': number;
  title: string;
  user: {login: string};
  state: string;
}

/**
 * When other components want to use this service, they declare dependency on the following interface.
 */
export interface GitHubApi {
  getIssue(
    repositoryOwner: string,
    repositoryName: string,
    issueNumber: number,
  ): Promise<GitHubIssueResponse>;
}

export class GitHubApiProvider implements Provider<GitHubApi> {
  constructor(
    // GitHubApi must match the name property in the datasource json file
    @inject('datasources.GitHubApi')
    protected dataSource: GitHubApiDataSource = new GitHubApiDataSource(),
  ) {}

  value(): Promise<GitHubApi> {
    return getService(this.dataSource);
  }
}

Here, we used GitHubIssueResponse to define the properties that are read from the GitHub API. GitHub API returns numerous properties in the response, but we'll only use a few properties for simplicity. LoopBack will automatically parse GitHub API's response, and instantiate an object of GitHubIssueResponse with the properties that we need.

Notice also how we declared a dependency on GitHubApiDataSource in the constructor. This is LoopBack's dependency injection mechanism at work - we only declare the dependency through @inject annotation, and LoopBack's DI container is responsible for injecting an instance of GitHubApiDataSource during bootstrap.

Saving Issues to Local Database

Our cache would not work without having some local storage. LoopBack has a variety of database connectors, but we'll go with the most simple one: an in-memory database which is persisted to a JSON file on the local disk. Run the lb4 datasource command, name the datasource "FileDb" and use the In-memory db connector with data/db.json as the full path for file persistence. Config of the generated datasource should look like this:

const config = {
  name: 'FileDb',
  connector: 'memory',
  localStorage: '',
  file: './data/db.json' // Make sure the file exists!
};

As you can see, the configuration for an in-memory database is quite simple when compared to the configuration of the REST connector that we configured earlier. One thing to note here is that LoopBack expects the file ./data/db.json to exists on the filesystem. Be sure to create it before starting the application (it can be empty).

The controller will access this datasource through a service, but not just any service. For CRUD operations, we use a specialized service called a repository. Repositories provide strong-typed data access operations of a domain model against the underlying database or service. Before we create a repository, we need a model to persist first. Execute lb4 model, and choose Entity model this time, since it will be persisted to the database.

import {Entity, model, property} from '@loopback/repository';

/**
 * This model represents the issue that is persisted to local database.
 */
@model()
export class CachedIssue extends Entity {
  @property({
    type: 'number',
    id: true,
    generated: false,
    required: true,
  })
  issueNumber: number;

  @property({
    type: 'string',
    required: true,
  })
  repositoryOwner: string;

  @property({
    type: 'string',
    required: true,
  })
  repositoryName: string;

  @property({
    type: 'string',
    required: true,
  })
  title: string;

  @property({
    type: 'string',
    required: true,
  })
  reporter: string;

  @property({
    type: 'string',
    required: true,
  })
  state: string;

  constructor(data?: Partial<CachedIssue>) {
    super(data);
  }
}

export interface CachedIssueRelations {
  // describe navigational properties here
}

export type IssueWithRelations = CachedIssue & CachedIssueRelations;
tions {
  // describe navigational properties here
}

export type IssueWithRelations = Issue & IssueRelations;

Use the lb4 repository command to generate a repository using the FileDbDatasource datasource and the CachedIssue model:

import {inject} from '@loopback/core';
import {DefaultCrudRepository} from '@loopback/repository';
import {FileDbDataSource} from '../datasources';
import {CachedIssue, IssueRelations} from '../models';

export class IssueRepository extends DefaultCrudRepository<
  CachedIssue,
  typeof CachedIssue.prototype.issueNumber,
  IssueRelations
> {
  constructor(@inject('datasources.FileDb') dataSource: FileDbDataSource) {
    super(CachedIssue, dataSource);
  }
}
import {inject} from '@loopback/core';
import {DefaultCrudRepository} from '@loopback/repository';
import {FileDbDataSource} from '../datasources';
import {Issue, IssueRelations} from '../models';

export class IssueRepository extends DefaultCrudRepository<
  Issue,
  typeof Issue.prototype.issueNumber,
  IssueRelations
> {
  constructor(
    @inject('datasources.FileDb') dataSource: FileDbDataSource,
  ) {
    super(Issue, dataSource);
  }
}

Putting It All Together

With all the integrations in place, we can now finalize the controller and add some business logic to it. The controller should read parameters from the request, propagate them to GitHub API, and read GitHub API's response, which is represented by an instance of GitHubIssueResponse object. Once it has this object, it uses the issue number as a primary key to see if the issue has already been persisted to the database. If it has, the controller will return the cached issue, otherwise it will fetch it from GitHub before returning it.

import {get, getModelSchemaRef, HttpErrors, param} from '@loopback/rest';
import {CachedIssue} from '../models';
import {inject} from '@loopback/core';
import {GitHubApi} from '../services';
import {repository} from '@loopback/repository';
import {IssueRepository} from '../repositories';

export class IssueController {
  constructor(
    @inject('services.GitHubApi')
    protected gitHubApiService: GitHubApi,
    @repository(IssueRepository)
    public issueRepository: IssueRepository,
  ) {}

  @get('/issues/{repositoryOwner}/{repositoryName}/{issueNumber}', {
    responses: {
      '200': {
        content: {
          'application/json': {
            schema: getModelSchemaRef(CachedIssue),
          },
        },
      },
    },
  })
  async getIssue(
    @param.path.string('repositoryOwner') repositoryOwner: string,
    @param.path.string('repositoryName') repositoryName: string,
    @param.path.number('issueNumber') issueNumber: number,
  ): Promise<CachedIssue> {
    try {
      // This method will return saved entity if exists, otherwise it will raise ENTITY_NOT_FOUND error
      return await this.issueRepository.findById(issueNumber);
    } catch (e) {
      if (e.code === 'ENTITY_NOT_FOUND') {
        const issueResponse = await this.gitHubApiService.getIssue(
          repositoryOwner,
          repositoryName,
          issueNumber,
        );

        const newIssueEntity = new CachedIssue();
        newIssueEntity.issueNumber = issueResponse.number;
        newIssueEntity.title = issueResponse.title;
        newIssueEntity.reporter = issueResponse.user?.login;
        newIssueEntity.state = issueResponse.state;
        newIssueEntity.repositoryName = repositoryName;
        newIssueEntity.repositoryOwner = repositoryOwner;

        return this.issueRepository.create(newIssueEntity);
      } else {
        throw new HttpErrors.InternalServerError(
          `Error while looking up issue #${issueNumber} in the database`,
        );
      }
    }
  }
}

We now have a fully functioning application. You can try re-sending the GET request from earlier, and verify that it is persisted to ./data/db.json. Of course, we're still missing some important cache features such as eviction of unused data, but we'll leave it to you to implement in case you'd like to play with the framework further.

We hope you enjoyed this brief intro to LoopBack, and perhaps you'll even consider it for your next project. LoopBack has many other functionalities and built-in connectors, but as part of this tutorial, we focused on the common ones: creating a simple API, invoking an external API, and using a database. The complete project is available on GitHub in case you'd like to check it out.

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)

Dario Djuric
Dario is a full-stack engineer who has spent most of his career doing enterprise Java projects. He has always had a hidden passion for frontend, though -- and he is now able to pursue that passion at This Dot. He spends most of his free time with his two sons, but occasionally, he manages to squeeze in some casual sports activities such as jogging, cycling, and soccer.
@dario_djuric @dariodjuric

Making Seamless Page Transitions with the View Transitions API

Make Seamless Page Transitions using the View Transitions API Traditionally web applications have always had a less polished experience, both functionally and visually speaking, compared to native applications on mobile and other platforms. This has been improving over the years with the introduction of new web APIs and standards. One such new API that bridges that gap is the View Transitions API. What is the View Transitions API? The View Transitions API is a new browser feature that allows developers to more easily create animated transitions between pages and views, similar to how mobile apps have transitions when navigating between pages. Adding view transitions to your application can reduce the cognitive load on your users and make the experience feel less inconsistent. One great thing about view transitions is that they can be used by both SPAs (single-page applications) and MPAs (multi-page applications) alike! Using the View Transitions API for SPAs Let’s see how we can use view transitions ourselves. We will use examples adapted from demos created by the wonderful Jake Archibald and Bramus. There are some alterations to a few of the examples to make them work with the newest version of the View Transitions API, but otherwise, they’re mostly the same. The process of getting view transitions working for SPAs is as simple as calling document.startViewTransition right before starting navigation and replacing your page’s content immediately after that. You need to make this call in your router or in an event listener that triggers your page navigation. The following is an example of how you can hook into page navigation in a vanilla JavaScript application. This example uses the Navigation API if it’s available. As of the time of writing this article only Chromium-based browsers support the Navigation API, but there is a fallback to using a click listener on link elements so that this works with Firefox and Safari. ` If you’re using a framework, then there’s probably a better way to do this specific to that framework than by using this contrived example. For example, if you are implementing usage of this API with a Next application, you may opt for something like next-view-transitions. For this article, we’re going to focus on the way this is done in vanilla JavaScript so that the fundamentals of using the API are understood. Knowing how it’s implemented in vanilla JavaScript should give you enough understanding to implement this in the framework of your choice if there isn’t already a library that does it for you. Now we have a way to know when a navigation is being requested. Using the above utility function we can start the animation and replace our content as follows: ` getMyPageContentSomehow can be any function that returns HTML. How that is implemented will depend on your application and framework of choice. If you want to run these examples on your machine, the demo repository has instructions in its README. In essence, it’s as simple as hosting an HTTP server at the root of the project and visiting localhost. No fancy build system is required! By default, a fade is done that only lasts for a moment. The animation that happens can be configured using CSS with the ::view-transition-group pseudo-element on the element you want to animate, which in our case is the entire page, and we pass in root. ` Given that the animation properties are used, you have much control over what kind of animation to do. You can change the duration and the interpolation, add keyframes and gradients, and even add image masks. You can learn more about the animation properties in CSS on MDN. Using the View Transitions API for MPAs As mentioned, view transitions also work for MPAs with no client-side routing. Setting up view transitions for MPAs is much easier than for SPAs. All you have to do is include the CSS rule on all pages where you want the animations. ` Of course, like how it works with SPAs, you can customize the animations to your heart’s content using the view transition pseudo-elements. Conclusion I hope this article helped you understand the fundamentals of using the View Transitions API. Now that most browsers support it and it’s not too difficult to add it to existing applications, it is a great time to learn how to use it. You can view a full list of examples here (made by Jake Archibald and Bramus) if you want to see how advanced the animations can get. I like the Star Wars ones especially. The README explains how to get all the examples up and running (a total of 43!)....

Aug 2, 2024

4 mins

JavaScript

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them. However, web browsers now offer a standard dialog element. Why use the dialog element? The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser. This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general. Basic usage Adding a dialog using the new tag can be achieved with just a few lines of code. ` However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it. ` Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat! Accessibility and focus management Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you. By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close element. Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly. Adding forms to dialogs Forms can also be added to dialogs, and there’s even a special method value for them. If you add a element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods. First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form. So given this example form: ` The form element with the example-form id will have its returnValue set to Submit. In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted. You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog. In this case, you can call event.preventDefault() in the submit event listener like so: ` Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog. Enhancing the backdrop The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc. You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working. First, an event listener is needed so that we know when the user clicks away from the dialog. ` Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog. To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple element can do! ` Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue. ` The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed. Conclusion Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options....

Oct 25, 2024

4 mins

HTMLJavaScript

A Look at Playwright Parallelism

A Look at Playwright Parallelism Playwright is an open-source automation library developed by Microsoft, designed for testing web applications across multiple browsers. It enables developers and testers to write scripts that simulate real user actions when interacting with web pages. Playwright supports major browsers like Chrome, Firefox, and Safari, including their headless modes. Recently, it has gained a lot of popularity for its robustness, ease of use, and cross-browser compatibility. In this blog post, we will take a look at one very useful aspect of Playwright: running tests in parallel. Parallelism in Playwright Parallelism in Playwright refers to running multiple test spec files or even test cases within a spec file simultaneously, greatly improving test execution speed. This is achieved by running the tests in worker processes, where each worker process is an OS process, running independently, orchestrated by the test runner. All workers have identical environments, and each starts its own browser instance. Parallel execution is particularly beneficial in continuous integration and continuous deployment (CI/CD) pipelines, reducing overall build and testing times. Playwright's architecture inherently supports parallelism, and most modern test runners integrating with Playwright can leverage this feature. The parallel execution feature makes Playwright a highly efficient tool for large-scale web application testing. Enabling Parallelism By default, if you scaffold the project using npm init playwright@latest, parallelism is already enabled. Assuming that Playwright's configuration includes three browsers and there is a single spec file with two test cases, the total number of tests that Playwright needs to execute is 3x2 = 6. ` Playwright will decide on how many workers to use based on several factors: - Hardware support: Depending on the number of CPU cores and other system resources, the operating system will decide how many processes Playwright can spin up. - The workers property in the playwright.config.ts file. - The --workers argument to the playwright test command. For example, npx playwright test --workers 4. The --workers argument overrides the workers property in the configuration. However, in both cases, the number of workers can go up to the number of processes that Playwright can spin up, as decided by the operating system. Once it has determined the number of workers, and if the number of workers is larger than 1, Playwright will then decide how to split the work between workers. This decision also depends on several factors, such as the number of browsers involved and the granularity of the parallelism, which can be controlled in several ways: - In the test spec file, you can specify whether to run the test cases in parallel. To run tests in parallel, you can invoke test.describe.configure({ mode: 'parallel' }); before your test cases. - Alternatively, you can configure it per project by setting the fullyParallel: true property. - And finally, you can set it globally in the config, using the same property: fullyParallel: true. Therefore, if there is more than one worker and the parallel mode is enabled, Playwright will assign test cases to each worker as they become available. This scenario is ideal because it means that each test is stateless, and the resources are used most efficiently. ` Disabling Parallelism What if, however, the tests are not stateless? Imagine one test changes the global configuration of the app via some sort of administration page, and the configuration affects different parts of the app, like enabling or disabling features. Other tests, which may be testing those features, would be impacted and would report incorrect results. In such cases, you might want to disable parallelism. You can disable any parallelism globally by allowing just a single worker at any time. Following the instructions from the previous sections to configure the number of workers, you can either set the workers: 1 option in the configuration file or pass --workers=1 to the command line. ` Let's have a look at our test output in this case: ` Now, compare the time it took with one worker versus the time it took with four workers. It took 8.2 seconds with one worker compared to only 3.9 seconds with multiple workers. That might be an inefficient usage of resources, of course, especially if you have a large test suite and some of the tests are stateless and can be run without impacting other tests. Tweaking Parallelism If you want some tests not to run in parallel, but still want to utilize your workers, you can do that. Again, following the configuration options from the previous sections, you can annotate the entire spec file with test.describe.configure({ mode: 'serial' }); to have the tests run sequentially in that spec file, or use the fullyParallel: false property to run tests sequentially on the project level, or using the same property to run tests sequentially on the global level. This means you can still split the tests between workers, but the tests would be run sequentially within a worker depending on the configuration. For example, let's set the number of workers to 4, but set fullyParallel: false globally. ` The tests need to be run sequentially, but since each browser instance effectively provides an isolated environment, this means tests cannot impact each other between environments, and they are safe to be executed sequentially within an environment. This means setting fullyParallel: false on the global level is not the same as having workers: 1, since the browsers themselves offer an isolated environment for the tests to run sequentially. However, since we only have 3 environments (3 browsers), we cannot fully utilize 4 workers as we wanted, so the number of workers is 3. Conclusion In conclusion, Playwright's workers are the core of its parallelism capabilities, enabling tests to run concurrently across different environments and browsers with efficiency. Through its many configuration properties, Playwright allows you to configure parallelism at multiple levels, offering a granular approach to optimizing your test runs. Beyond just executing tests in parallel on a single machine, Playwright's parallelism can even extend to splitting work across multiple machines through sharding, significantly enhancing the scalability of your testing. We hope this blog post was useful. For those interested in delving deeper into the world of Playwright and its powerful features, we've also recently released a JS Drop titled Awesome Web Testing with Playwright, and we also hosted Debbie O'Brien from Microsoft in a Modern Web episode....

Mar 20, 2024

5 mins

JavaScriptPlaywrightTesting

D1 SQLite: Writing queries with the D1 Client API

Writing queries with the D1 Client API In the previous post we defined our database schema, got up and running with migrations, and loaded some seed data into our database. In this post we will be working with our new database and seed data. If you want to participate, make sure to follow the steps in the first post. We’ve been taking a minimal approach so far by using only wrangler and sql scripts for our workflow. The D1 Client API has a small surface area. Thanks to the power of SQL, we will have everything we need to construct all types of queries. Before we start writing our queries, let's touch on some important concepts. Prepared statements and parameter binding This is the first section of the docs and it highlights two different ways to write our SQL statements using the client API: prepared and static statements. Best practice is to use prepared statements because they are more performant and prevent SQL injection attacks. So we will write our queries using prepared statements. We need to use parameter binding to build our queries with prepared statements. This is pretty straightforward and there are two variations. By default we add ? ’s to our statement to represent a value to be filled in. The bind method will bind the parameters to each question mark by their index. The first ? is tied to the first parameter in bind, 2nd, etc. I would stick with this most of the time to avoid any confusion. ` I like this second method less as it feels like something I can imagine messing up very innocently. You can add a number directly after a question mark to indicate which number parameter it should be bound to. In this exampl, we reverse the previous binding. ` Reusing prepared statements If we take the first example above and not bind any values we have a statement that can be reused: ` Querying For the purposes of this post we will just build example queries by writing them out directly in our Worker fetch handler. If you are building an app I would recommend building functions or some other abstraction around your queries. select queries Let's write our first query against our data set to get our feet wet. Here’s the initial worker code and a query for all authors: ` We pass our SQL statement into prepare and use the all method to get all the rows. Notice that we are able to pass our types to a generic parameter in all. This allows us to get a fully typed response from our query. We can run our worker with npm run dev and access it at http://localhost:8787 by default. We’ll keep this simple workflow of writing queries and passing them as a json response for inspection in the browser. Opening the page we get our author results. joins Not using an ORM means we have full control over our own destiny. Like anything else though, this has tradeoffs. Let’s look at a query to fetch the list of posts that includes author and tags information. ` Let’s walk through each part of the query and highlight some pros and cons. ` * The query selects all columns from the posts table. * It also selects the name column from the authors table and renames it to author_name. * It aggregates the name column from the tags table into a JSON array. If there are no tags, it returns an empty JSON array. This aggregated result is renamed to tags. ` * The query starts by selecting data from the posts table. * It then joins the authors table to include author information for each post, matching posts to authors using the author_id column in posts and the id column in authors. * Next, it left joins the posts_tags table to include tag associations for each post, ensuring that all posts are included even if they have no tags. * Next, it left joins the tags table to include tag names, matching tags to posts using the tag_id column in posts_tags and the id column in tags. * Finally, group the results by the post id so that all rows with the same post id are combined in a single row SQL provides a lot of power to query our data in interesting ways. JOIN ’s will typically be more performant than performing additional queries.You could just as easily write a simpler version of this query that uses subqueries to fetch post tags and join all the data by hand with JavaScript. This is the nice thing about writing SQL, you’re free to fetch and handle your data how you please. Our results should look similar to this: ` This brings us to our next topic. Marshaling / coercing result data A couple of things we notice about the format of the result data our query provides: Rows are flat. We join the author directly onto the post and prefix its column names with author. ` Using an ORM we might get the data back as a child object: ` Another thing is that our tags data is a JSON string and not a JavaScript array. This means that we will need to parse it ourselves. ` This isn’t the end of the world but it is some more work on our end to coerce the result data into the format that we actually want. This problem is handled in most ORM’s and is their main selling point in my opinion. insert / update / delete Next, let’s write a function that will add a new post to our database. ` There’s a few queries involved in our create post function: * first we create the new post * next we run through the tags and either create or return an existing tag * finally, we add entries to our post_tags join table to associate our new post with the tags assigned We can test our new function by providing post content in query params on our index page and formatting them for our function. ` I gave it a run like this: http://localhost:8787authorId=1&tags=Food%2CReview&title=A+review+of+my+favorite+Italian+restaurant&content=I+got+the+sausage+orchette+and+it+was+amazing.+I+wish+that+instead+of+baby+broccoli+they+used+rapini.+Otherwise+it+was+a+perfect+dish+and+the+vibes+were+great And got a new post with the id 11. UPDATE and DELETE operations are pretty similar to what we’ve seen so far. Most complexity in your queries will be similar to what we’ve seen in the posts query where we want to JOIN or GROUP BY data in various ways. To update the post we can write a query that looks like this: ` COALESCE acts similarly to if we had written a ?? b in JavaScript. If the binded value that we provide is null it will fall back to the default. We can delete our new post with a simple DELETE query: ` Transactions / Batching One thing to note with D1 is that I don’t think the traditional style of SQLite transactions are supported. You can use the db.batch API to achieve similar functionality though. According to the docs: Batched statements are SQL transactions ↗. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence. ` Summary In this post, we've taken a hands-on approach to exploring the D1 Client API, starting with defining our database schema and loading seed data. We then dove into writing queries, covering the basics of prepared statements and parameter binding, before moving on to more complex topics like joins and transactions. We saw how to construct and execute queries to fetch data from our database, including how to handle relationships between tables and marshal result data into a usable format. We also touched on inserting, updating, and deleting data, and how to use transactions to ensure data consistency. By working through these examples, we've gained a solid understanding of how to use the D1 Client API to interact with our database and build robust, data-driven applications....

Dec 23, 2024

6 mins

JavaScript

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.

Introduction to LoopBack

Features at a Glance

Getting Started

Scaffolding the Project

Running the Project

Project Structure

Developing Our Cache Application

Implementing Basic Controller

Integrating with GitHub

Saving Issues to Local Database

Putting It All Together

Dario Djuric

You might also like

Making Seamless Page Transitions with the View Transitions API

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

A Look at Playwright Parallelism

D1 SQLite: Writing queries with the D1 Client API

Let's innovate together!

You might also like

Making Seamless Page Transitions with the View Transitions API

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

A Look at Playwright Parallelism

D1 SQLite: Writing queries with the D1 Client API