Javascript

Introduction to LoopBack

Aug 4, 2021

8 min read

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.

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

Improving INP in React and Next.js

Improving INP in React and Next.js In one of my previous articles, I've explained what INP is, how it works, and how it may affect your website. I also promised you to follow up with more concrete advice on how to improve your INP in your favorite framework. This is the follow-up article, where I'll focus on how to improve your INP score in React and Next.js. How to prepare for INP in React and Next.js? The first thing to do is to ensure you're using the latest version of React. The React team has been working on making React more INP-friendly and has already made some improvements in the latest versions. To enhance your INP score, consider fully taking advantage of new features introduced in React 18, such as Concurrent Rendering, Automatic Batching, and Selective Hydration. However, there are also some general areas to focus on, such as SSR and SSG in Next.js, Web Workers, or optimizing your hooks and state management. Concurrent Rendering The Concurrent Mode in React uses an algorithm that breaks rendering down into so-called "fiber nodes" and schedules the renders based on their expiration and priority. This effectively allows the user to interact with the page while the rendering is still in progress. In previous React versions, all updates, such as setState calls were treated as "urgent" and once the re-render had started, there was no way to interrupt it. Concurrent Mode changes this by being able to prioritize the updates and interrupt a non-blocking state update started with startTransition. For a simple explanation of concurrency in React, you can check out Dan Abramov's explanation. As part of the Concurrent Mode, React introduced several lifecycle methods that allow you to prioritize the rendering of certain parts of your UI, such as: - useTransition hook that allows you to update the state without blocking the UI, - useDeferredValue hook that allows you to defer the rendering of certain parts of your UI, - startTransition API that, similarly to the useTransition hook lets you mark a state update as non-blocking. It lacks, however, an indication of whether it's still pending. Automatic Batching Introduced in React 18, Automatic Batching reduces the number of re-renders that happen on state changes even when they happen outside of event handlers, e.g. in a setTimeout or Promise callback. This feature comes out of the box and you don't have to do anything to enable it, and it makes a great argument for upgrading to React 18. Selective Hydration Selective Hydration allows you to take hydration off the main thread by wrapping your components in a Suspense boundary. This way, components can become interactive faster as the browser can do other work on the main thread while the hydration is happening. To fully take advantage of selective hydration, consider the following: - Prioritizing Above-the-Fold Content: Use Suspense boundaries strategically around any parts of your application that may take the server longer to deliver to ensure they don’t block critical content from becoming interactive as soon as possible. - Hydration on Interaction: Implementing hydration upon user interaction for non-critical components can drastically reduce the main thread's workload, enhancing INP. Vercel even has a small case study showing how using selective hydration improved the performance of a Next.js site. Server-Side Rendering (SSR) and Static Site Generation (SSG) in Next.js Not everything has to run client-side. Next.js excels in SSR and SSG capabilities, which can significantly impact INP by delivering content to users faster. Optimizing SSR with techniques like incremental static regeneration (ISR) or leveraging SSG for static pages ensures that users can interact with content faster, improving the perceived performance. Workers Offloading heavy computations to Web Workers can free up the main thread, enhancing the responsiveness of React and Next.js applications. This strategy is especially useful when dealing with third-party scripts. Offloading such scripts in Next.js can be easily done by specifying the "worker" strategy on your Script component. Be aware that this feature is not yet stable and does not work with the app directory, though. If you want to take things one step further, you could use Partytown, which helps you offload any resource-intensive scripts to Web Workers. It comes with a React component that you can use to wrap your third-party scripts and offload them to a Web Worker, and it's compatible with Next.js as well. Hooks and State Management State management in React applications can easily get out of hand, leading to unnecessary re-renders and effectively an increased INP. Sometimes, using a state management library like Redux or MobX can help you consolidate your state and reduce the number of re-renders. However, they are not silver bullets and can also introduce performance issues if not used properly. If you are dealing with a lot of re-renders due to prop changes, make sure you are leveraging memoization. As of now, you may need to work with useMemo and useCallback hooks to memoize your values and functions, respectively. The upcoming React 19’s Forget Compiler, however, will apparently memoize everything under the hood, making these hooks obsolete. Using memoization properly can help you reduce the number of re-renders and improve your INP. To investigate your hook dependencies and re-renders, you can leverage React Developer Tools or use this handy helper hook I found on the internet to trace your re-renders: ` Conclusion Improving INP in React and Next.js is not easy and can require much investigation and fine-tuning. Still, it's worth doing to avoid being penalized by Google in its search results and provide a better experience for your users. Adopting React 18's new features, leveraging SSR and SSG in Next.js, utilizing Web Workers, and optimizing hooks and state management can significantly boost your INP score and deliver a faster application to your users. Remember, INP is just one among many performance metrics emphasizing the need for a comprehensive approach to performance optimization...

Apr 19, 2024

5 mins

Web PerformanceReactNextJSJavaScript

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

OAuth2 for JavaScript Developers

OAuth2 for JavaScript Developers OAuth is a staple of modern web development. It's the magic behind the "Log in with Facebook" or "Connect to Google" buttons you see everywhere. But what exactly is it, and how does it work, especially for a JavaScript developer? Let's dive in, using GitHub as our primary example. What is OAuth? At its core, OAuth (Open Authorization) is a protocol for authorization. It allows third-party applications to access user data without needing the user's password. Instead of users sharing their password with an app, they are granted a token that the app can use to act on their behalf. This offers several benefits; the most significant is that the app doesn't need to store user passwords, which greatly reduces potential attack vectors. Although OAuth is often used interchangeably with OAuth2, they are distinct. OAuth 1.0, introduced in 2007, is the first version of the protocol. While it provided a solid method for consumers to access protected resources without user credentials, it had complexities, such as the need for cryptographic libraries for request signing. Recognizing these challenges, the community introduced OAuth2 in 2012. OAuth2 simplified many aspects, eliminating the need for cryptographic signatures and emphasizing bearer tokens, which are easier to manage. OAuth2 provides flexibility with various methods of obtaining access tokens suitable for different application types. OAuth2 Steps Explained Using GitHub To explain how OAuth2 works, it's best to describe the entire process step-by-step. It's challenging to do this without code, so we'll reference our starter.dev backend showcase, which illustrates integrating a serverless backend with GitHub as an OAuth2 provider. Although the steps below are tailored to GitHub's OAuth2 implementation, it's important to note that the core flow is consistent across most OAuth2 services. For most of these services, you'll only need to adjust elements like URLs, query parameter names, and so on. Also, please note that our starter.dev backend showcase is designed to be deployed on Netlify. As such, all the API endpoints run as Netlify functions. When running the app locally, you must prepend the URL path with /.netlify/functions/server to access these endpoints. This step is unnecessary for the deployed version; API endpoints can be accessed directly (e.g., /api/auth/signin instead of /.netlify/functions/server/api/auth/signin) due to the redirects configured in the netlify.toml file. Step 0: Creating the App on GitHub The first step is to create your app with the provider. For GitHub, this is done on the Settings / Developer Settings / OAuth Apps page. This step is essential so that the provider can identify your app and possibly manage service-level parameters, like rate limits. In the screenshot above, when registering our app on GitHub, the authorization callback URL is a local URL. This is suitable for local development. However, in production, it should be a public API endpoint accessible to GitHub, like an API endpoint on Netlify. After registering the app, you'll receive a public client ID for your app and will need to generate a client secret (which should stay private). The client secret, used alongside the client ID, helps authenticate your application when trading an authorization code for an access token. Essentially, the client secret assures GitHub that the request for an access token genuinely comes from your app and not a malicious actor. Step 1: App Sends User to GitHub for Authorization The first step in the OAuth2 flow typically involves the user clicking a "Log in with GitHub" button on our web app or something similar. This action redirects the user from the web app to the OAuth2 provider's page (in this case, GitHub). For GitHub, the base URL for such a page is https://github.com/login/oauth/authorize, followed by query parameters that provide more details about the app. These parameters usually include the client ID — a mandatory identifier for your app — and several optional parameters, such as the redirect URI (where GitHub will send the user back) and scope (defining the permissions you're requesting). In our starter.dev example, clicking the "Log in with GitHub" button should lead the user to the /api/auth/signin route in our app. This route generates the GitHub authorization URL, populating it with all the necessary query parameters, and then redirects the user to that URL using a standard HTTP 303 redirect. ` Step 2: User Grants Permission In this step, the user arrives at the provider's authorization page and sees a prompt asking if they allow your app to access the specified data. The user can either approve or decline this request. For our scenario, this page would appear as follows: If either the cancel or authorize button is clicked, GitHub will invoke the callback URL specified when registering the app on GitHub. However, if the authorize button is clicked, GitHub will also send a one-time-use code query parameter that can be used to get the access token. Step 3: App Receives an Authorization Code After the user grants permission, GitHub redirects them to the specified callback URL. Attached to this URL is a one-time-use code query parameter. ` Step 3: App Exchanges Authorization Code for Access Token With this code, the app needs to make a POST request to the GitHub API to exchange the code for an access token. As shown below, the app sends the client ID, client secret, and the one-time code to GitHub and receives the access token in return. The access token should then be persisted in a store (such as Redis) or sent to the frontend as a cookie, as shown below: ` Step 4: App Accesses User Data with the Access Token Once you have the access token, you can use it to make authorized API requests on behalf of the user. All the app needs to do is include the access token in the Authorization header. ` And that is all. As long as the access token is valid, you can access any of the API services that were granted by the user in the authorization step. Conclusion OAuth2, though appearing complex initially, provides a strong method for authentication and authorization. For JavaScript developers, knowing its process helps in easy third-party integrations, giving users a safe way to access different services. Whether using GitHub or another platform, the main concepts are the same, allowing for better web applications. Check out our starter.dev backend showcase for the full code! There's also an associated StackBlitz project if you want to play with it....

