DEV Community: Hamed Fatehi

Demystifying OAuth 2.0 with a Clubbing Analogy

Hamed Fatehi — Tue, 26 Mar 2024 12:07:57 +0000

Understanding OAuth 2.0 authentication can be complex. To simplify, we compare it to a club night out, using Google OAuth 2.0 as our example. This analogy will help demystify how applications authenticate users and manage access. Let's break down this process into more relatable terms.

Key Technical Terms and Their Club Night Out Analogies

Technical Term	Analogy
Client ID	Akin to an event flyer with a QR code that gets you started on your journey to the club.
Client Secret	Similar to a secret passphrase given to the club's entrance (the backend) by the club's partner (Google), ensuring that the entrance is authorized to request VIP passes on behalf of guests.
Google OAuth	Comparable to the special pass system managed by the club's partner, verifying your identity and granting access.

Clarifications

Where does the Client Secret come from? The Client Secret is provided by Google when the application is registered with Google's OAuth system. It's like when the club's entrance (the backend of the application) gets a secret passphrase directly from the club's partner (Google) as proof of their partnership and authorization to request VIP passes.
Why does the backend have a Client Secret at all? The backend holds the Client Secret to prove its identity and authorization to Google. It's necessary because it ensures that not just anyone can request access tokens on behalf of the application. Think of it as a way to prevent unauthorized parties from acting as the club's entrance and requesting VIP passes without proper authorization.

Authentication Flow and Club Night Out Analogy Explanation

Authentication Flow Steps	Club Night Out Analogy
1. Redirect to Google OAuth Page: Frontend (F) directs the user to Google's OAuth 2.0 authentication page.	1. Heading to Google Club Partner's Booth: You follow the instructions (like a QR code on a flyer) to go to the Google Club Partner's booth to start the access process.
2. User Grants Access: User agrees to grant the application access to specified data on the consent screen.	2. Showing Your ID at the Booth: You show your ID (Google credentials) at the booth, allowing Google to verify who you are, similar to giving consent for a VIP status check.
3. Auth Code via /auth/google/redirect: Google redirects the user back to the application with an authorization code.	3. Receiving a Special Code: Google verifies your ID and gives you a special code, like a temporary VIP pass, to take to the club's entrance.
4. Exchange Code with Token: The backend receives the code and sends it back to Google, alongside the clientID and clientSecret for authentication.	4. Exchanging the Code at the Club Entrance: You present the special code at the club's entrance. The entrance then uses the secret passphrase (clientSecret) to prove to Google that it's authorized to request the actual VIP pass.
5. Token Response: Google validates the authorization code, clientID, and clientSecret, then sends an access token back to the application.	5. Getting the Pass: Google recognizes the passphrase, validating the club's entrance request, and issues the actual VIP pass (access token).
6. Create JWT Token: The backend generates a JWT for the authenticated user using the access token.	6. Creating Your VIP Badge: With the VIP pass received, the club's entrance creates a VIP badge for you, symbolizing your verified access.
7. Set JWT Token in Cookie and Redirect: The backend places the JWT in an HTTP-only cookie and redirects the user to the dashboard on the Frontend.	7. Entering the Club: With the VIP badge (the JWT in a cookie), you're granted entry into the club, ready to enjoy its exclusive amenities.

Now lets have a look at the technical sequence diagram of the OAuth Authentication flow and see if we can understand it better:

Hopefully it is now more clear :)

For a deeper dive into Google OAuth 2.0, check out this Google Developers post.

Thanks for reading!

As always, I appreciate any feedback. 🍺

How to Implement Micro Frontends Using SystemJS: A Comprehensive Guide

Hamed Fatehi — Tue, 19 Mar 2024 09:55:10 +0000

In the ever-evolving landscape of web development, the need for scalable, maintainable, and flexible architectures has never been greater. Enter micro frontends, a design approach that breaks down the frontend monolith into smaller, more manageable pieces. Much like microservices have revolutionized backend development by decomposing complex applications into smaller services, micro frontends aim to achieve the same for the user interface. The benefits of this approach are manifold:

Scalability: By breaking down the frontend into smaller units, teams can scale development processes more efficiently.
Independence: Different teams can work on different parts of the frontend simultaneously without stepping on each other's toes.
Flexibility: It's easier to experiment with new technologies or frameworks when you're working with a smaller piece of the puzzle.
Resilience: A failure in one micro frontend doesn't necessarily bring down the entire application.
Reusability: Components or entire micro frontends can be reused across different parts of the application or even different projects.

