DEV Community: Ingila Ejaz

Secure Airtable Integration: Mastering OAuth 2.0 PKCE with Node.js 22 and Angular 20

Ingila Ejaz — Mon, 28 Jul 2025 14:46:11 +0000

Integrating third-party services into B2B and SaaS applications demands robust security. When connecting to powerful platforms like Airtable, understanding their authentication mechanisms is paramount. Airtable, embracing modern security standards, utilizes OAuth 2.0 with PKCE (Proof Key for Code Exchange) for its authentication flow, a critical extension that significantly bolsters security.

Pronounced “PIX-y,” PKCE is an ingenious mechanism designed specifically to prevent authorization code interception attacks. This ensures that the application requesting the final access token is indeed the very same one that initiated the authorization process. This “proof-of-possession” is vital for safeguarding user data and maintaining application integrity, especially for public clients like single-page applications or mobile apps.

Let’s break down the core components of PKCE that make this security possible:

code_verifier: This is a high-entropy, cryptographically random secret generated by your application at the very beginning of the authorization flow. Think of it as a unique, one-time-use password that your application creates for a single login session. It's never sent directly to the authorization server (Airtable) in the initial request, remaining a secret known only to your application.
code_challenge_method: A simple string (e.g., S256) that explicitly communicates to Airtable which hashing algorithm was used to transform the code_verifier. It's essentially your application declaring: "The code_challenge I'm providing was generated using the SHA-256 hashing algorithm." This standardization allows the authorization server to independently verify the challenge.
code_challenge: This is the hashed and specially encoded version of your code_verifier. It's the only PKCE parameter sent to Airtable when your application first redirects the user to the authorization endpoint. Airtable securely stores this code_challenge temporarily. When your application later exchanges the authorization code for an access token, it must present the original code_verifier. Airtable will then re-compute the code_challenge from the code_verifier it just received and compare it against the one it initially stored. If they don't match, the token exchange is denied, effectively thwarting any unauthorized attempts. For this tutorial, we leverage Node.js's built-in crypto module, mirroring the robust practices often seen in official documentation and advanced implementations.

In the following sections, we’ll walk through the practical steps of setting up your application to authenticate with Airtable using this secure PKCE flow. We’ll be working with an Airtable base similar to this:

Step 1 — Create OAuth Integrations in Airtable

First things first, create an Airtable Integration:

Go to https://airtable.com/create/oauth
Click on Register New OAuth Integration.

On the next page, give your integration a name and redirect URL. This URL will be redirected when the authentication is successful.

Now click on Register Integration and you will be redirected to another page with your client_id and client_secret.

The client_secret is optional but recommended so go ahead and create a client_secret. Save the client_id in your .env file.

You can select the scope of access as well from the Scopes section. For now, I have selected read-based access only.

You also need to generate client_secret from the integration panel. To do this, click on Generate client secret.

Click generate on the dialog and copy the client_secret.

Note: the client_secret is only shown once so make sure you copy and paste it in a secure file.

Click on Save Changes and you should now see your integration in the integrations list:

Step 2 — Create a Backend — Node.js 22 + Express

Create New Node.js Project. I am using Node.js 22 but you are free to use any version.

mkdir airtable-integration-backend
cd airtable-integration-backend
npm init

Install the following packages as we will be using them later on:

npm install express dotenv cors crypto axios qs

#dotenv - For .env files to store client_id, client_secret, redirect_url and scope
#express - For making the http calls
#cors - For allowing cors (locally)
#crypto - To generate code_verifier, code_challenge and code_challenge_method
#axios - To call airtable APIs and fetch response
#qs - To build queryString

Next, create a new file called server.js. Your project structure should look something like this.

We will create these functions in our server.js file.

get_authorization_url — This function is designed to initiate an OAuth 2.0 authorization flow with Airtable, specifically utilizing the Proof Key for Code Exchange (PKCE) extension for enhanced security.

The primary goal of this function is to generate and return an authorization URL to the client. The client (e.g., a web browser) will then redirect the user to this URL, prompting them to grant permission to access their Airtable data. Here’s a detailed breakdown of this method:

Generates state, codeVerifier, and codeChallenge.
Stores codeVerifier (and state) in a temporary cache.
Constructs the Airtable authorization URL with all the necessary parameters, including state and code_challenge.
Sends this URL back to the client.