Jan 19, 2024

5 mins

GitHubJavaScriptOAuth 2

How to Go from Software Engineer to AI Engineer with Shawn Wang

Shawn Wang discusses AI engineering’s potential impact on the software development labor market and developer experience. With the rise of artificial intelligence technologies, there is an increasing demand for professionals who can bridge the gap between AI and software engineering, and engineers are looking around for guidance on how to best learn AI. Shawn emphasizes the importance of acquiring core knowledge and skills in AI engineering, highlighting the need for a systematic approach to education and development. He envisions a future where AI engineering becomes a recognized profession, with specialized training programs and certifications. He further talks about mental models for approaching AI literacy, and skill building. Shawn also discusses the use of advanced AI technology in software development. He showcases tools like GPT Vision, which can automate tasks and generate code efficiently. While acknowledging the potential of AI in enhancing productivity, Shawn emphasizes the need to leverage AI tools to augment human capabilities rather than replace them. Download this episode here....

Apr 17, 2024

1 min

Artificial IntelligenceEngineering Leadership

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

Improving INP in React and Next.js

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

OAuth2 for JavaScript Developers

How to Go from Software Engineer to AI Engineer with Shawn Wang

You might also like

Improving INP in React and Next.js

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

OAuth2 for JavaScript Developers

How to Go from Software Engineer to AI Engineer with Shawn Wang