frontend posts - idmontie's Portfolio

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    blockquote: "blockquote",
    code: "code",
    h2: "h2",
    li: "li",
    p: "p",
    pre: "pre",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management."
    }), "\n", _jsx(_components.p, {
      children: "The implementation may be wrong, but the path toward fixing it is usually understood."
    }), "\n", _jsx(_components.p, {
      children: "Then there are toasts."
    }), "\n", _jsx(_components.h2, {
      children: "What is a Toast"
    }), "\n", _jsx(_components.p, {
      children: "A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed."
    }), "\n", _jsx(_components.p, {
      children: "In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action."
    }), "\n", _jsx(_components.p, {
      children: "In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result."
    }), "\n", _jsx(_components.h2, {
      children: "Why toasts are difficult"
    }), "\n", _jsxs(_components.p, {
      children: ["Dialogs have ", _jsx(_components.code, {
        children: "<dialog>"
      }), ". Buttons have ", _jsx(_components.code, {
        children: "<button>"
      }), ". Forms have ", _jsx(_components.code, {
        children: "<form>"
      }), ", ", _jsx(_components.code, {
        children: "<input>"
      }), ", and ", _jsx(_components.code, {
        children: "<label>"
      }), ". Toasts have… ", _jsx(_components.code, {
        children: "<div>"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "For example, here is an HTML-only modal example:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        children: " <dialog id=\"hello_modal\" class=\"modal\">\n  <div class=\"modal-box\">\n    <h3 class=\"text-lg font-bold\">Hello!</h3>\n  </div>\n</dialog>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Native elements provide browsers and assistive technologies with semantics they already understand."
    }), "\n", _jsx(_components.p, {
      children: "The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it."
    }), "\n", _jsx(_components.p, {
      children: "Then there is the large amount of usability issues:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "On large screens, toasts end up going unnoticed."
      }), "\n", _jsx(_components.li, {
        children: "On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter."
      }), "\n", _jsx(_components.li, {
        children: "A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it."
      }), "\n", _jsx(_components.li, {
        children: "If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window."
      }), "\n", _jsx(_components.li, {
        children: "A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it."
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "What do we do about it?"
    }), "\n", _jsxs(_components.p, {
      children: ["The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that ", _jsx(_components.a, {
        href: "https://primer.style/accessibility/patterns/accessible-notifications-and-messages/",
        children: "toasts were not worth the effort"
      }), ":"]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Toasts pose significant accessibility concerns and are not recommended for use."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "The accessibility problem with toasts isn't merely that screen readers can't announce them. It's that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen."
    }), "\n", _jsx(_components.p, {
      children: "For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message."
    }), "\n", _jsxs(_components.p, {
      children: ["There are also many discussions on YCombinator, such as ", _jsx(_components.a, {
        href: "https://news.ycombinator.com/item?id=46135145",
        children: "this one"
      }), " where users argue about how useful toasts really are."]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Toasts are a great way to lose information."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them."
    }), "\n", _jsxs(_components.p, {
      children: ["But if a toast is really required, the package ", _jsx(_components.a, {
        href: "https://github.com/emilkowalski/sonner",
        children: "Sonner"
      }), " offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a ", _jsx(_components.a, {
        href: "https://emilkowal.ski/ui/building-a-toast-component",
        children: "nice blog post here"
      }), " that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<section\n  aria-label={ariaLabel}\n  tabIndex={-1}\n  aria-live=\"polite\"\n  aria-atomic=\"false\"\n>\n  <ol tabIndex={-1}>\n    <li tabIndex={0}>\n\t    {content}\n    </li>\n  </ol>\n</section>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Each section helps with accessibility as follows:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-label"
        }), " provides screen readers with an accessible name for the section"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "tabIndex={-1}"
        }), " takes the section out of the keyboard navigation flow"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-live=\"polite\""
        }), " means that any changes within this node will wait to alert the user until their current action is complete"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-atomic=\"false\""
        }), " means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again."]
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["Another implementation that is very accessibility aware is the ", _jsx(_components.a, {
        href: "https://react-aria.adobe.com/Toast/useToast",
        children: "React Aria library"
      }), ", which creates markup similar to:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<div\n\trole=\"region\"\n\ttabindex=\"-1\"\n\taria-label=\"1 notification.\"\n>\n\t<div\n\t\trole=\"alertdialog\"\n\t\taria-modal=\"false\"\n\t\taria-labelledby=\"title\"\n\t\ttabindex=\"0\"\n\t>\n\t\t<div\n\t\t\trole=\"alert\"\n\t\t\taria-atomic=\"true\"\n\t\t>\n\t\t\t<div\n\t\t\t\tid=\"title\"\n\t\t\t\tslot=\"title\"\n\t\t\t>\n\t\t\t\tToast is done!\n\t\t\t</div>\n\t\t</div>\n\t</div>\n</div>\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a ", _jsx(_components.code, {
        children: "region"
      }), ". It also uses the role ", _jsx(_components.code, {
        children: "alertdialog"
      }), " ."]
    }), "\n", _jsx(_components.h2, {
      children: "Did we solve it?"
    }), "\n", _jsx(_components.p, {
      children: "Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast."
    }), "\n", _jsx(_components.p, {
      children: "The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?"
    }), "\n", _jsx(_components.p, {
      children: "There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention."
    }), "\n", _jsx(_components.p, {
      children: "Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management.</p>
<p>The implementation may be wrong, but the path toward fixing it is usually understood.</p>
<p>Then there are toasts.</p>
<h2>What is a Toast</h2>
<p>A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed.</p>
<p>In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action.</p>
<p>In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result.</p>
<h2>Why toasts are difficult</h2>
<p>Dialogs have <code>&lt;dialog&gt;</code>. Buttons have <code>&lt;button&gt;</code>. Forms have <code>&lt;form&gt;</code>, <code>&lt;input&gt;</code>, and <code>&lt;label&gt;</code>. Toasts have… <code>&lt;div&gt;</code>.</p>
<p>For example, here is an HTML-only modal example:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code> &lt;dialog id=&quot;hello_modal&quot; class=&quot;modal&quot;&gt;
  &lt;div class=&quot;modal-box&quot;&gt;
    &lt;h3 class=&quot;text-lg font-bold&quot;&gt;Hello!&lt;/h3&gt;
  &lt;/div&gt;
&lt;/dialog&gt;
</code></pre></div>
<p>Native elements provide browsers and assistive technologies with semantics they already understand.</p>
<p>The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it.</p>
<p>Then there is the large amount of usability issues:</p>
<ul>
<li>On large screens, toasts end up going unnoticed.</li>
<li>On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter.</li>
<li>A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it.</li>
<li>If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window.</li>
<li>A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it.</li>
</ul>
<h2>What do we do about it?</h2>
<p>The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that <a href="https://primer.style/accessibility/patterns/accessible-notifications-and-messages/">toasts were not worth the effort</a>:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Toasts pose significant accessibility concerns and are not recommended for use.</p>
</blockquote>
<p>The accessibility problem with toasts isn&#x27;t merely that screen readers can&#x27;t announce them. It&#x27;s that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen.</p>
<p>For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message.</p>
<p>There are also many discussions on YCombinator, such as <a href="https://news.ycombinator.com/item?id=46135145">this one</a> where users argue about how useful toasts really are.</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Toasts are a great way to lose information.</p>
</blockquote>
<p>On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them.</p>
<p>But if a toast is really required, the package <a href="https://github.com/emilkowalski/sonner">Sonner</a> offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a <a href="https://emilkowal.ski/ui/building-a-toast-component">nice blog post here</a> that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;section
  aria-label={ariaLabel}
  tabIndex={-1}
  aria-live=&quot;polite&quot;
  aria-atomic=&quot;false&quot;
&gt;
  &lt;ol tabIndex={-1}&gt;
    &lt;li tabIndex={0}&gt;
	    {content}
    &lt;/li&gt;
  &lt;/ol&gt;
&lt;/section&gt;
</code></pre></div>
<p>Each section helps with accessibility as follows:</p>
<ul>
<li><code>aria-label</code> provides screen readers with an accessible name for the section</li>
<li><code>tabIndex={-1}</code> takes the section out of the keyboard navigation flow</li>
<li><code>aria-live=&quot;polite&quot;</code> means that any changes within this node will wait to alert the user until their current action is complete</li>
<li><code>aria-atomic=&quot;false&quot;</code> means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again.</li>
</ul>
<p>Another implementation that is very accessibility aware is the <a href="https://react-aria.adobe.com/Toast/useToast">React Aria library</a>, which creates markup similar to:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;div
	role=&quot;region&quot;
	tabindex=&quot;-1&quot;
	aria-label=&quot;1 notification.&quot;
&gt;
	&lt;div
		role=&quot;alertdialog&quot;
		aria-modal=&quot;false&quot;
		aria-labelledby=&quot;title&quot;
		tabindex=&quot;0&quot;
	&gt;
		&lt;div
			role=&quot;alert&quot;
			aria-atomic=&quot;true&quot;
		&gt;
			&lt;div
				id=&quot;title&quot;
				slot=&quot;title&quot;
			&gt;
				Toast is done!
			&lt;/div&gt;
		&lt;/div&gt;
	&lt;/div&gt;
&lt;/div&gt;
</code></pre></div>
<p>Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a <code>region</code>. It also uses the role <code>alertdialog</code> .</p>
<h2>Did we solve it?</h2>
<p>Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast.</p>
<p>The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?</p>
<p>There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention.</p>
<p>Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?</p>

Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management.

The implementation may be wrong, but the path toward fixing it is usually understood.

Then there are toasts.



## What is a Toast

A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed.

In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action.

In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result.

## Why toasts are difficult

Dialogs have `<dialog>`. Buttons have `<button>`. Forms have `<form>`, `<input>`, and `<label>`. Toasts have… `<div>`.

For example, here is an HTML-only modal example:

```
 <dialog id="hello_modal" class="modal">
  <div class="modal-box">
    <h3 class="text-lg font-bold">Hello!</h3>
  </div>
</dialog>
```

Native elements provide browsers and assistive technologies with semantics they already understand.

The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it.

Then there is the large amount of usability issues:

- On large screens, toasts end up going unnoticed.
- On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter.
- A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it.
- If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window.
- A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it.

## What do we do about it?

The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that [toasts were not worth the effort](https://primer.style/accessibility/patterns/accessible-notifications-and-messages/):

> Toasts pose significant accessibility concerns and are not recommended for use.

The accessibility problem with toasts isn't merely that screen readers can't announce them. It's that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen. 

For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message.

There are also many discussions on YCombinator, such as [this one](https://news.ycombinator.com/item?id=46135145) where users argue about how useful toasts really are.

> Toasts are a great way to lose information.


On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them.

But if a toast is really required, the package [Sonner](https://github.com/emilkowalski/sonner) offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a [nice blog post here](https://emilkowal.ski/ui/building-a-toast-component) that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:

```html
<section
  aria-label={ariaLabel}
  tabIndex={-1}
  aria-live="polite"
  aria-atomic="false"
>
  <ol tabIndex={-1}>
    <li tabIndex={0}>
	    {content}
    </li>
  </ol>
</section>
```

Each section helps with accessibility as follows:

- `aria-label` provides screen readers with an accessible name for the section
- `tabIndex={-1}` takes the section out of the keyboard navigation flow
- `aria-live="polite"` means that any changes within this node will wait to alert the user until their current action is complete
- `aria-atomic="false"` means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again.

Another implementation that is very accessibility aware is the [React Aria library](https://react-aria.adobe.com/Toast/useToast), which creates markup similar to:

```html
<div
	role="region"
	tabindex="-1"
	aria-label="1 notification."
>
	<div
		role="alertdialog"
		aria-modal="false"
		aria-labelledby="title"
		tabindex="0"
	>
		<div
			role="alert"
			aria-atomic="true"
		>
			<div
				id="title"
				slot="title"
			>
				Toast is done!
			</div>
		</div>
	</div>
</div>
```

Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a `region`. It also uses the role `alertdialog` .

## Did we solve it?

Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast.

The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?

There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention.

Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?

Toasts Are Harder Than They Look

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    h2: "h2",
    h3: "h3",
    li: "li",
    ol: "ol",
    p: "p",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "Below are some notes I’ve taken from setting up new code repositories and onboarding new team members. Hopefully they can help improve your current documentation and notes to make onboarding a smooth process."
    }), "\n", _jsx(_components.h2, {
      children: "Onboarding"
    }), "\n", _jsx(_components.p, {
      children: "When new members start, do you have processes and documentation in place to make onboarding easy?"
    }), "\n", _jsx(_components.p, {
      children: "☐ Is your process written down?"
    }), "\n", _jsx(_components.p, {
      children: "☐ Add a note for people onboarding continue to improve it when they walk through it. Every time a new members onboards, they should follow the documentation and update it with any missing steps or new errors and resolutions if they come across them."
    }), "\n", _jsx(_components.h2, {
      children: "Environment Setup"
    }), "\n", _jsx(_components.p, {
      children: "Part of onboarding is getting your environment set up. Usually, a team will have a preferred IDE and environment set up so that it is easy to help each other if there are any problems."
    }), "\n", _jsx(_components.p, {
      children: "☐ Is the preferred IDE documented?"
    }), "\n", _jsx(_components.p, {
      children: "☐ Are preferred 3rd party plugins that developers install listed and documented somewhere?"
    }), "\n", _jsx(_components.p, {
      children: "☐ If there is a VPN, are all the VPN details documented?"
    }), "\n", _jsx(_components.p, {
      children: "☐ Is the preferred Git usage documented? IE git-flow etc?"
    }), "\n", _jsx(_components.h2, {
      children: "README"
    }), "\n", _jsx(_components.p, {
      children: "Each repository should have a main README that acts as a starting point for people new to the project to read. This should be useful to people who have been at the company for years, all the way to someone new who has just received their laptop:"
    }), "\n", _jsx(_components.p, {
      children: "☐ Does the README have all the steps to:"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Download"
      }), "\n", _jsx(_components.li, {
        children: "Install"
      }), "\n", _jsx(_components.li, {
        children: "Run"
      }), "\n", _jsx(_components.li, {
        children: "Deploy"
      }), "\n", _jsx(_components.li, {
        children: "Test"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "☐ Architecture - Is the architecture documented? This doesn’t need to be all documented within the README, but the README should at least link out to external documentation that covers:"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Clients, servers, databases, 3rd party systems are documented"
      }), "\n", _jsx(_components.li, {
        children: "Data flows between systems are documented"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "☐  API Documentation - How is the API documented? This is similar to the architecture section."
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "If your repo has components, is there a Storybook or similar site to document the interfaces?"
      }), "\n", _jsx(_components.li, {
        children: "If your repo has web APIs, is there a OpenAPI spec that can be viewed?"
      }), "\n", _jsx(_components.li, {
        children: "Other projects will want to document their APIs as well."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "☐ Design System - Similar to the API documentation, if there is a design system that is used or implemented, does your README call that out?"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Documentation - do you have a link to how to get to the documentation?"
      }), "\n", _jsx(_components.li, {
        children: "Storybooks - is there already a live storybook link somewhere? Does your README document how to run the storybook as well?"
      }), "\n"]
    }), "\n", _jsx(_components.h3, {
      children: "Building and CI/CD"
    }), "\n", _jsx(_components.p, {
      children: "If your project is buildable or deployable, do you have documentation on the Build Pipeline and the CI/CD PIipelines? These are important to simplify and document. Someone new to the project should be able to follow the README in the repo to build the application and understand what happens when they push a commit to the repository."
    }), "\n", _jsx(_components.p, {
      children: "☐  Build Pipeline"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Can the app be built in one step?"
      }), "\n", _jsx(_components.li, {
        children: "Is the pipeline modern?"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "☐  CI/CD"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Is there a CI/CD runner?"
      }), "\n", _jsx(_components.li, {
        children: "Is it documented?"
      }), "\n", _jsxs(_components.li, {
        children: ["Are there lint guidelines?", "\n", _jsxs(_components.ol, {
          children: ["\n", _jsx(_components.li, {
            children: "Are they checked on the CI/CD?"
          }), "\n"]
        }), "\n"]
      }), "\n", _jsxs(_components.li, {
        children: ["Are there unit tests?", "\n", _jsxs(_components.ol, {
          children: ["\n", _jsx(_components.li, {
            children: "Are they run on every commit?"
          }), "\n"]
        }), "\n"]
      }), "\n", _jsx(_components.li, {
        children: "Are there pre-push and pre-commit hooks? You can use Husky to set these up"
      }), "\n"]
    }), "\n", _jsx(_components.h3, {
      children: "Testing"
    }), "\n", _jsx(_components.p, {
      children: "As mentioned above, running unit, integration, and e2e tests may be part of the CI/CD pipeline. Will new people who onboard be able to follow the repo’s README or some other document in order to understand how to test their changes? If there is code-coverage, how do new members of the team know where to find them?"
    }), "\n", _jsx(_components.p, {
      children: "☐ Testing"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Is there a test pipeline"
      }), "\n", _jsx(_components.li, {
        children: "Are there unit tests"
      }), "\n", _jsx(_components.li, {
        children: "Are there automated code coverage reports?"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "☐ Bundle Sizes"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Make sure tree shaking is happening correctly"
      }), "\n", _jsx(_components.li, {
        children: "Analyze the bundle size with create-react-app or BundleSizeAnalyzer webpack plugin"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "☐ Performance"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsxs(_components.li, {
        children: ["Analyze your web app for pagespeed, lighthouse rating, and ", _jsx(_components.a, {
          href: "https://github.com/thecreazy/siteaudit",
          children: "a11y"
        })]
      }), "\n"]
    }), "\n", _jsx(_components.h3, {
      children: "External Services"
    }), "\n", _jsx(_components.p, {
      children: "Sometimes repositories are self-contained, but more often than not, a repository will pull external information from a service. This might be feature flags from providers like LaunchDarkly, or website content from a Content Management System (CMS). Do new members of the team need API keys for these services? Make sure to document any external services and how to access them."
    }), "\n", _jsx(_components.p, {
      children: "☐ CMS"
    }), "\n", _jsxs(_components.ol, {
      children: ["\n", _jsx(_components.li, {
        children: "Are there a lot of text and content that is constantly updated?"
      }), "\n", _jsx(_components.li, {
        children: "Is there a CMS already implemented?"
      }), "\n"]
    }), "\n", _jsx(_components.h3, {
      children: "Conclusion"
    }), "\n", _jsx(_components.p, {
      children: "This is not meant to be an exhaustive list of everything to think about concerning onboarding members to a project. Documentation is nice to have, but working with the team to understand what is missing and how to improve it goes a long way to keeping the team happy and productive."
    }), "\n", _jsx(_components.p, {
      children: "I highly recommend reviewing the onboarding process from time to time and making sure that it is easy to onboard. You never know when your computer will crash and you need to set up your entire environment again."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Below are some notes I’ve taken from setting up new code repositories and onboarding new team members. Hopefully they can help improve your current documentation and notes to make onboarding a smooth process.</p>
<h2>Onboarding</h2>
<p>When new members start, do you have processes and documentation in place to make onboarding easy?</p>
<p>☐ Is your process written down?</p>
<p>☐ Add a note for people onboarding continue to improve it when they walk through it. Every time a new members onboards, they should follow the documentation and update it with any missing steps or new errors and resolutions if they come across them.</p>
<h2>Environment Setup</h2>
<p>Part of onboarding is getting your environment set up. Usually, a team will have a preferred IDE and environment set up so that it is easy to help each other if there are any problems.</p>
<p>☐ Is the preferred IDE documented?</p>
<p>☐ Are preferred 3rd party plugins that developers install listed and documented somewhere?</p>
<p>☐ If there is a VPN, are all the VPN details documented?</p>
<p>☐ Is the preferred Git usage documented? IE git-flow etc?</p>
<h2>README</h2>
<p>Each repository should have a main README that acts as a starting point for people new to the project to read. This should be useful to people who have been at the company for years, all the way to someone new who has just received their laptop:</p>
<p>☐ Does the README have all the steps to:</p>
<ol>
<li>Download</li>
<li>Install</li>
<li>Run</li>
<li>Deploy</li>
<li>Test</li>
</ol>
<p>☐ Architecture - Is the architecture documented? This doesn’t need to be all documented within the README, but the README should at least link out to external documentation that covers:</p>
<ol>
<li>Clients, servers, databases, 3rd party systems are documented</li>
<li>Data flows between systems are documented</li>
</ol>
<p>☐  API Documentation - How is the API documented? This is similar to the architecture section.</p>
<ol>
<li>If your repo has components, is there a Storybook or similar site to document the interfaces?</li>
<li>If your repo has web APIs, is there a OpenAPI spec that can be viewed?</li>
<li>Other projects will want to document their APIs as well.</li>
</ol>
<p>☐ Design System - Similar to the API documentation, if there is a design system that is used or implemented, does your README call that out?</p>
<ol>
<li>Documentation - do you have a link to how to get to the documentation?</li>
<li>Storybooks - is there already a live storybook link somewhere? Does your README document how to run the storybook as well?</li>
</ol>
<h3>Building and CI/CD</h3>
<p>If your project is buildable or deployable, do you have documentation on the Build Pipeline and the CI/CD PIipelines? These are important to simplify and document. Someone new to the project should be able to follow the README in the repo to build the application and understand what happens when they push a commit to the repository.</p>
<p>☐  Build Pipeline</p>
<ol>
<li>Can the app be built in one step?</li>
<li>Is the pipeline modern?</li>
</ol>
<p>☐  CI/CD</p>
<ol>
<li>Is there a CI/CD runner?</li>
<li>Is it documented?</li>
<li>Are there lint guidelines?
<ol>
<li>Are they checked on the CI/CD?</li>
</ol>
</li>
<li>Are there unit tests?
<ol>
<li>Are they run on every commit?</li>
</ol>
</li>
<li>Are there pre-push and pre-commit hooks? You can use Husky to set these up</li>
</ol>
<h3>Testing</h3>
<p>As mentioned above, running unit, integration, and e2e tests may be part of the CI/CD pipeline. Will new people who onboard be able to follow the repo’s README or some other document in order to understand how to test their changes? If there is code-coverage, how do new members of the team know where to find them?</p>
<p>☐ Testing</p>
<ol>
<li>Is there a test pipeline</li>
<li>Are there unit tests</li>
<li>Are there automated code coverage reports?</li>
</ol>
<p>☐ Bundle Sizes</p>
<ol>
<li>Make sure tree shaking is happening correctly</li>
<li>Analyze the bundle size with create-react-app or BundleSizeAnalyzer webpack plugin</li>
</ol>
<p>☐ Performance</p>
<ol>
<li>Analyze your web app for pagespeed, lighthouse rating, and <a href="https://github.com/thecreazy/siteaudit">a11y</a></li>
</ol>
<h3>External Services</h3>
<p>Sometimes repositories are self-contained, but more often than not, a repository will pull external information from a service. This might be feature flags from providers like LaunchDarkly, or website content from a Content Management System (CMS). Do new members of the team need API keys for these services? Make sure to document any external services and how to access them.</p>
<p>☐ CMS</p>
<ol>
<li>Are there a lot of text and content that is constantly updated?</li>
<li>Is there a CMS already implemented?</li>
</ol>
<h3>Conclusion</h3>
<p>This is not meant to be an exhaustive list of everything to think about concerning onboarding members to a project. Documentation is nice to have, but working with the team to understand what is missing and how to improve it goes a long way to keeping the team happy and productive.</p>
<p>I highly recommend reviewing the onboarding process from time to time and making sure that it is easy to onboard. You never know when your computer will crash and you need to set up your entire environment again.</p>


Below are some notes I’ve taken from setting up new code repositories and onboarding new team members. Hopefully they can help improve your current documentation and notes to make onboarding a smooth process.

## Onboarding

When new members start, do you have processes and documentation in place to make onboarding easy?

☐ Is your process written down?

☐ Add a note for people onboarding continue to improve it when they walk through it. Every time a new members onboards, they should follow the documentation and update it with any missing steps or new errors and resolutions if they come across them.

## Environment Setup

Part of onboarding is getting your environment set up. Usually, a team will have a preferred IDE and environment set up so that it is easy to help each other if there are any problems.

☐ Is the preferred IDE documented?

☐ Are preferred 3rd party plugins that developers install listed and documented somewhere?

☐ If there is a VPN, are all the VPN details documented?

☐ Is the preferred Git usage documented? IE git-flow etc?

## README

Each repository should have a main README that acts as a starting point for people new to the project to read. This should be useful to people who have been at the company for years, all the way to someone new who has just received their laptop:

☐ Does the README have all the steps to:

1. Download
2. Install
3. Run
4. Deploy
5. Test

☐ Architecture - Is the architecture documented? This doesn’t need to be all documented within the README, but the README should at least link out to external documentation that covers:

1. Clients, servers, databases, 3rd party systems are documented
2. Data flows between systems are documented

☐  API Documentation - How is the API documented? This is similar to the architecture section.

1. If your repo has components, is there a Storybook or similar site to document the interfaces?
2. If your repo has web APIs, is there a OpenAPI spec that can be viewed?
3. Other projects will want to document their APIs as well.

☐ Design System - Similar to the API documentation, if there is a design system that is used or implemented, does your README call that out?

1. Documentation - do you have a link to how to get to the documentation?
2. Storybooks - is there already a live storybook link somewhere? Does your README document how to run the storybook as well?

### Building and CI/CD

If your project is buildable or deployable, do you have documentation on the Build Pipeline and the CI/CD PIipelines? These are important to simplify and document. Someone new to the project should be able to follow the README in the repo to build the application and understand what happens when they push a commit to the repository.

☐  Build Pipeline

1. Can the app be built in one step?
2. Is the pipeline modern?

☐  CI/CD

1. Is there a CI/CD runner?
2. Is it documented?
3. Are there lint guidelines?
    1. Are they checked on the CI/CD?
4. Are there unit tests?
    1. Are they run on every commit?
5. Are there pre-push and pre-commit hooks? You can use Husky to set these up

### Testing

As mentioned above, running unit, integration, and e2e tests may be part of the CI/CD pipeline. Will new people who onboard be able to follow the repo’s README or some other document in order to understand how to test their changes? If there is code-coverage, how do new members of the team know where to find them?

☐ Testing

1. Is there a test pipeline
2. Are there unit tests
3. Are there automated code coverage reports?

☐ Bundle Sizes

1. Make sure tree shaking is happening correctly
2. Analyze the bundle size with create-react-app or BundleSizeAnalyzer webpack plugin

☐ Performance

1. Analyze your web app for pagespeed, lighthouse rating, and [a11y](https://github.com/thecreazy/siteaudit)

### External Services

Sometimes repositories are self-contained, but more often than not, a repository will pull external information from a service. This might be feature flags from providers like LaunchDarkly, or website content from a Content Management System (CMS). Do new members of the team need API keys for these services? Make sure to document any external services and how to access them.

☐ CMS

1. Are there a lot of text and content that is constantly updated?
2. Is there a CMS already implemented?

### Conclusion

This is not meant to be an exhaustive list of everything to think about concerning onboarding members to a project. Documentation is nice to have, but working with the team to understand what is missing and how to improve it goes a long way to keeping the team happy and productive.

I highly recommend reviewing the onboarding process from time to time and making sure that it is easy to onboard. You never know when your computer will crash and you need to set up your entire environment again.


Reviewing Your Frontend Applications

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    h2: "h2",
    li: "li",
    mermaid: "mermaid",
    p: "p",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "The Backend for the Frontend (BEFFE) is typically stateless and acts as a proxy for other services, including authentication, authorization, and core services. The recent divorce of browser code being rendered by backend services was created by SPAs - Single Page Applications. In simpler architectures, a SPA and service could be as simple as:"
    }), "\n", _jsx(_components.mermaid, {
      chart: "graph LR\n  SPA --> Backend"
    }), "\n", _jsx(_components.p, {
      children: "SPAs also became popular because the codebase could be built into static assets that could be services."
    }), "\n", _jsx(_components.p, {
      children: "However, as complexity arises with the above architecture and the SPA starts to rely on more services, a thin proxy is typically introduced, like NGINX:"
    }), "\n", _jsx(_components.mermaid, {
      chart: "graph LR\n  SPA --> NGINX\n  NGINX --> Service1\n  NGINX --> Service2\n  NGINX --> Service3"
    }), "\n", _jsx(_components.p, {
      children: "While proxies like NGINX can continue to be useful, using it as a proxy ends up putting a lot of routing and additional API handling logic on the client. The client now ends up also having to support, understand, and embed how to interact with the data rom all the downstream services. To simplify and create consistent contracts with the UI, we can create a proxy service: a Backend for the Frontend:"
    }), "\n", _jsx(_components.mermaid, {
      chart: "graph LR\n  SPA --> BEFFE\n  BEFFE --> Service1\n  BEFFE --> Service2\n  BEFFE --> Service3"
    }), "\n", _jsx(_components.p, {
      children: "The Backend for the Frontend ends up serving two purposes:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "It acts as a proxy for all UI requests"
      }), "\n", _jsx(_components.li, {
        children: "It manages and massages the APIs of downstream services to be a consistent API for the UI."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "When building a UI, only a single service that acts like an API Gateway is required to understand and encode within the application."
    }), "\n", _jsx(_components.p, {
      children: "The Backend for the Frontend model also allows engineers working on services to separate logic for the UI with the logic from an internal service. An internal service can rely on the Backend for the Frontend to handle things like Authentication, Authorization, Caching, and Rate-limits. These mechanisms may also be implemented as independent services, but the Backend for the Frontend can make multiple API calls per any API request from the UI."
    }), "\n", _jsx(_components.h2, {
      children: "Moving away from SPAs"
    }), "\n", _jsx(_components.p, {
      children: "A newer development in the UI space is server side render the application. If we are already introducing additional complexity by having a Backend for the Frontend, then why not combine the UI code with the backend service and generate hydrated and cacheable pages via the server instead of using a SPA?"
    }), "\n", _jsx(_components.mermaid, {
      chart: "graph LR\n  UIServer[\"UI Server\"] --> Service1\n  UIServer --> Service2\n UIServer --> Service3"
    }), "\n", _jsx(_components.p, {
      children: "With this design, we increase the complexity - the backend not has to be able to render the UI code. It must now render, hydrate, make requests to downstream APIs, and send those server-side rendered pages to the browser."
    }), "\n", _jsx(_components.p, {
      children: "But this additional complexity enabled us to:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "create truly authenticated and authorized routes – the code for those routes isn’t even streamed to the browser, unlike a SPA."
      }), "\n", _jsx(_components.li, {
        children: "near instant page loads – reducing the bundle size by just sending the JavaScript needed to run the page makes this possible. And since API calls are happening within the same network, this saves the user from additional loading spinners after the initial bundle has been loaded."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "The general trend of having a Backend for the Frontend comes with additional complexity. It stems from the want to enhance the experience of the user, and probably from a subconscious desire to return to a simpler time:"
    }), "\n", _jsx(_components.mermaid, {
      chart: "graph TD\n  Server"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>The Backend for the Frontend (BEFFE) is typically stateless and acts as a proxy for other services, including authentication, authorization, and core services. The recent divorce of browser code being rendered by backend services was created by SPAs - Single Page Applications. In simpler architectures, a SPA and service could be as simple as:</p>
<mermaid chart="graph LR
  SPA --&gt; Backend"></mermaid>
<p>SPAs also became popular because the codebase could be built into static assets that could be services.</p>
<p>However, as complexity arises with the above architecture and the SPA starts to rely on more services, a thin proxy is typically introduced, like NGINX:</p>
<mermaid chart="graph LR
  SPA --&gt; NGINX
  NGINX --&gt; Service1
  NGINX --&gt; Service2
  NGINX --&gt; Service3"></mermaid>
<p>While proxies like NGINX can continue to be useful, using it as a proxy ends up putting a lot of routing and additional API handling logic on the client. The client now ends up also having to support, understand, and embed how to interact with the data rom all the downstream services. To simplify and create consistent contracts with the UI, we can create a proxy service: a Backend for the Frontend:</p>
<mermaid chart="graph LR
  SPA --&gt; BEFFE
  BEFFE --&gt; Service1
  BEFFE --&gt; Service2
  BEFFE --&gt; Service3"></mermaid>
<p>The Backend for the Frontend ends up serving two purposes:</p>
<ul>
<li>It acts as a proxy for all UI requests</li>
<li>It manages and massages the APIs of downstream services to be a consistent API for the UI.</li>
</ul>
<p>When building a UI, only a single service that acts like an API Gateway is required to understand and encode within the application.</p>
<p>The Backend for the Frontend model also allows engineers working on services to separate logic for the UI with the logic from an internal service. An internal service can rely on the Backend for the Frontend to handle things like Authentication, Authorization, Caching, and Rate-limits. These mechanisms may also be implemented as independent services, but the Backend for the Frontend can make multiple API calls per any API request from the UI.</p>
<h2>Moving away from SPAs</h2>
<p>A newer development in the UI space is server side render the application. If we are already introducing additional complexity by having a Backend for the Frontend, then why not combine the UI code with the backend service and generate hydrated and cacheable pages via the server instead of using a SPA?</p>
<mermaid chart="graph LR
  UIServer[&quot;UI Server&quot;] --&gt; Service1
  UIServer --&gt; Service2
 UIServer --&gt; Service3"></mermaid>
<p>With this design, we increase the complexity - the backend not has to be able to render the UI code. It must now render, hydrate, make requests to downstream APIs, and send those server-side rendered pages to the browser.</p>
<p>But this additional complexity enabled us to:</p>
<ul>
<li>create truly authenticated and authorized routes – the code for those routes isn’t even streamed to the browser, unlike a SPA.</li>
<li>near instant page loads – reducing the bundle size by just sending the JavaScript needed to run the page makes this possible. And since API calls are happening within the same network, this saves the user from additional loading spinners after the initial bundle has been loaded.</li>
</ul>
<p>The general trend of having a Backend for the Frontend comes with additional complexity. It stems from the want to enhance the experience of the user, and probably from a subconscious desire to return to a simpler time:</p>
<mermaid chart="graph TD
  Server"></mermaid>


The Backend for the Frontend (BEFFE) is typically stateless and acts as a proxy for other services, including authentication, authorization, and core services. The recent divorce of browser code being rendered by backend services was created by SPAs - Single Page Applications. In simpler architectures, a SPA and service could be as simple as:

```mermaid
graph LR
  SPA --> Backend
```

SPAs also became popular because the codebase could be built into static assets that could be services.

However, as complexity arises with the above architecture and the SPA starts to rely on more services, a thin proxy is typically introduced, like NGINX:

```mermaid
graph LR
  SPA --> NGINX
  NGINX --> Service1
  NGINX --> Service2
  NGINX --> Service3
```

While proxies like NGINX can continue to be useful, using it as a proxy ends up putting a lot of routing and additional API handling logic on the client. The client now ends up also having to support, understand, and embed how to interact with the data rom all the downstream services. To simplify and create consistent contracts with the UI, we can create a proxy service: a Backend for the Frontend:

```mermaid
graph LR
  SPA --> BEFFE
  BEFFE --> Service1
  BEFFE --> Service2
  BEFFE --> Service3
```

The Backend for the Frontend ends up serving two purposes:

- It acts as a proxy for all UI requests
- It manages and massages the APIs of downstream services to be a consistent API for the UI.

When building a UI, only a single service that acts like an API Gateway is required to understand and encode within the application.

The Backend for the Frontend model also allows engineers working on services to separate logic for the UI with the logic from an internal service. An internal service can rely on the Backend for the Frontend to handle things like Authentication, Authorization, Caching, and Rate-limits. These mechanisms may also be implemented as independent services, but the Backend for the Frontend can make multiple API calls per any API request from the UI.

## Moving away from SPAs

A newer development in the UI space is server side render the application. If we are already introducing additional complexity by having a Backend for the Frontend, then why not combine the UI code with the backend service and generate hydrated and cacheable pages via the server instead of using a SPA?

```mermaid
graph LR
  UIServer["UI Server"] --> Service1
  UIServer --> Service2
 UIServer --> Service3
```

With this design, we increase the complexity - the backend not has to be able to render the UI code. It must now render, hydrate, make requests to downstream APIs, and send those server-side rendered pages to the browser.

But this additional complexity enabled us to:

- create truly authenticated and authorized routes – the code for those routes isn’t even streamed to the browser, unlike a SPA.
- near instant page loads – reducing the bundle size by just sending the JavaScript needed to run the page makes this possible. And since API calls are happening within the same network, this saves the user from additional loading spinners after the initial bundle has been loaded.

The general trend of having a Backend for the Frontend comes with additional complexity. It stems from the want to enhance the experience of the user, and probably from a subconscious desire to return to a simpler time:

```mermaid
graph TD
  Server
```


Toasts Are Harder Than They Look

Reviewing Your Frontend Applications

Backend for Frontend