//Get authorization URL
app.get("/get-authorization-url", (req, res) => {
  // prevents others from impersonating Airtable
  const state = crypto.randomBytes(100).toString("base64url");

  // prevents others from impersonating you
  const codeVerifier = crypto.randomBytes(96).toString("base64url"); // 128 characters
  const codeChallengeMethod = "S256";
  const codeChallenge = crypto
    .createHash("sha256")
    .update(codeVerifier) // hash the code verifier with the sha256 algorithm
    .digest("base64") // base64 encode, needs to be transformed to base64url
    .replace(/=/g, "") // remove =
    .replace(/\+/g, "-") // replace + with -
    .replace(/\//g, "_"); // replace / with _ now base64url encoded

  // ideally, entries in this cache expires after ~10-15 minutes
  authorizationCache[state] = {
    // we'll use this in the redirect url route
    codeVerifier,
    // any other data you want to store, like the user's ID
  };

  // build the authorization URL
  const authorizationUrl = new URL(`${airtableBaseUrl}/oauth2/v1/authorize`);
  authorizationUrl.searchParams.set("code_challenge", codeChallenge);
  authorizationUrl.searchParams.set(
    "code_challenge_method",
    codeChallengeMethod
  );
  authorizationUrl.searchParams.set("state", state);
  authorizationUrl.searchParams.set("client_id", clientId);
  authorizationUrl.searchParams.set("redirect_uri", redirectUri);
  authorizationUrl.searchParams.set("response_type", "code");
  // your OAuth integration register with these scopes in the management page
  authorizationUrl.searchParams.set("scope", scope);
  res.json({ authorizationUrl: authorizationUrl.toString() });
});

get_auth_token — This method is the crucial next step in the OAuth 2.0 PKCE flow with Airtable. After a user has granted (or denied) the application permission, Airtable redirects their browser back to this endpoint.

This method is responsible for validating that redirect and then exchanging the received authorization code for actual access tokens. We can also call this as the “token exchange” phase, where the temporary authorization code is swapped for long-lived access and refresh tokens.

The core purpose of this method is to:

Validate the incoming redirect from Airtable using the state parameter to prevent CSRF.
Handle potential errors from the authorization attempt (e.g., user denied access).
Exchange the authorization_code received from Airtable for access_token and refresh_token by making a POST request to Airtable's token endpoint, securely using the code_verifier.
Respond to the client with the acquired tokens or an error.

//Get Auth token
app.get("/request-oauth-token", (req, res) => {
  const state = req.query.state;
  const cached = authorizationCache[state];
  if (cached === undefined) {
    return res
      .status(400)
      .json({ error: "This request was not from Airtable!" });
  }
  // clear the cache
  delete authorizationCache[state];

  // Check if the redirect includes an error code.
  // Note that if your client_id and redirect_uri do not match the user will never be re-directed
  if (req.query.error) {
    const error = req.query.error;
    const errorDescription = req.query.error_description;
    return res.status(400).json({ error, errorDescription });
  }

  const code = req.query.code;
  const codeVerifier = cached.codeVerifier;

  const headers = {
    // Content-Type is always required
    "Content-Type": "application/x-www-form-urlencoded",
  };
  if (clientSecret !== "") {
    // Authorization is required if your integration has a client secret
    // omit it otherwise
    headers.Authorization = authorizationHeader;
  }

  setLatestTokenRequestState("LOADING");
  // make the POST request
  axios({
    method: "POST",
    url: `${airtableBaseUrl}/oauth2/v1/token`,
    headers,
    // stringify the request body like a URL query string
    data: qs.stringify({
      client_id: clientId,
      code_verifier: codeVerifier,
      redirect_uri: redirectUri,
      code,
      grant_type: "authorization_code",
    }),
  })
    .then((response) => {
      // book-keeping so we can show you the response
      setLatestTokenRequestState("AUTHORIZATION_SUCCESS", response.data);

      res.json(response.data);
    })
    .catch((e) => {
      // 400 and 401 errors mean some problem in our configuration, the user waited too
      // long to authorize, or there were multiple requests using this auth code.
      // We expect these but not other error codes during normal operations
      if (e.response && [400, 401].includes(e.response.status)) {
        setLatestTokenRequestState("AUTHORIZATION_ERROR", e.response.data);
        res.status(e.response.status).json(e.response.data);
      } else if (e.response) {
        console.log("uh oh, something went wrong", e.response.data);
        setLatestTokenRequestState("UNKNOWN_AUTHORIZATION_ERROR");
        res
          .status(e.response.status)
          .json({ error: "Unknown error", details: e.response.data });
      } else {
        console.log("uh oh, something went wrong", e);
        setLatestTokenRequestState("UNKNOWN_AUTHORIZATION_ERROR");
        res.status(500).json({ error: "Unknown error", details: e.message });
      }
    });
});

Finally, this is how your .env should look like:

Now run the service by executing node server.js and you should see the server running successfully.

Step 3 — Frontend — Angular 20

Once the service is up and running, we create a new Angular app.

ng new airtable-integration-frontend

For my angular app, I have created these basic components:

//Template login.html

<p>Welcome to Airtable Integration!</p>
<button (click)="loginWithAirtable()">Click to Login with SSO</button>

//Login.ts
import { Component, inject } from '@angular/core';
import { Auth } from '../auth';

@Component({
  selector: 'app-login',
  imports: [],
  templateUrl: './login.html',
  styleUrl: './login.css',
})
export class Login {
  private service = inject(Auth);
  loginWithAirtable() {
    this.service.getAuthorizationURL().subscribe((response: any) => {
      window.location.href = response.authorizationUrl;
    });
  }
}

AuthCallback — To display a message “Processing OAuth…” while the app is working on generating a token in exchange of code sent by Airtable.

//Template auth-callback.html
<p>Performing OAuth...</p>

//auth-callback.ts
import { Component, inject, OnInit } from '@angular/core';
import { Auth } from '../auth';
import { ActivatedRoute, Router } from '@angular/router';

@Component({
  selector: 'app-auth-callback',
  imports: [],
  templateUrl: './auth-callback.html',
  styleUrl: './auth-callback.css',
})
export class AuthCallback implements OnInit {
  private authService = inject(Auth);
  private router = inject(Router);
  private route = inject(ActivatedRoute);

  ngOnInit() {
    const code = this.route.snapshot.queryParamMap.get('code');
    const state = this.route.snapshot.queryParamMap.get('state');
    const code_challenge_method = this.route.snapshot.queryParamMap.get(
      'code_challenge_method'
    );
    const code_challenge =
      this.route.snapshot.queryParamMap.get('code_challenge');

    if (code && state) {
      // Exchange code for token (if needed)
      this.authService.exchangeCodeForToken(code, state).subscribe({
        next: (data: any) => {
          localStorage.clear();
          localStorage.setItem('airtable_access_token', data.access_token);
          localStorage.setItem('airtable_refresh_token', data.refresh_token);
          localStorage.setItem('airtable_expires_in', data.expires_in);
          this.router.navigate(['/login-success']);
        },
        error: () => this.router.navigate(['/login-failure']),
      });
    } else {
      this.router.navigate(['/login-failure']);
    }
  }
}

LoginSuccess — Protected route and only accessible on successful authentication.

//login-success.html

<p>Logged In successfully! This is a route protected by AuthGuard.</p>
<button (click)="logout()">Logout</button>

//login-success.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-login-success',
  imports: [],
  templateUrl: './login-success.html',
  styleUrl: './login-success.css',
})
export class LoginSuccess {
  logout() {
    localStorage.clear();
    window.location.href = '/';
  }
}

LoginFailure — To redirect to in case of authentication failure. This is optional as you can just simply redirect to the /login page as well.

//login-failure.html
<p>Authentication Failed</p>

//login-failure.ts

import { Component } from '@angular/core';

@Component({
  selector: 'app-login-failure',
  imports: [],
  templateUrl: './login-failure.html',
  styleUrl: './login-failure.css',
})
export class LoginFailure {}

Here is what the routes look like:

//app.routes.ts

export const routes: Routes = [
  {
    path: '',
    component: Login,
  },
  {
    path: 'auth-callback',
    component: AuthCallback,
  },
  {
    path: 'login-success',
    component: LoginSuccess,
    canActivate: [authGuard], //Protected route via AuthGuard
  },
  {
    path: 'login-failure',
    component: LoginFailure,
  },
];

Service Integration:

We now create a new service called auth-service and integrate our endpoints we created earlier.

Create new service called auth:

ng g s auth

Create the following functions in your service.ts file:

//service.ts