Given these advantages, it's tempting to dive right into micro frontends. However, it's crucial to understand the architectural choices available and their implications. Broadly speaking, there are two prevalent approaches:

1.Central Orchestrator Model: In this approach, there's a primary application that acts as the orchestrator. It's responsible for mounting and unmounting micro frontends based on user interactions or other triggers. This centralized control can simplify state management and inter-micro frontend communication. However, a significant challenge arises when different micro frontends use different frameworks. Even varying versions of the same framework can pose integration challenges. Consistency in technology choices becomes essential for smooth operation.

2.Route-Driven Fragmentation: Here, the main application is stripped down to its bare essentials, primarily handling routes. Each route or link corresponds to a micro frontend, making this approach particularly suitable for dashboards or applications where each view is distinct. The primary advantage is the flexibility it offers. Since each micro frontend is loaded independently based on routes, there's greater freedom in choosing frameworks or technologies for each one. Teams can pick the best tool for the job without being constrained by the choices of other micro frontends.

State Management in Micro Frontends

State management is a cornerstone of any frontend application, determining how data flows, is stored, and is manipulated. When diving into the realm of micro frontends, the challenge amplifies, given the distributed nature of the architecture. Let's explore how state management varies between the two primary micro frontend architectural approaches.

Central Orchestrator Model

In this approach, the overarching application acts as the central hub, making it conducive to employ a centralized state management system. Tools like Redux, Vuex, or NgRx can be seamlessly integrated, allowing for a unified store that holds the global state.

Programmatic State Passing: The main application can pass down relevant parts of the state to individual micro frontends as they are mounted. Depending on the framework, this can be achieved through props, context, or other mechanisms. This ensures that each micro frontend has access to the data it needs without being overwhelmed by the entirety of the global state.
Modularity with Centralization: Even though the state is centralized, it doesn't mean everything is lumped together. Middleware, actions, reducers, or equivalent constructs can be organized around individual micro frontends. This ensures modularity and maintainability while benefiting from a unified data store.

Route-Driven Fragmentation

Given the isolated nature of micro frontends in this approach, state management tends to be more decentralized.

URL Params: State relevant to navigation or user interface settings can be encoded in the URL. This allows for deep linking, where users can bookmark or share specific application views. For instance, a dashboard's filter settings might be represented as URL parameters, ensuring consistent views upon navigation.
Global Window Variables: While not always recommended due to potential risks like accidental overwrites, global window variables can serve as a mechanism to share state or functions between micro frontends. However, care must be taken to ensure encapsulation and avoid naming collisions.
External State Stores: To achieve a shared state without relying on the main app, micro frontends can resort to external state stores or services. Backend APIs, browser databases like IndexedDB, or even cloud-based real-time databases can be employed. This allows micro frontends to fetch and update shared state independently.

In essence, while the "Central Orchestrator Model" approach leans towards a more centralized state management system, the "Route-Driven Fragmentation" approach demands a more decentralized and strategic approach to handle state. Both methods come with their set of challenges and advantages, and the choice largely depends on the specific needs of the application and the preferences of the development team.

Technical Implementation

In the realm of Micro Frontends, whether you opt for the Central Orchestrator Model or the Route-Driven Fragmentation approach, the technical implementation plays a crucial role. There are several interesting options available, from Import Maps for controlled module loading to leveraging the dynamic module capabilities of SystemJS. Module Federation offers a way to seamlessly share dependencies across builds, while Single SPA provides a comprehensive solution specifically designed for managing Micro Frontends and often suggests using SystemJS for optimal module loading. Each of these options has its own pros and cons.

I conclude this article with an example, demonstrating how to use SystemJS to implement Micro Frontends without additional frameworks. The advantage of SystemJS over Webpack Module Federation is that it does not bind you to a specific bundler.

Structure of the Micro Frontend: The Micro Frontend defines two functions, mount and unmount in src/main.tsx, which enable the main application to control the loading and unloading of the Micro Frontend.



// src/main.tsx
let rootInstance: Root | null = null;