import { HttpClient } from '@angular/common/http';
import { inject, Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class Auth {
  private http = inject(HttpClient);
  API_BASE_URL = 'http://localhost:3000';

  getAuthorizationURL() {
    return this.http.get(`${this.API_BASE_URL}/get-authorization-url`);
  }

  exchangeCodeForToken(code: string, state: string) {
    return this.http.get<any>(
      `${this.API_BASE_URL}/request-oauth-token?code=${encodeURIComponent(
        code
      )}&state=${encodeURIComponent(state)}`
    );
  }
}

We also need to create an authGuard to protect the route. For the sake of the demo, I am only checking if localstorage contains token, but you can be as creative as you want.

import { CanActivateFn } from '@angular/router';

export const authGuard: CanActivateFn = (route, state) => {
  return localStorage.getItem('airtable_access_token') !== null;
};

Now run the application using

ng serve --host 127.0.0.1

You should see the following screen:

The full application can be found at my Github.

Frontend: https://github.com/Ingila185/airtable-integration-frontend.git

Backend: https://github.com/Ingila185/airtable-integration-backend.git

Cracking the FAANG Code: My 2024 Google Interview Journey & Key Takeaways (with Actionable Tips!)

Ingila Ejaz — Fri, 06 Dec 2024 14:53:48 +0000

Earlier this year, I had the opportunity to interview for a role at Google. A recruiter reached out to me on LinkedIn, and after enthusiastically saying yes, I dove headfirst into preparation.

Initial Technical Assessment

While initial anxiety set in with the vast amount of material to cover, I tackled a mix of technical and non-technical questions in a 45-minute screening.

The interview commenced with standard introductions. The interviewer inquired about my professional background and past projects. Subsequently, I was presented with a series of technical questions pertaining to fundamental algorithms such as merge sort, quick sort, and binary search. The discussion extended to data structures, their optimal applications, and the associated time and space complexities of various search algorithms, including DFS and BFS. To facilitate further preparation, the interviewer provided relevant study materials and allotted a three-week timeframe for the upcoming technical interview.

I was asked about my preferred coding language and was recommended to the second round. Advancing to the technical round, I honed my coding skills (focusing on my preferred language) and prepared from LeetCode, HackerRank , W3Schools.com and CodeSignal.

Technical Interview: A Deep Dive into Graphs

The second interview was primarily focused on algorithmic problem-solving. Unlike technical interviews of other organizations where coding on an IDE is involved, this phase emphasizes clear communication of problem-solving approaches using Google docs or simple text editor. Candidates are expected to demonstrate their thought process, starting with a brute-force solution and progressing towards an optimized one.

For my second interview, I was presented with a medium-level graph problem from LeetCode. I successfully implemented the brute-force solution and discussed the potential optimizations with the interviewer before the time was out.

While I was not selected for the System Design round, this experience proved invaluable. It highlighted the specific areas where I needed improvement to successfully navigate FAANG/GAMAM/MAANG interviews.

The following key takeaways will be beneficial for anyone preparing for FAANG/MAANG/GAMAM interviews:

- Coding platforms are a stepping stone, not a silver bullet:
While coding platforms are great for building problem-solving logic, real-world problems might require different approaches. Time management is also crucial!

- Clarify, discuss, but don’t stall:
While asking questions is encouraged, striking a balance is key. Aim to reach a brute force solution, optimize it, and calculate time/space complexity within the allotted time.

- Learn from others, but find your own path: Don’t get stuck on coding problems. Utilize resources like YouTube videos to learn different approaches and broaden your problem-solving horizons. Google seeks your unique approach, not a memorized solution.

- Feedback is your friend: Request a short follow-up call with your recruiter to gain valuable insights into your interview performance.

- Rejection is a chance to grow: Google has a 6-month reapplication period. Use this time to refine your skills and come back stronger! I will be re-applying again in January 2025 and would document the process again!

I’m especially grateful to fellow Googlers who provided invaluable support, influence and guidance throughout the process. Their encouragement helped me manage interview anxiety and motivated me to keep learning.

This experience has been incredibly rewarding and most importantly, it has given me the exact picture of where I lag as a developer and I can’t wait to apply at Google with better preparation this time.

Here’s my portfolio, Github and LinkedIn for anyone who would like to stay in touch and say Hi!

Angular 19 - 5 Game-Changing Features You Need to Know

Ingila Ejaz — Wed, 06 Nov 2024 16:53:20 +0000

Angular continues to evolve, bringing exciting features with each release. Angular 19 is no exception, focusing on improving developer experience (DX) and application performance. Let's dive into five key features expected in Angular 19 that will enhance your development workflow and create smoother, faster applications.

1. Partial and Incremental Hydration

Angular's dedication to improving hydration is a welcome sight. While traditional hydration has been around, Angular 19 introduces partial hydration and incremental hydration. These features enhance DX by prioritizing the loading of critical deferred components first, leading to faster initial load times. Learn more here

Incremental hydration takes it a step further. It allows developers to defer loading certain functionalities of deferred components based on triggers and user interaction. This means the application only sends the minimum amount of Javascript initially, with additional functionalities loading based on user actions like hovering or clicking. This approach results in a noticeably faster first impression and a smoother user experience.

2. Standalone Components

For improved code reusability and overall application performance, consider using standalone components. Prior to Angular 14, all components needed to be declared within a module. This often led to boilerplate code and unnecessary overhead. Angular 14 introduced standalone components, which encapsulate both component logic and dependencies within themselves, eliminating the need for module declaration.

Angular 19 is poised to make standalone components the default option. This means that when you create a new component, it will be considered standalone by default. If you specifically want a component to be part of a module, you'll explicitly set standalone: false during creation. This shift simplifies code structure and promotes reusability across different parts of your application.

3. Zoneless Change Detection

Angular has continuously refined its change detection strategy. While Zone.js provided a solid foundation in the early days, it introduced some performance overhead and increased bundle size. To address this, Angular has introduced the experimental zoneless change detection feature, activated through provideExperimentalZonelessChangeDetection(). Read more about it here.

Zoneless change detection promises substantial benefits, including:

Improved Performance: Expect faster initial renders and smoother overall application performance.
Smaller Bundle Sizes: Reduced overhead translates to smaller application bundles, leading to faster download times.
Simpler Debugging: Zoneless change detection simplifies the debugging process by removing the complexity associated with Zone.js.

4. linkedSignal: Boosting Reactivity for a Responsive Application

linkedSignal is a new primitive designed to enhance the reactivity of Angular applications. It provides a way to create writable signals that automatically update their values based on changes in a source signal. This feature simplifies data flow and promotes a more responsive user experience. You can find more details about linkedSignal from this article.

Angular 19 is expected to introduce several overloads of linkedSignal, including:

linkedSignal with Source and Computation: This allows you to define a source signal and a computation function to determine the updated value of the linked signal.
linkedSignal Shorthand Version: This provides a simplified syntax for creating linked signals, making your code more concise and easier to maintain.

5. Resource and rxResource APIs: Streamlining Data Retrieval

Managing asynchronous data retrieval can be cumbersome. Angular 19 introduces experimental APIs – resource and rxResource – designed to simplify this process. These APIs provide a unified approach for data retrieval using both promises (resource) and Observables (rxResource). Here's what you can expect:

Resource API: This API offers three key properties:

status: Indicates the current state of the resource (loading, success, error).
value: Holds the retrieved data upon successful completion.
error: Provides an error handler for potential issues during data retrieval.

rxResource API: This API utilizes Observables to manage asynchronous data retrieval. It simplifies the handling of data streams, making it easier to control data flow and handle errors.
Both resource and rxResource APIs aim to improve the way developers interact with asynchronous data within Angular applications.

Here you can find more information about resource and rxResource API.

These are just a few of the exciting features expected in Angular 19. With its focus on DX and performance, Angular 19 promises to streamline development workflows and create faster, more responsive web applications. Stay tuned for the official release to experience these advancements firsthand!

If you liked this article, feel free to reach out to me on LinkedIn, GitHub, and maybe see my portfolio here :) I'd love to connect!