export function mount(containerId: string, token: string) {
  const container = document.getElementById(containerId);
  if (!container) {
    console.error(`Container with id "${containerId}" not found.`);
    return;
  }

  initializeFirebase(token);
  rootInstance = createRoot(container);
  rootInstance.render(
    <ChatPartnerProvider>
      <App />
    </ChatPartnerProvider>
  );
}

export function unmount(containerId: string) {
  if (rootInstance) {
    rootInstance.unmount();
    rootInstance = null;
  } else {
    console.error(`Application not mounted to "${containerId}"`);
  }
}

Dynamic Loading through the Main Application: The main application uses SystemJS to dynamically load the Micro Frontend. The loadMicroFrontend function loads the bundled Micro Frontend from a Google Cloud Storage Bucket.



let microFrontendPromise: Promise<any> | null = null;
export type MicroFe = {
  mount: (containerId: string) => void,
  unmount: (containerId: string) => void,
};

export const loadMicroFrontend = async (): Promise<MicroFe | undefined> => {
  if (!microFrontendPromise) {
    microFrontendPromise = System.import("https://some-bucket.com/chat-micro-fe/main-chat-fe.js")
      .then((module) => {
        return { ...module };
      })
      .catch((err) => {
        microFrontendPromise = null;
        throw err;
      });
  }

  return microFrontendPromise;
};

Integration and Control by the Main Application: The MicroFrontend component in the main application uses useEffect to mount the Micro Frontend upon loading and to unmount it upon removal.



export default function MicroFrontend({ containerId }: MicroFrontendProps) {
  useEffect(() => {
    let microFe: MicroFe | undefined;
    const loader = async () => {
      microFe = await loadMicroFrontend();
      microFe && microFe.mount(containerId);
    };
    loader();

    return () => microFe && microFe.unmount(containerId);
  }, [containerId]);

  return <div id={containerId} />;
}

Handling Shared Dependencies: The main application's HTML document provides shared dependencies through a systemjs-importmap.



<!DOCTYPE html>
<html lang="en">
<head>
  <script type="systemjs-importmap">
    {
      "imports": {
        "react": "/react.development.js",
        "react-dom": "/react-dom.development.js",
        "@mui/material": "/material-ui.production.min.js"
      }
    }
  </script>
</head>
<body>
  ...
</body>
</html>

As always, I'm grateful for any feedback.

Cheers,
Hamed

Delete-me

Hamed Fatehi — Wed, 11 Oct 2023 21:40:33 +0000

Delete-me

CSS-in-JS: Comparing compile-time and runtime approaches

Hamed Fatehi — Fri, 12 May 2023 15:19:16 +0000

Integrating CSS into JavaScript, also known as CSS-in-JS, has become an increasingly popular approach in web development in recent years. Styles are defined directly within JavaScript code. In the context of CSS-in-JS, run-time methods generate styles at application runtime, while compile-time methods generate styles during the build process.



// linaria (Compile Time CSS extraction):
<style type="text/css" data-vite-dev-id="/src/App_1k77ml9.css">
    .t1uehvp8{color:var(--t1uehvp8-0);}
</style>
<h1 class="t1uehvp8" style="--t1uehvp8-0:#0f0;">
    Hello World!
</h1>

In the compile-time approach (here Linaria), the CSS code is generated and extracted during the build process. The resulting CSS class (here .t1uehvp8) is inserted into the HTML code in the <style> tag, while the component is given a class with the generated class name. A custom CSS variable (here --t1uehvp8-0) is also used here to enable dynamic values.