Angular 19 - Streamlining Data Retrieval with Experimental Resource and rxResource APIs

Ingila Ejaz — Wed, 06 Nov 2024 04:41:29 +0000

Angular 19 introduces two exciting experimental APIs, resource and rxResource, designed to simplify asynchronous data retrieval and management. This article explores these APIs, diving into their functionalities and showcasing how they enhance developer experience (DX) for crafting reactive and efficient Angular applications. All API endpoints used in the article are from JSON Placeholder.

Born from a Vision: Asynchronous Data Loading with `Signals`

The idea behind these APIs originated from a pull request by Alex Rickabaugh. The core concept lies in utilizing Signals to manage the asynchronous loading of resources. While resource utilizes Promises, rxResource leverages Observables, catering to different developer preferences. Both APIs provide a WritableResource object, allowing you to update resource data locally.

A resource offers several signals to keep you informed about its state:

Value: Provides the current data of the resource, representing the result of a query.
Status: Reflects the resource's current state. Here's a breakdown of the various status types:

Error: Provides details on errors encountered during data retrieval.

Creating a Resource

Instantiating a resource is simple:

This will result the following output. Notice how initially the status is "Loading" (2) and eventually it becomes "Resolved" (4).

Updating Resource Data Locally

To update a resource's data locally, leverage the update() method of the value signal. See the following template and component for reference:

The updateResource() function will update the value of resource locally with a different string.

This will produce the following output. Notice the status being "Local" (5) as it's value has been updated locally.

Refreshing a Resource

Let's create a Refresh button in our template and refresh a resource when the user clicks it.

The reload function in the code below triggers the resource loader to execute again. If user clicks Refresh button multiple times, the loader will be triggered only once until the previous request is finished. It is similar to exhaustMap in Rxjs.

Notice the status transitioning from "Reloading" (3) to "Resolved" (4) in the output below.

Data Based on Signals: Dynamic Resource Loading

Suppose you want to fetch posts based on an postId signal. You can achieve this by passing the signal as a request parameter to your endpoint:

By passing the signal postId as a request parameter, you can achieve dynamic data retrieval based on the postId value. Here's an example:

This will result in the following output:

While this approach works for initial data fetching, it lacks reactivity. Loaders in Angular's resource API are inherently untracked. This means that if a signal like postId changes after the initial resource creation, the loader won't automatically re-execute.

To overcome this limitation and ensure reactive behavior, we need to explicitly bind the signal to the resource's request parameter. This establishes a dependency between the resource and the signal, ensuring that the loader is triggered whenever the signal's value changes.

Let's create a button to update the signal postId to a random number.

Now, in the component, we add a method to update the signal postId to a random number. We also bind postId to the request parameter of our resource to ensure reactivity.

Handling Local Data Changes During Active Requests

When a local data change occurs while a resource is fetching data from a remote source, a potential race condition arises. To mitigate this, we can leverage the abortSignal() function to gracefully handle concurrent requests.

By providing an AbortSignal object to the resource's loader function, we can cancel ongoing requests if the signal is aborted. This is particularly useful when a new request is triggered before the previous one completes.

Here's a breakdown of the process:

Local Data Change: A user modifies data locally, triggering a new request.
Abort Signal: An AbortSignal is created and passed to the resource's loader.
Request Cancellation: If the previous request is still in progress, it's canceled using the AbortSignal.
New Request Initiation: The loader is invoked with the updated postId and the new AbortSignal.
Data Fetching and Update: The new request proceeds, and the resource's value is updated with the fetched data.

Here's an example which will fetch data based on new value of signal and cancel the previous request in progress in case of multiple triggers.

Multiple Signal Dependencies: Reactive Resource Loading

A resource can be made reactive to changes in multiple signals, allowing for complex data fetching scenarios. By binding multiple signals to the resource's request parameter, the loader will be triggered whenever any of the dependent signals change.

Here's an example demonstrating this behavior where both postId and userId are being set by a random number and the resource is made reactive to changes in both the signals:

In the above example, the loader will be re-executed whenever either the userId or postId signal changes. This ensures that the resource always reflects the latest data based on the current values of its dependent signals.

Code Reusability with Resource Functions

To enhance code maintainability and promote a modular approach, consider creating reusable resource functions. These functions encapsulate the logic for creating resources with specific configurations, making them easily shareable across your application.

Here's an example of a reusable resource function:

In the example above, myResource can be used across different areas of your application, ensuring clean code and reusability.

RxResource: Leveraging Observables for Reactive Data Fetching

When working with Observables in your Angular application, the rxResource API provides a powerful mechanism for managing asynchronous data operations. Similar to the resource API, rxResource allows you to define resources that fetch data and emit it as an Observable.

Key Differences from resource:

Observable-Based: rxResource leverages Observables to provide a stream of data, enabling more flexible and reactive data handling.
No abortSignal: Since Observables can be easily unsubscribed, there's no need for an explicit abortSignal to cancel requests.
First-Value-Only: The current implementation of rxResource only considers the first emitted value from the Observable. Subsequent emissions are ignored.
Writable Resources: Like resource, rxResource allows you to update the local state of a resource using Observables.

Here's an example of a resource created using rxResource:

In this example, the loader will emit the posts as an Observable. You can subscribe to this Observable to react to data changes and perform necessary actions.

Conclusion

Angular's resource and rxResource APIs represent a significant step forward in simplifying asynchronous data operations. These APIs offer a declarative and concise approach to fetching and managing data, enhancing developer productivity and application performance.

While still in developer preview, these APIs hold the promise of revolutionizing the way Angular developers handle data retrieval. By leveraging Signals and Observables, these APIs provide a flexible and efficient mechanism for managing data flow and reactivity in Angular applications.

Github PR: https://github.com/angular/angular/pull/58255
Code repository: https://github.com/Ingila185/angular-resource-demo
Stackblitz Playground: https://stackblitz.com/edit/stackblitz-starters-hamcfa?file=src%2Fmain.ts

Credits to Enea Jahollari for writing such a detailed article about resource and rxResource on Push Based.

Angular 19 - Introduction to linkedSignal

Ingila Ejaz — Sun, 03 Nov 2024 08:27:13 +0000

Angular 19 is on the horizon, and it’s bringing a host of exciting new features to the table. One of the most notable additions is the linkedSignal primitive, which promises to revolutionize the way we handle reactive programming in Angular applications.

The Problem with Reset Patterns

Traditionally, implementing reset patterns in Angular involved using computed() signals. While effective, this approach has limitations. When you need to set the value of a signal explicitly, it becomes a read-only signal, hindering flexibility.

The linkedSignal Solution

linkedSignal addresses this limitation by providing a writable signal that automatically updates its value based on changes to a source signal. This enables us to create a seamless synchronization between the two, ensuring a glitch-free user experience.

Understanding linkedSignal

While linkedSignal will have multiple overloads, two of them are worth mentioning:

linkedSignal with Source and Computation

This overload allows you to create a linkedSignal that computes its value based on the value of a source signal. Here's an example:

import { signal, linkedSignal } from '@angular/core';

  const sourceSignal = signal(0);
  const linkedSignal = linkedSignal({
    source: this.sourceSignal,
    computation: () => this.sourceSignal() * 5,
  });

In this example, linkedSignal will always be twice the value of sourceSignal. Whenever sourceSignal changes, linkedSignal will automatically recompute its value. Here’s a more real-world example of linkedSignal:

The CourseDetailComponent component accepts a courseId as input and displays the number of enrolled students. We aim to reset the student count whenever the selected courseId changes. This necessitates a mechanism to synchronize two signals: the courseId and the studentCount.

While the usage of computed() can be effective in deriving values from other signals, they are read-only. To dynamically update the studentCount based on changes in the courseId, we leverage the linkedSignal primitive. By creating a writable signal linked to the courseId, we can both set the studentCount explicitly and automatically update it whenever the courseId changes. This approach provides a robust and flexible solution for managing signal dependencies and ensuring data consistency.

linkedSignal Shorthand

For simpler scenarios, you can use a shorthand syntax to create linkedSignal:

const sourceSignal = signal(10);
const linkedSignal = linkedSignal(() => sourceSignal() * 2);

This shorthand syntax is equivalent to the first overload, but it’s more concise and easier to read.

Key Benefits of LinkedSignals

Simplified Reset Patterns: Easily implement reset patterns without the complexities of computed() signals.
Enhanced Flexibility: Maintain the ability to set signal values explicitly while ensuring automatic updates.
Improved Performance: Optimized under the hood for efficient updates.
Cleaner Code: More concise and readable code, especially for complex reactive scenarios.

Conclusion

linkedSignal is a powerful new tool in Angular's reactive toolkit. By understanding its core concepts and usage patterns, you can create more robust, responsive, and user-friendly Angular applications. With its ability to combine the best aspects of computed() and writable signals, linkedSignal is poised to become an indispensable tool for Angular developers. You can learn more about linkedSignals from this stackblitz.

Github PR: https://github.com/angular/angular/pull/58189

Core Web Vitals — Now Built-n to Chrome

Ingila Ejaz — Fri, 18 Oct 2024 05:32:02 +0000

Have you wondered what these numbers in the DevTools are?

Earlier this year, Google introduced an in-browser preview of Core Web Vitals in the DevTools. This article dives deep into what Core Web Vitals (CWV) are, why they matter and how can we improve them.

Core Web Vitals (CWV) are a new addition to the performance tab of Google Chrome. CWV are a set of metrics that Google uses to assess the overall user experience of a web page. They focus on three key aspects of performance:

Largest Contentful Paint (LCP)

LCP is the measure of how quickly the web page loads. A fast LCP indicates that the user can quickly start interacting with the most important content on the page.

According to the docs:

To provide a good user experience, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits.

Best Practices to optimize LCP:

Optimize images and reduce their file size.
Minimize render-blocking resources.
Leverage browser caching.
Improve server response times.
Use a CDN.
Learn more here.

Interactive Paint (INP)

INP is the measure of the responsiveness of the page during interactions like clicking buttons or typing in forms. A fast INP indicates that the page is responsive and doesn’t feel sluggish or unresponsive.

According to the docs:

To provide a good user experience, websites should strive to have an Interaction to Next Paint of 200 milliseconds or less.

Best Practices to Optimize INP:

Minimize JavaScript execution time.
Avoid long tasks that block the main thread.
Prioritize critical tasks and defer non-critical ones.
Optimize event handling and input processing.
Learn more here.

Cumulative Layout Shift (CLS)

CLS is the measure of the visual stability of the page, assessing how often elements shift unexpectedly after the page has loaded. An example of unexpected layouts can be found here.

A low CLS indicates that the page is visually stable and doesn’t suffer from unexpected layout shifts that can disrupt the user experience. According to the docs:

To provide a good user experience, sites should strive to have a CLS score of 0.1 or less.

Best Practices to optimize CLS:

Reserve space for dynamic content.
Avoid images without specified dimensions.
Use font-display: swap for fonts.
Minimize JavaScript-triggered layout shifts.
Learn more here.

Why are Core Web Vitals important?

User Experience: A good user experience is crucial for website success. Core Web Vitals directly impact how users perceive a website’s performance and usability.

Search Engine Ranking: Google has indicated that Core Web Vitals are a ranking factor. Websites with poor Core Web Vital scores may rank lower in search results.

Conversion Rates: A fast and stable website is more likely to convert visitors into customers.

Conclusion:

By focusing on improving Core Web Vitals, you can create a better user experience, improve your website’s search engine ranking, and increase your website’s conversion rates.

Improving Core Web Vitals including LCP and CLS with Partial Hydration in Angular 18