// styled-components (Runtime Styling)
<style data-styled="active" data-styled-version="5.3.10">
    .bpatyH{color:#f00;}
</style>
<h1 color="#f00" class="sc-bgqQcB bpatyH">
    Hello World !
</h1>

In contrast, the runtime approach (styled components here) generates the CSS code at runtime of the application. The resulting CSS class (here .sc-bgqQcB bpatyH) is dynamically created and assigned to the component. The CSS code is not pre-inserted in the HTML code, it is added at runtime. (for this example I set SC_DISABLE_SPEEDY = true so that the styles are visible in the DOM. More about speedy mode )

Benefits of CSS-in-JS

Before we dive into comparing runtime and compile-time approaches, let me first explain the general benefits of CSS-in-JS.

Encapsulation (Scoped CSS): CSS-in-JS allows for the isolation of styles at the component level, reducing the risk of style conflicts and unwanted side effects.
Dynamic styling: Because styles are defined directly in JavaScript, they can be easily created dynamically and changed based on application data or user interaction.
Ease of maintenance: The tight coupling of components and their associated styles makes it easier to find and update styles, especially in larger projects.
Dead Code Elimination: With CSS-in-JS, only the CSS code that is actually used is included in the application, which leads to a reduction in unused code and better performance.
Component-based design (colocation): Integrating styles into JavaScript components encourages the development of modular and reusable user interfaces.

Advantages of runtime solution

Here I use Styled-Components as an example. But most of the similar libraries share these properties. I'm just listing the benefits. For more information see the Styled-Components documentation.

Automatically critical CSS
No class name bug
Easier deletion of CSS
Simple dynamic styling
Painless maintenance
Automatic vendor prefixing

But like (almost) everything else in life, good things come at a price.

Welcome to the Dark Side

I read this article a while ago: Why We're Breaking Up with CSS-in-JS . It was written by the developer of Emotion (Emotion is runtime like styled-components). In short, the author calls the following disadvantages:

CSS-in-JS increases run-time overhead: when components are rendered, the CSS-in-JS libraries have to convert their styles into plain CSS that can be injected into the document. This consumes additional CPU cycles and can affect the performance of your application.
CSS-in-JS increases the size of your bundle: Every user who visits your website must now download the JavaScript for the CSS-in-JS library. Emotion is 7.9 kB minzipped and Styled-Components is 12.7 kB. Both libraries aren't huge, but it adds up.
Frequently injecting CSS rules forces the browser to do a lot of extra work: the runtime CSS-in-JS libraries work by injecting new style rules when components are rendered, and at a fundamental level this is bad for performance
CSS-in-JS confuses the React DevTools: for each element using the CSS property renders emotion <EmotionCssPropInternal> and <Insertion> components. If you use the CSS property on many elements, Emotion's internal components can mess up the React DevTools.

In the end, the author suggests using Sass modules and utility classes instead, as the runtime performance cost of Emotion far outweighs the developer experience (DX) benefits.

There is also a nice article that compares CSS and CSS-in-JS in a real application. Let's look at some charts from this article:

Lighthouse performance audit:

Performance profiling:

I also created a dummy react app that renders 3000 colored boxes and 3000 colored short texts. In this app, you can change the theme with a click of a button. Below is the interactivity test of Linaria (a compile time library) and styled components. The test was recorded when you click the "Theme change" button. The result shows a dramatic difference in performance. But as you know, this was an exaggerated example to show the difference.

Styled-Component (Runtime-Time CSS-in-JS) Interaction duration : 3.312 ms

Linaria (Compile-Time CSS-in-JS) Interaction duration : 528 ms

Compile-time CSS-in-JS

Compile-time CSS-in-JS tools like Linaria offer an intermediate solution between pure CSS-based solutions and runtime CSS-in-JS approaches. Linaria combines the best of both approaches by generating the CSS classes at compile time and extracting them into separate CSS files instead of generating them at runtime. This makes it possible to avoid the performance penalties of runtime CSS-in-JS solutions while retaining the benefits of component isolation and dynamic style matching.

Advantages are:

No Runtime Overhead: Compile-time CSS-in-JS solutions generate static CSS, eliminating the need for JavaScript to handle styles at runtime. This reduces CPU load and improves performance.
Smaller bundle size: Since the CSS code is extracted at compile time, no additional JavaScript library is required at runtime. This results in a smaller bundle size and faster loading times.
Cleaner React DevTools: Since the styles are extracted into static CSS and no additional components are created at runtime, the React DevTools view remains tidy and uncluttered.
Optimum browser performance: Static CSS extraction prevents the browser from constantly having to calculate new CSS rules, since the styles are already generated at compile time. This leads to better browser performance.
Simplified Server-Side Rendering (SSR): Since the CSS code is static, there are fewer problems using SSR. Static extraction avoids potential complications that might arise with dynamic CSS-in-JS solutions.
Improved browser caching: Since the extracted style files are separate, they can be cached more effectively by the browser. Even if the JavaScript changes, the static CSS files can still remain in the cache, resulting in faster load times and a better user experience.

What about SSR (Server Side Rendering)?

Almost all CSS-in-JS libraries support SSR , even the compile-time libraries. For example, Styled-Components uses ServerStyleSheet to generate critical css on the server, which can be made available to the client in a blocking request. This avoids the Flash of Unstyled Content (FOUC).

This screenshot from a NextJS application using styled components with ServerStyleSheet shows how style tags are extracted and made available to the client:

Styled components with ServerStyleSheet:

This feature could, to some extent, compensate for the lack of generated CSS at compile time. A major benefit of extracted CSS before runtime is that you can use tools like critical or penthouse to automatically extract the critical CSS (above the fold) and serve only that style via a blocking request, while the rest asynchronously in the background is loaded.

Conclusion

The following points are the most important findings:

CSS-in-JS compile-time methods seem to perform better, especially on low-powered devices.
The migration from a runtime to a compile-time solution can take place step by step and component by component. Tools like Linaria provide syntax similar to SC to smooth the way for migration.
One should only switch from the build-time to the compile-time solution when performance becomes a bottleneck. In many cases, end users may not notice the improvements.
Compile-time solutions require requests to get the style files. Therefore, it is important to think about a good caching mechanism. This is especially important on first-time visits, as there is no cache for style files in the browser.

Side note: This text focused on CSS-in-JS. Of course there are many other tools like utility first classes (e.g. Tailwind) that don't involve JS in styling. Other frameworks like Angular also take a similar approach, combining Sass and component-level styling. From experience I can say CSS-in-JS provides better DX. Writing complex logic in Scss could be much harder than doing it in JS. But again, in your case the styling might not need such level of dynamics.

Styling in general is evolving, and there are many ways of thinking. Let me know what tools you use in your projects. 😇

Thank you for reading and, as always, I appreciate your feedback. 🥳

Cover Photo: Dall-E (Oil pastel drawing of 2 aliens putting makeup on each other)

When Direct DOM Manipulation Outperforms React State Management

Hamed Fatehi — Mon, 17 Apr 2023 16:22:00 +0000

Introduction:

Optimizing performance is a critical aspect of developing web applications with React. To demonstrate various techniques for improving React performance, we'll use a scroll progress bar as a real-world example. In this article, we'll explore three different approaches to implementing a scroll progress bar. We start with the worst and move are way up to the most performant approach.

1.The Ugly Way:

In this initial approach, we place the scroll logic directly in the parent component and use useState. Although this may seem straightforward, it can lead to unnecessary re-renders of the parent component and its children.

// ParentComponent.js
function ParentComponent() {
  const [scrollProgress, setScrollProgress] = useState(0);

  const handleScroll = () => {
    const scrollTop = document.documentElement.scrollTop;
    const windowHeight = window.innerHeight;
    const docHeight = document.documentElement.scrollHeight - windowHeight;
    const scrollPercentage = (scrollTop / docHeight) * 100;
    setScrollProgress(scrollPercentage);
  };

  useEffect(() => {
    console.log("Parent component rendered");
    window.addEventListener('scroll', handleScroll);
    return () => window.removeEventListener('scroll', handleScroll);
  }, []);

  return (
    <div>
      <h1>Parent Component</h1>
      <ProgressBar progress={scrollProgress} />
      <ChildComponent />
    </div>
  );
}

function ChildComponent() {
  console.log("Child component rendered");
  return <p>Child Component</p>;
}

In this example, every time the user scrolls, the parent component and its children are re-rendered.

2. The Bad Way:

A better approach is to encapsulate the scroll logic and state within a separate ScrollProgressBar component. By doing so, we isolate the re-rendering of the progress bar from the rest of the application.

// ScrollProgressBar.js
function ScrollProgressBar() {
  const [scrollProgress, setScrollProgress] = useState(0);

  const handleScroll = () => {
  // ... same as the previous example
  };

  useEffect(() => {
    console.log("ScrollProgressBar rendered");
    // ... same as the previous example
  }, []);

  return <ProgressBar progress={scrollProgress} />;
}

// ParentComponent.js
function ParentComponent() {
  console.log("Parent component rendered");
  return (
    <div>
      <h1>Parent Component</h1>
      <ScrollProgressBar />
      <ChildComponent />
    </div>
  );
}

function ChildComponent() {
  console.log("Child component rendered");
  return <p>Child Component</p>;
}

Although this method eliminates the unnecessary re-renderings of unrelated components (specially when they are not memoized), still each scroll event triggers a re-render of the ScrollProgressBar component itself, which could be avoided. See the last part to find out how:

3. The Good Way:

The most performant approach is to directly manipulate the DOM without using useState. This eliminates unnecessary re-rendering altogether.

// ScrollProgressBar.js
function ScrollProgressBar({ color }) {
  const progressRef = useRef(null);   

  useEffect(() => {
    console.log("ScrollProgressBar mounted");

     if (!progressBarRef.current) {
        return null;
     } 
     const handleScroll = () => {
        const scrollTop = document.documentElement.scrollTop;
        const windowHeight = window.innerHeight;
        const docHeight = document.documentElement.scrollHeight - windowHeight;
        const scrollPercentage = (scrollTop / docHeight) * 100;
        progressRef.current.style.width = `${scrollPercentage}%`;
     };

    window.addEventListener("scroll", handleScroll);
    return () => window.removeEventListener("scroll", handleScroll);
  }, []);

  return (
    <div
      ref={progressRef}
      style={{ width: "0%", height: "5px", backgroundColor: color }}
    />
  );
}

// ParentComponent.js
function ParentComponent() {
  console.log("Parent component rendered");
  return (
    <div>
      <h1>Parent Component</h1>
      <ScrollProgressBar color="red" />
      <ChildComponent />
    </div>
  );
}

function ChildComponent() {
  console.log("Child component rendered");
  return <p>Child Component</p>;
}

In this final example, the ScrollProgressBar component's DOM is manipulated directly, avoiding unnecessary re-renders. The console.log statements show that the parent and child components are not re-rendered during scrolling, ensuring optimal performance.

Conclusion:

It's essential to keep in mind that while React's state management is convenient and powerful, there are situations where direct DOM manipulation can lead to better performance, especially when dealing with frequently updating elements and heavy parent components with complex logic. Always consider the trade-offs between convenience and performance when deciding on an approach to optimize your application.

A Developer's Guide to Mastering SEO [Part 1]- Title, Description, Canonical & Robots Tags

Hamed Fatehi — Mon, 17 Apr 2023 11:30:34 +0000

Introduction: As a developer, understanding and implementing essential SEO tags is crucial for improving a website's visibility and performance in search engine results. In this article, we will delve into four key tags: Title, Meta Description, Canonical, and Robots Meta, explaining their purpose, how they contribute to SEO, and providing examples for each.

Title-Tag

Why it exists: The title tag defines the title of a webpage, which is displayed in search engine results pages (SERPs) and browser tabs. It is a critical element for both user experience and SEO, as it gives users and search engines a concise summary of the page's content.

How it helps SEO: A well-crafted title tag improves click-through rates, as users are more likely to click on a result with a relevant and engaging title. Additionally, search engines use title tags to understand the topic and context of a page, which can influence rankings.

Example:

<head>
  <title>Web Development Tips & Best Practices | YourSite</title>
</head>

Meta-Description

Why it exists: The meta description tag provides a brief summary of a webpage's content, which is displayed below the title in SERPs. This summary helps users determine the relevance of the page to their query.

How it helps SEO: While meta descriptions are not a direct ranking factor, they can significantly impact click-through rates. An informative and enticing description can attract more clicks, signalling to search engines that the page is relevant and valuable to users.

Example:

<head>
  <meta name="description" content="Discover the latest web development tips, best practices, and expert advice to help you create user-friendly, responsive, and SEO-friendly websites.">
</head>

Canonical-Tag

Why it exists: The canonical tag is used to indicate the preferred version of a webpage when multiple versions exist. This can help prevent duplicate content issues, which can dilute the value of the original content and confuse search engines.

How it helps SEO: By specifying a canonical URL, you help search engines consolidate the link equity of various versions of a page, which can improve the ranking of the preferred version. It also ensures that search engines index and display the correct version in SERPs.

Example:

<head>
  <link rel="canonical" href="https://www.yoursite.com/blog/web-development-tips">
</head>

Canonical tags are important for SEO because Google doesn’t like duplicate content. It makes it harder for them to choose which version of a page to index and rank, and where to consolidate any “link equity.” Too much duplicate content can also affect your “crawl budget”.

Robots-Meta-Tag

Why it exists: The Robots Meta Tag provides instructions to search engine crawlers on how to handle the indexing and following of links on a webpage. This tag is particularly useful for managing crawl budgets, preventing sensitive or duplicate content from being indexed, and controlling how search engines interact with your site.

Robots Meta Tag Attributes

There are several key attributes that can be used within the Robots Meta Tag to guide search engine behavior:

- index / noindex:
These directives determine whether search engines should index a page or not. By default, all pages are assumed to be indexable unless specified otherwise using the "noindex" attribute.

- follow / nofollow:
These directives control whether search engine crawlers should follow the links on a page. By default, all links are assumed to be followed unless specified otherwise using the "nofollow" attribute.

- noarchive:
This directive tells search engines not to store a cached copy of the page.

- nosnippet:
This directive prevents search engines from displaying a text snippet or a video preview in search results.

- notranslate:
This directive asks search engines not to offer a translated version of the page in search results.

- noimageindex
: This directive tells search engines not to index images on the page. One use case for the noimageindex parameter is when you have images on your website that you do not want to appear in image search results. For example, you might have images that are only relevant to users who are already on your website and would not make sense out of context. By using the noimageindex parameter, you can prevent these images from appearing in image search results and potentially confusing users.

- unavailable_after:
This directive specifies a date and time after which the page should no longer be indexed.

Example:

<head>
  <meta name="robots" content="noindex, nofollow, noarchive">
</head>

In this example, the Robots Meta Tag tells search engines not to index the page, not to follow any links on it, and not to store a cached copy.

Implementation Best Practices

Use the Robots Meta Tag when you want to control the indexing and following behavior of specific pages. For broader site-wide rules, consider using a robots.txt file.

Be cautious when using the "noindex" and "nofollow" directives. Overusing these directives can lead to important content not being indexed or crawled, which can negatively impact your site's search engine performance.

Combine multiple directives in a single Robots Meta Tag using commas, as shown in the example above.

Remember that the Robots Meta Tag is not a security measure. While it can prevent certain pages from appearing in search results, it does not guarantee complete privacy. Sensitive content should be protected with appropriate access controls.

Moz. (n.d.). Meta Robots Tag: An SEO Guide to Using the Robots Meta Tag.

Yoast. The ultimate guide to the meta robots tag.

ahrefs. Canonical Tags: A Simple Guide for Beginners

Project-Level Security: Leveraging Local Git Config and Dedicated SSH Keys for Multiple Repositories

Hamed Fatehi — Tue, 11 Apr 2023 18:58:47 +0000

Developing multiple projects often requires the use of different Git repositories. As a developer, you might have access to various repositories, each with different access levels and security requirements. In such cases, it's essential to maintain a secure and organized development environment. One way to achieve this is by using a separate SSH private key for each repository and configuring local Git config files accordingly.

When each repository has its dedicated SSH key, it becomes easier to manage access rights. Revoking or granting access to a specific repository can be achieved by simply managing the corresponding SSH key.

Configuring Local Git Config for Each Repository:

To set up a dedicated SSH key for each repository, you need to create and configure the local Git config file for each project. The local Git config file, located at .git/config within the repository, contains repository-specific settings. Here's how to configure the local Git config file to use a separate SSH private key for each repository:

Generate a new SSH key pair for each repository you want to secure:

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com" -f /path/to/your/private_key

Add the generated public key to the corresponding repository's SSH settings.

Configure the local Git config file for each project by adding the following lines to the .git/config file:

[core]
  sshCommand = "ssh -i /path/to/your/private_key"

You can also set the core.sshCommand configuration for a specific repository via the terminal using the following command:

git config core.sshCommand "ssh -i /path/to/your/private_key"

The sshCommand directive specifies the path to the private key associated with the repository. Replace /path/to/your/private_key with the actual path to the private key you generated in step 1.

Save the changes to the local Git config file.
Now, when you interact with the repository (e.g., git pull, git push), Git will use the specified private key for authentication, ensuring that each repository has its dedicated SSH key.

Conclusion:

By using dedicated SSH keys for each Git repository and configuring the local Git config file accordingly, you can improve your development environment's security and organization. This approach simplifies access management and makes it easier to troubleshoot authentication issues. As a result, you can focus on your development tasks with confidence, knowing that your repositories are secure and well-organized.