Ingila Ejaz — Sat, 05 Oct 2024 13:56:01 +0000

Angular 18 introduced Partial Hydration in ng-conf 2024, a powerful technique that significantly improves application performance in conjunction with Server-Side Rendering (SSR). This article dives into the concept of partial hydration, its benefits, and how it leverages deferrable views introduced in Angular 17.

According to Angular Roadmap:

We’re already seeing significant improvements to Core Web Vitals, including LCP and CLS. In lab tests, we consistently observed 45% better LCP of a real-world app.

Why Partial Hydration and SSR Matter

Traditional Angular applications often suffer from a performance bottleneck when loading all JavaScript upfront. This can significantly impact the initial load time, especially for large and performance-critical applications. By strategically reducing the amount of JavaScript loaded at the start, we can drastically enhance user experience.

Partial Hydration: A Smarter Approach to SSR

Partial hydration builds upon the foundation of deferrable views, introduced in Angular 17. Instead of rendering a simple placeholder on the server, Angular can now render the main content of a designated block marked with @defer. Here's how it works:

Server-side Rendering: The server renders the essential content of the application along with the @defer block containing the component.
Client-side Hydration: When the application runs on the client, Angular downloads the necessary JavaScript for the deferred component.
Selective Activation: The deferred component only becomes interactive when it meets specific conditions, like entering the user's viewport.

This approach offers several advantages:

Faster Initial Load Times: By deferring unnecessary JavaScript, users experience a quicker initial page load.
Improved Perception: The application feels more responsive as core functionalities are available instantly.
Reduced Data Consumption: Smaller initial JavaScript payloads translate to lower data usage.

Enabling Partial Hydration

Utilizing partial hydration is going to be straightforward as mentioned in the Angular blog. Here's a potential example:

{
  @defer (render on server; on viewport) {
    <my-deferrable-component></my-deferrable-component>
  }
}

In this example:

my-deferrable-component is rendered on the server.
Client-side, Angular downloads the required JavaScript for the component.
Interaction with my-deferrable-component only occurs when it enters the viewport, optimizing rendering and performance.

Conclusion

Partial hydration is one of the most requested features of Angular that empowers Angular developers to create performant and user-friendly applications. By strategically deferring component hydration based on user interaction or visibility, Angular 18 ensures a smooth and responsive user experience, especially for complex and data-heavy applications.

Angular Change Detection from zone.js to Experimental Zoneless

Ingila Ejaz — Thu, 19 Sep 2024 09:07:16 +0000

Change detection is a fundamental aspect of Angular, responsible for identifying and updating parts of the DOM that have changed in response to data modifications or user interactions. This process ensures that the UI remains consistent with the underlying data, enhancing user experience and application performance.

The Role of Zone.js

Historically, Angular has relied on Zone.js for its change detection mechanism. Zone.js is a JavaScript library that intercepts asynchronous operations, allowing Angular to monitor changes and trigger updates accordingly. However, the inclusion of Zone.js can add overhead to the application, particularly in scenarios with frequent asynchronous activities.

Change Detection Strategies

Angular provides two primary change detection strategies:

Default: Change detection is triggered after every lifecycle hook, such as ngOnInit or ngAfterViewInit. This strategy is straightforward but can lead to unnecessary DOM updates, especially in large applications.

@Component({
  selector: 'app-my-component',
  template: `
    <p>{{ message }}</p>
  `
})
export class MyComponent {
  message = 'Hello, world!';
}

This strategy is easier to implement, as Angular handles most of the change detection logic automatically.
The biggest challenge with this change detection strategy was that it led to unnecessary DOM updates which gets critical for large applications.

OnPush: Change detection is triggered only when input properties or asynchronous observables change. This strategy is more performant for complex components with frequent data updates but requires more manual management.

@Component({
  selector: 'app-my-component',
  template: `
    <p>{{ message }}</p>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class MyComponent {
  message = 'Hello, world!';
}

While onPush change detection strategy minimized unnecessary DOM manipulations, the biggest challenge with onPush change strategy was that the developers had to do more manual management and trigger changes manually. They had to handle change detection explicitly with changeDetectorRef.detectChanges() in certain scenarios, such as when data changes indirectly or when using mutable objects.

Angular 18 and Hybrid Change Detection: A Zone-less Approach

To address the challenges associated with Zone.js, Angular 18 introduced an experimental feature known as Hybrid Change Detection. This approach aims to eliminate Zone.js entirely, using a new change detection mechanism to detect changes and manipulate the DOM.

Enabling Hybrid Change Detection:

To enable Hybrid Change Detection, you can use the following code:

bootstrapApplication(RootCmp,
{ providers: [provideExperimentalZonelessChangeDetection()] 
}
);

This will trigger change detection in the following scenarios:

A signal is updated.
changeDetectorRef.markForCheck() is called.
An observable subscribed with the AsyncPipe receives a new value.
A component gets attached or detached.
An input is set.

Once Hybrid Change Detection is enabled, you can safely remove Zone.js from your application's polyfills.

 "polyfills": [
              "zone.js" //remove this line
            ],

Benefits of Hybrid Change Detection

Improved performance: Eliminating Zone.js reduces overhead, leading to better performance, especially in applications with numerous asynchronous operations.
Enhanced developer experience: The removal of manual change detection simplifies development and reduces the likelihood of errors.
Smaller application size: Zone.js typically adds around 13KB to the application size. Removing it can lead to a smaller bundle.

Monorepos with Nx: Why You Might Want a Single Home for All Your Code

Ingila Ejaz — Wed, 11 Sep 2024 17:33:13 +0000

Ever felt like your codebase is scattered across a million different repositories? That’s the life of a polyrepo, the traditional way of managing software development. But what if there was a better way? Enter the monorepo, a single giant repository housing all your projects and libraries.

This article dives into the world of monorepos, explores their benefits and drawbacks, and introduces NX, a powerful tool built specifically for managing these code havens.

Monorepo vs Polyrepo: Collaboration vs. Isolation

Imagine a world where each development team has its own code kingdom — a separate repository for every project. This is the essence of a polyrepo. While it offers autonomy (each team makes its own decisions), it can lead to isolation. Changes in one project might break another, simply because they haven’t been tested together.

Monorepos flip this script. They bring all your code under one roof, fostering collaboration and ensuring everyone’s on the same page (literally, in the same repository). But wait, doesn’t that sound like a tangled mess? Not quite. Monorepos allow for well-defined relationships between projects, keeping things organized even within the one big codebase.

But before you jump ship to monorepo land, remember — it’s not for everyone. It works best for organizations with a shared codebase and a strong focus on collaboration.

Monorepo Myth Busting: It’s Not a Monolith!

Don’t confuse monorepos with monoliths. Monoliths are giant, tightly coupled applications where everything’s intertwined. Monorepos, on the other hand, can house independent, loosely coupled projects. Think of it as a library full of books — each book is a project, but they’re all neatly organized on the same shelves (the monorepo).

Enter NX: Your Monorepo Management Superhero

So, you’ve decided to explore the monorepo world. Here’s where NX comes in. It’s a build system specifically designed for the unique challenges of managing these large-scale codebases. NX boasts a toolbox of features to keep your monorepo running smoothly:

Parallelize Your Workflow: Speed things up by running tasks simultaneously. No more waiting for one build to finish before starting another. Learn more here
CI Powerhouse: Improve your continuous integration performance by distributed task execution across multiple virtual machines.
Cache Like a Boss: Avoid unnecessary rebuilds with local and remote caching. Only rebuild what needs rebuilding, saving precious time.
Tame the Test Beast: Split large end-to-end tests across VMs to identify and re-run flaky tests more efficiently.
Plugin Power: NX plugins extend its functionality. Generate code, automate dependency upgrades, and enforce best practices across your organization.

The Final Verdict: Monorepos with NX — A Powerful Duo

Monorepos offer a compelling alternative to the traditional polyrepo approach, fostering collaboration and reducing the risk of breaking changes. NX, with its suite of management tools, empowers you to take full advantage of the monorepo model.

However, remember — monorepos aren’t a one-size-fits-all solution. Consider your team structure and development style before making the switch. But if collaboration and streamlined workflows are your goals, a monorepo managed by NX might just be the key to unlocking a new level of development efficiency.

Leveraging Django 5.1.1 and PostgreSQL 16 for an Efficient Geo-Targeted Rating API

Ingila Ejaz — Tue, 03 Sep 2024 17:21:14 +0000

Last week, I had a chance to dive into a case study that involved developing an HTTP-based REST API. This API's core functionality was to calculate the average rating between designated geographical locations. The locations encompassed regions, ports within those regions, and the API facilitated retrieving ratings across various combinations: port-to-port, region-to-region, port-to-region, and region-to-port.

For the backend, I selected a powerful tech stack: Django 5.1.1 with Django REST Framework (DRF) running on Python 3.12. The database of choice was a PostgreSQL 16 instance, conveniently deployed using Docker. This combination proved to be an exceptional choice, offering a seamless developer experience and impressive performance.

Django 5.1.1: A Performance Leap

It had been a while since I last utilized Django. My prior experience stemmed from the Meta Backend Developer specialization, where I employed Django 4.1, the latest version at that time.

Stepping into Django 5.1.1, a distinct sense of improvement in performance was undeniable. This solidified my appreciation for Django's exceptional Object-Relational Mapper (ORM), which continues to streamline database interactions.

PostgreSQL 16: Power Under the Hood

While the case study didn't necessitate crafting particularly complex queries, PostgreSQL 16's capabilities were nonetheless impressive. The Parallel Execution feature significantly enhanced query execution speed for various operations, including joins, aggregations, and scans. Additionally, the Bulk Data Loading feature offered a compelling solution for swift loading of large datasets using a novel binary format.

A Developer-Centric Tech Stack

The combination of Django 5.1.1, DRF, Python 3.12, and PostgreSQL 16 within a Dockerized environment culminated in a developer experience that surpassed any I've encountered with other frameworks. The overall synergy between these technologies fostered an efficient and streamlined development process.

Conclusion

In conclusion, this project served as a valuable exploration of the latest advancements in Django and PostgreSQL. The performance optimizations in Django 5.1.1, coupled with PostgreSQL 16's feature set, particularly Parallel Execution and Bulk Data Loading, make this tech stack a compelling choice for building robust and scalable REST APIs. The seamless integration within a Dockerized environment further enhances development efficiency. I highly recommend considering this combination for your next project that demands exceptional performance and a smooth developer experience.

If you want to have a look at the API, you can simply visit my github. You can also learn more about me

Building and Serving Angular Applications Across Environments with environment.ts (Angular 15+)

Ingila Ejaz — Tue, 03 Sep 2024 11:17:45 +0000

As an Angular developer, deploying your application to different environments – development (dev), user acceptance testing (UAT), and production – is a common occurrence. However, constantly changing code to cater to these environment specifics can be tedious, error-prone, and hinders efficiency.

This article outlines a step-by-step approach to building and serving your Angular application across various environments without modifying the codebase, leveraging the powerful environment.ts functionality.

Scenario:

Imagine an Angular application where the frontend interacts with backend APIs hosted on different environments. Let's explore how to create new environments, configure them, and serve/build your application based on the target environment.

Setting Up Environments:

Generate Environment Files:

Run the following command in your terminal:

ng generate environments

This creates a folder named environments within the src directory, containing an initial environment.ts file. By default, this file serves as your development environment configuration.

Defining Environment Variables:

Open environment.ts and define your development environment variables:

export const environment = {
  production: false, //Set to False for development
  apiUrl: 'http://my-dev-url' //Replace with your development URL
};

Creating Environment-Specific Files:

For UAT and Production environments, create separate files:

environment.test.ts (for UAT)
environment.prod.ts (for Production)

Add your respective UAT and Production API URLs to these files:

// environment.test.ts (UAT)
export const environment = {
  production: false,
  apiUrl: 'http://my-uat-url'
};

// environment.prod.ts (Production)
export const environment = {
  production: true,
  apiUrl: 'http://my-prod-url'
};

Utilizing Environments in Code:

To utilize the API URL within your code:

Import environment.ts:

import { environment } from './environments/environment';

Access API URL:

In your service or component, inject the environment variable:

export class MyService {
  constructor() {}
  apiUrl = environment.apiUrl;
}

Configuring angular.json for Environment-Specific Builds:

Target Configurations:

Open angular.json and locate the "configurations" section under "build". This defines build configurations for different environments.

"configurations": {
  "production": {
    // Rest of the configs
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.prod.ts"
      }
    ]
  },

"staging": {
    // Rest of the configs
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.test.ts"
      }
    ]
  },
  // ... other configurations
},

"defaultConfiguration": "production"

This instructs the Angular CLI to replace the default environment.ts with environment.prod.tsduring production builds and environment.test.ts for UAT builds.

For serving the applications on multiple environments, you can add serve configurations inside angular.json as:

"serve": {
    "builder": "@angular-devkit/build-angular:dev-server",
    "options": { … },
    "configurations": {
      "development": {
        // Use the `development` configuration of the `build` target.
        "buildTarget": "my-app:build:development"
      },
      "staging": {
        // Use the `development` configuration of the `build` target.
        "buildTarget": "my-app:build:staging"
      },
      "production": {
        // Use the `production` configuration of the `build` target.
        "buildTarget": "my-app:build:production"
      }
    },
    "defaultConfiguration": "development"
  },

Building and Serving for Specific Environments:

Build for production:

To build your application for production, use:

ng build --configuration=production

Use the name of the configuration defined in angular.json (production, staging in our scenario)

Serve for UAT:

To serve your application for UAT, use:

ng serve --configuration=staging

Conclusion

Employing environment-specific configurations significantly enhances the developer experience. It offers a clean and maintainable approach, streamlining application deployment across diverse environments and ultimately reducing the mean time to production (MTTP).

Also, if you enjoyed reading this article, you can learn more about me here.

Angular 18.2: Enhanced Template Syntax and Streamlined Migrations

Ingila Ejaz — Wed, 21 Aug 2024 23:43:15 +0000

Angular 18.2 has arrived, and while it may be a minor release, it holds some valuable improvements that enhance developer experience. This article delves into these exciting features, focusing on the refined @let syntax and the introduction of new migration schematics.

@let Improves

The @let syntax, a personal favorite among many Angular developers, continues to evolve in 18.2. It offers two distinct approaches to defining template variables, bringing greater flexibility and readability to your code:

Dynamic @let: Embrace the ability to utilize template reference variables within @for and @if directives. Imagine effortlessly accessing a form's value within the template:

<input #myForm name="my-from" [maxlength]="maxLength" />
@let formValue = myForm.value

Async @let: In previous versions, accessing the latest value emitted from an observable required an ngIf directive.

@if ({ tasks:  tasks$ | async }; as taskData) {

//shows the @if block before the 1st tasks$ emit
 @for (task of taskData.tasks; track task.id) {
    [...]
  } @empty {
    No Tasks pending.
  }
}

Now, achieve the same result with fewer lines and improved clarity

@let tasks = tasks$ | async;
@for (task of tasks; track task.id) {
  [...]
}
@empty {
  No Tasks pending.
}

Remember, @let variables are read-only and cannot be reassigned. However, their values will automatically update with each change detection cycle. While using the same names within the template and class component is technically possible, the long-term implications of this practice require further exploration.

Migration Made Easy: New Schematics in Town

Starting with Angular 17, we encountered three primary migration schematics:

Template syntax control flow: ng g @angular/core:control-flow
New app builder: ng update @angular/cli --name use-application-builder
Standalone components: ng g @angular/core:standalone

Angular 18.2 expands this toolkit with even more helpful tools:

Standalone component route conversion: Craft lazy-loaded routes from standalone components with ease using ng g @angular/core:route-lazy-loading.
DI migration: Simplify the transition from constructor-based dependency injection to the new functional inject() approach with ng g @angular/core:inject-migration.

Conclusion and Looking Ahead

Angular 18.2 may be a minor release, but it offers significant improvements for those who enjoy working with @let and appreciate streamlined migration processes. As we eagerly anticipate the major features planned for Angular 19 in November 2024, version 18.3, arriving in the next six weeks, promises to be another exciting stepping stone. So, keep calm, keep coding, and embrace the advancements in Angular!

DEV Community: Ingila Ejaz

Secure Airtable Integration: Mastering OAuth 2.0 PKCE with Node.js 22 and Angular 20

Step 1 — Create OAuth Integrations in Airtable

Step 2 — Create a Backend — Node.js 22 + Express

Step 3 — Frontend — Angular 20

Service Integration:

Cracking the FAANG Code: My 2024 Google Interview Journey & Key Takeaways (with Actionable Tips!)

Initial Technical Assessment

Technical Interview: A Deep Dive into Graphs

Angular 19 - 5 Game-Changing Features You Need to Know

1. Partial and Incremental Hydration

2. Standalone Components

3. Zoneless Change Detection

4. linkedSignal: Boosting Reactivity for a Responsive Application

5. Resource and rxResource APIs: Streamlining Data Retrieval

Angular 19 - Streamlining Data Retrieval with Experimental Resource and rxResource APIs

Born from a Vision: Asynchronous Data Loading with Signals

Creating a Resource

Updating Resource Data Locally

Refreshing a Resource

Data Based on Signals: Dynamic Resource Loading

Handling Local Data Changes During Active Requests

Multiple Signal Dependencies: Reactive Resource Loading

Code Reusability with Resource Functions

RxResource: Leveraging Observables for Reactive Data Fetching

Key Differences from resource:

Conclusion

Angular 19 - Introduction to linkedSignal

The Problem with Reset Patterns

The linkedSignal Solution

Understanding linkedSignal

Key Benefits of LinkedSignals

Conclusion

Core Web Vitals — Now Built-n to Chrome

Largest Contentful Paint (LCP)

Interactive Paint (INP)

Cumulative Layout Shift (CLS)

Why are Core Web Vitals important?

Conclusion:

Improving Core Web Vitals including LCP and CLS with Partial Hydration in Angular 18

Why Partial Hydration and SSR Matter

Partial Hydration: A Smarter Approach to SSR

Enabling Partial Hydration

Conclusion

Angular Change Detection from zone.js to Experimental Zoneless

The Role of Zone.js

Change Detection Strategies

Angular 18 and Hybrid Change Detection: A Zone-less Approach

Enabling Hybrid Change Detection:

Benefits of Hybrid Change Detection

Monorepos with Nx: Why You Might Want a Single Home for All Your Code

Monorepo vs Polyrepo: Collaboration vs. Isolation

Monorepo Myth Busting: It’s Not a Monolith!

Enter NX: Your Monorepo Management Superhero

The Final Verdict: Monorepos with NX — A Powerful Duo

Leveraging Django 5.1.1 and PostgreSQL 16 for an Efficient Geo-Targeted Rating API

Django 5.1.1: A Performance Leap

PostgreSQL 16: Power Under the Hood

A Developer-Centric Tech Stack

Conclusion

Building and Serving Angular Applications Across Environments with environment.ts (Angular 15+)

Scenario:

Setting Up Environments:

Utilizing Environments in Code:

Building and Serving for Specific Environments:

Conclusion

Angular 18.2: Enhanced Template Syntax and Streamlined Migrations

@let Improves

Migration Made Easy: New Schematics in Town

Conclusion and Looking Ahead

Born from a Vision: Asynchronous Data Loading with `Signals`