DEV Community: Fatuma Abdullahi

How to Build Accessible Video Experiences

Fatuma Abdullahi — Mon, 28 Apr 2025 16:34:03 +0000

Roughly 16% of the human population suffers from some form of long-term disability. If you include temporary disability like a broken arm, that number shoots up significantly.

If your in-app video content isn't accessible, you're potentially excluding a large part of the population and missing an opportunity to create better experiences for everyone.

As more people consume information through media, it is increasingly crucial to plan, organize, and ensure that video content is accessible. Accessible video expands the user base, enhances the experience for existing users, and ensures compliance with forthcoming accessibility laws.

But what does accessibility mean in the context of video?

Many teams struggle with where to start and find integrating inclusive practices challenging. This blog will break down the guidelines and considerations for building video experiences that people of all abilities can enjoy.

Understanding Web Accessibility

Accessibility is a broad topic and can be overwhelming for teams to plan for and implement. The World Wide Web Consortium (W3C) is an international organization that creates web standards around accessibility, internationalization, and privacy.

Through the Web Accessibility Initiative (WAI), they create and maintain a set of guidelines and resources known as Web Content Accessibility Guidelines (WCAG). Organizations can use WCAG to benchmark their product's accessibility levels.

Web accessibility, in particular, refers to how easy it is for people of all abilities to use a web-based product. Video accessibility refers to the same concept for audiovisual experiences. It includes a set of checks and guidelines designed to help determine what is objectively accessible for all audiences.

The POUR principles

At the heart of web accessibility is the idea that the web is for everyone, and everyone should be able to use it with as little friction as possible. WCAG has a lot of guidelines and rules, but these are the main principles informing the specific implementations:

Perceivable

User interfaces (UIs) and content should be seen, heard, understandable, or otherwise perceivable through multiple senses. For example, your UI should be usable by both sighted and non-sighted users.

You can achieve this by developing your UI to make it easy for screen readers to scan and relay information back to blind users.

Provide captions and transcripts as needed for video content to make it perceivable by those who cannot take in visual information.

Here is an example of what captions look like:

Other considerations for making your UI perceivable include making it responsive, handling zoom gracefully, and ensuring text is large enough and has enough contrast to increase readability.

Operable

User interfaces (UIs), content, and navigation should be usable through multiple input devices. For example, your UI should work as expected if the user interacts with it using a keyboard instead of a trackpad or voice command instead of a mouse.

You can make your UI and apps operable by ensuring logical and consistent navigation. This way, users always know where they are on the site or product and can quickly skip links or return to a previous screen, as illustrated.

Additionally, content should be searchable, and callouts and alerts should not have auto timeouts.

Understandable

User interfaces (UIs) and content should be easy for the primary audience to understand, regardless of their language proficiency or cognitive skills.

The UI should follow established patterns to help users understand expected actions, and the content should use simple language and avoid jargon.

For example, forms should have descriptive labels and helpful error messages, as illustrated. Large forms should be broken up into multi-step forms. Video content should use everyday language and explain abbreviations or jargon when necessary.

Other ways to increase your UI's understandability are to use consistent labeling for components across the app, avoid significant UI changes without alerting users, and give the users enough time before implementation.

Robust

User interfaces (UIs) should be as future-proof as possible. They should be compatible with current and future user tools. That is, they should work correctly across as many browsers and assistive technologies as possible while keeping up with future changes.

This may sound complicated, but it comes down to using standard markup (HTML), standard web APIs, and giving names or titles when using a non-standard UI element.

For example, use <button> instead of styling a <div> to look and work like a button.

What to consider when building accessible video experiences

When building accessible video experiences, there are certain aspects you need to pay particular attention to that are unique to audio-visual experiences. Video accessibility considerations are divided into the following main buckets:

User Research

Step one is always to understand your users and the tools they use to consume your visual products. This will help keep your efforts away from blind compliance, allowing you the flexibility to implement guidelines that are informed and most meaningful to your users.

Planning Audio-Visual Content and Media

The next step is to add accessibility concerns at the planning stage. This entails understanding the video's goal and deciding whether it will need visual descriptions, sign language interpretation, and transcripts to support it.

This helps make implementing the WCAG guidelines for audio-visual content a lot simpler.

Audio Descriptions (AD)

This refers to describing videos or parts needed to understand the content in context. It is required when some actions in the video are integral to understanding the whole video, as captions or transcripts are not enough to convey the complete message.

They are mainly for blind users and can be provided as part of the main script, a standalone file, or even a separate video.

An example of a YouTube tutorial in which Audio descriptions would be necessary is when the instructor walks through how to create an index.html page.

They say, "Open VSCode, create a new file called index.html, and then paste the following into it." However, listeners who can't see the screen don't know what "the following" means, making captions insufficient.

In that case, an audio description might be: "The instructor opens VS Code and creates a new file named 'index.html.' They paste the following code: the opening <html> tag, then the <head> section, where they paste a <title> tag with the text 'My First Web Page.' Next, they paste the <body> tag, and within it, they paste a heading using the <h1> tag with the text 'Hello, world!'"

Captions

Captions refer to the text version of a video's audiovisual content. They are shown in the media player and synced with the audio.

Captions should be provided for deaf and hard-of-hearing users and should include a dialog transcript, nonverbal sounds like sound effects, and speaker identification where necessary.

Building off the previous example, the YouTube instructor's video captions would read: "[instructor] Open VSCode, create a new file called index.html, and then paste the following into it."

Types of Captions

There are three types of captions:

Closed captions: Captions that the listener can turn on or off as they are separate from the video.
Open captions: Captions that autoplay are embedded in the video, so the user cannot turn them off.
Live captions: Captions that are transcribed in real time as the audio plays. The transcriber can be physically present or remote.

While there are tools that can help auto-create captions, results should not be relied on until they have been proofread and confirmed to be accurate.

Transcripts

Transcripts are text versions of audio content. They include all the information needed to understand the content entirely.

Types of Transcripts

Transcripts are of two types:

Basic transcripts: These are similar to captions, except they are provided separately from the video and are not auto-synced with the video as it plays.
Descriptive transcripts: These include the audio descriptions integrated with the transcribed audio.\ Ideally, the user should be able to interact with it by using it to jump to relevant parts of the video.
Interactive Transcripts: These are time-stamped transcripts that allow users to click on the text and jump directly to the corresponding part of the video. The time stamps are clickable and sync with the video's timeline.

The Stream Video SDK provides captions and transcripts in several languages and can be configured to your needs.

Sign language and translation considerations

Sign language is a gesture-based language used by the deaf community, some of whom might find text-based transcripts hard to understand.

Providing a sign-language interpretation of your video content is the gold standard, especially if you know you have deaf users or if your content could be helpful to them.

However, providing sign language translations might not be very direct and will require extra effort to be done correctly.

Another point is internationalization. Although it is not a WCAG requirement, providing accurate captions and transcripts in widely used languages, especially the language your users commonly use, is an excellent way to make your video content more accessible.

User customizations (Media Players)

Choosing a media player that provides UX accessibility features out of the box, where applicable, is a significant step up when building accessible video experiences.

Accessible players support keyboard navigation and right-to-left (RTL) language support, have good contrast, and have labels.

They also allow users to change the speed of the video, control how captions are shown, and support interactive transcripts.

For example, Stream's media player and SDKs allow users to turn captions on/off, customize theming, and cancel noise - all great features that improve video experiences.

Optimizing pre-existing video experiences

It is generally challenging to return and make preexisting video content accessible, which is why pre-planning is essential. However, you can get some wins by:

Providing transcripts.
Revising and providing accurate captions.
Assessing whether you need Audio Descriptions.
Optimizing the media player you use to display your video content.

Additionally, consider adding translated versions of the captions and transcripts.

Compliance considerations

Accessibility isn't just best practice. It's increasingly becoming a legal requirement regulated by several acts.

The following key regulations should be noted to ensure compliance:

Americans with Disabilities Act (ADA)

This regulation has been interpreted by courts in the US to apply to digital products and spaces and should be considered by organizations operating within US law.

This is more so for organizations that sell consumer-focused products.

European Accessibility Act (EAA)

This regulation, which is mainly based on WCAG, is focused on digital accessibility. It will come into effect in 2025 and affect all organizations operating within the EU and those wishing to target that market.

Complying with these and other relevant accessibility laws protects organizations from litigation, inspires more trust, and increases profitability.

Organizations can use this checklist to measure their compliance levels and dedicate resources to preparing for the upcoming laws.

Notes and resources

Building accessible video experiences requires much more than providing captions. It is a process that requires careful planning and consideration. However, improving audiovisual experiences to be more helpful to a broader audience is a worthwhile investment.

Here are some resources you can use to learn more about web accessibility and making video accessible:

Want to try building accessible video experiences? Check out how Stream's Video API can help you get started.

How to Use Supabase MCP in VSCode and Cursor

Fatuma Abdullahi — Fri, 04 Apr 2025 16:03:55 +0000

You've probably seen all the hype about MCPs, and you might be wondering what an MCP is or whether you should pay attention to it.

This blog will explain an MCP, why it's a big deal, and how to set both the GitHub and Supabase MCPs in VSCode and Cursor so you can start using them immediately.

What is MCP?

Model Context Protocol (MCP) is a new protocol from Anthropic that defines a unified way for LLMs to interact with outside data sources.

Before MCP, LLMs could only access their training data and user-provided local files. They could not directly access outside sources in real time. For example, your coding assistant could not read your database schema, so its ability to help you debug was limited.

How MCPs work

MCPs have a client-server architecture. The LLM client interacts with users, and the server stores the MCP logic. The client calls the server when it needs certain information or wants to perform a specific action.

MCP servers have two main concepts: tools and resources. Tools are callable functions that take inputs, perform operations, and return outputs. Resources refer to data that is available to the client and can be used by the tools as needed.

For example, the GitHub MCP server has tools that allow it to list repositories, and the resources it can access include repositories, issues, and pull requests.

This allows the application hosting the LLM (the client) to get real-time dynamic information and frees them from training data limitations like training cut-off dates.

MCP vs API - What's the Difference?

MCP seems a lot like traditional APIs, except that MCP is specifically designed for LLM clients and can work across all MCP clients without needing extra code or config.

While APIs generally require that you write glue code to integrate client applications, each MCP server internally calls its specific APIs and handles data transformations using the standard protocol.

This removes the need for service-specific code, allowing LLM applications to interact with many different systems without developers needing to create distinct integrations for each service.

MCP abstracts the details of specific APIs and creates a plug-and-play layer that LLMs can use. This makes MCP scalable and reduces developers' maintenance headaches.

Why is MCP Important?

Before MCP, you would need to create custom integrations for every external service your LLM needed to access, and you'd also have to manage these connections individually. This was time-consuming and inefficient.

MCP streamlines this process by allowing LLMs to connect to multiple external systems through a single protocol. This makes it much easier to integrate new services and greatly increases the usefulness of LLM applications.

https://youtu.be/ECMJY5njbls?si=yJTmXPuxy_LFTLXb

How to Enable MCP in VSCode

To start using MCP, you need to set up your text editor to work with it. For VSCode, you'll need to use VSCode Insiders, as it is not yet supported in the stable version. You can download it here and it works right along the normal version.

Open the installation, open the user settings, search MCP, and ensure they are enabled. Then, click the Edit in settings.json as illustrated below:

How to Test the MCP Connection with GitHub MCP Server

Edit the settings.json file to look like this:

{
  "mcp": {
    "inputs": [],
    "servers": {
      "github": {
        "command": "npx",
        "args": [
          "-y",
          "@modelcontextprotocol/server-github"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_GITHUB_TOKEN>"
        }
      }
    }
  },
  "chat.mcp.discovery.enabled": true,
  "editor.inlineSuggest.suppressSuggestions": true,
  "cody.suggestions.mode": "auto-edit (Beta)",
  "window.commandCenter": false,
}

💡

This "@modelcontextprotocol/server-github" refers to the server to which the Copilot will connect. It is part of Anthropic's exhaustive list of official MCP servers.

Replace this <YOUR_GITHUB_TOKEN> with your actual token. You can get it from GitHub developer settings as shown below:

This adds the GitHub MCP server and gives it API access via the token. The GitHub server has over 20 tools you can use, all of which are documented here. This server lets you do some pretty cool stuff, like creating issues on your behalf and searching public code.

Now start the server from the settings start option shown below or by searching MCP, selecting List MCP, and then starting the one you need.

We can now open the Copilot chat, turn on Agent mode, and ask about GitHub repos. You should see it uses the configured GitHub MCP server to answer GitHub-specific questions.

Once the feature is ready, the general availability of MCP servers in the stable build of VSCode will be added.

How to Enable MCP in Cursor

In Cursor, the process is almost similar. Open settings, select the MCP tab and click the Add new global MCP Server button.

It will take you to a settings page, paste in the following to add the GitHub MCP server:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github",
        "<YOUR_GITHUB_TOKEN>"
      ]
    }
  }
}

How to Test the MCP Connection with GitHub's MCP Server

In the settings file above, replace <YOUR_GITHUB_TOKEN> with your actual token following the process shown in the VSCode section above. The main difference is how you pass environment variables.

To test it, open cursor chat and ask some questions as before. It will indicate that it uses GitHub MCP tools to answer the questions.

How to Add and Use Official Supabase MCP in VSCode

Setting up Supabase's MCP server requires adding more config to the settings. Add this below the GitHub entry in the settings page:

"supabase": {
  "command": "npx",
  "args": [
          "-y",
          "@supabase/mcp-server-supabase@latest",
          "--access-token",
          "<personal_access_token>"
        ],
}

Replace <persoanl_access_token> with a Supabase access token, which you can get here.

In this case, the Supabase MCP accepts command-line arguments instead of environment variables, so we pass the access token directly. Start the server so Copilot can pick it up, and we are ready to test it.

Open the Copilot chat to agent mode and ask questions about your Supabase projects. The Supabase MCP server has tools for managing projects, getting project information, and carrying out some database operations, including running raw SQL and applying migrations.

You can find a full list of tools and more information in this GitHub repository.

💡

The official Supabase MCP server is still in early days and could have breaking changes going forward.

How to Add and Use Supabase MCP in Cursor

On the cursor side, it's pretty much the same process: you paste it into the same setting as above, just below the GitHub one, and replace the token with an actual token.

Cursor should pick it up and activate it once you save and restart it. You will know all is well when you see this little green dot on the MCP settings page in Cursor:

Open the Cursor chat to agent mode and try to ask it questions about your Supabase projects as before. It should show you as it steps through the relevant tools to answer your questions.

💡

Note: Cursor has a limit of 40 tools and won't be able to use all available tools from all servers if the limit is exceeded. If you need more tools, consider disabling MCP servers that you will not be currently using.

Notes and Resources

Here are some resources on MCPs, AI and some links I think will be useful:

4 Coffee Chats 4 Lessons

Fatuma Abdullahi — Thu, 20 Mar 2025 11:17:43 +0000

In the past month, Ive had the amazing opportunity to chat with tech professionals working in the open-source space.

I picked up several insightful nuggets Id like to share with you.

Lesson 1: On Imposter Syndrome

The first insight was from Victor Ndaba, Software Engineer at Jumba. Victor talked about his experience speaking at developer conferences at the start of his career, which I found very intriguing. Imposter syndrome would stop most of us at that stage of our journeys, but Victor? This is what he had to say:

Imposter syndrome is a symptom of learning not a syndrome.

Dare to be brave and put yourself out there despite it all.

Lesson 2: On Networking

The second insight came from Samuel Iglesias, Partner at Igalia. Samuel discussed networking and growing your connections as a job strategy. He emphasized that your network can open up opportunities you would have never known existed and that the trust factor of a referral carries a lot of weight.

The important part of a conference is the people attending the conference

Always attend the Hallway track at conferences and make connections.

Lesson 3: On Asking for Help

This one was from Lauralyn Watson, Software Engineer at Wikimedia. Lauralyn discussed being visible in your work and the importance of alerting your team when you get stuck, especially if you are new.

Ask early and ask as soon as possible

Take away? Dont be afraid to ask because they are no stupid questions.

Lesson 4: On Creative Exploration

This insight came from Jonny Summers, Product Design at Supabase. Jonny discussed the portability of design systems and components, acquiring a good sense of taste in products, and the importance of flexibility as a tool for creative exploration.

You should own the code and you should be able to do whatever you want with it

Nothing kills creativity like too much rigidity. Im glad we agreed that design should be way closer to the code.

]]>

The Supabase Influence on my DevRel Mental Model

Fatuma Abdullahi — Tue, 18 Mar 2025 16:50:00 +0000

The first in-depth chat I had about developer relations was with Jon Meyers, DevRel at Supabase. We talked about definitions, tackling the representative of the organization dilemma, the challenges of context switching, and the upsides of always learning something new and usually cutting-edge.

These conversations happened in my first official year in tech and formed the basis of my understanding of developer relations. Soon after, I joined Supasquad, an unofficial group of Supabase advocates, and have continued contributing to the community.

My contributions range from helping with the code, building a community package, creating technical tutorials, and organizing meetups to just shouting about Supabase on socials 🤭. All while staying in touch with the team and seeing their DevRel, community, and open-source approach play out in real-time.

It is no surprise, then, that the Supabase philosophy influences my mental model of developer relations as a whole. And given how wildly popular Supabase has become with near $0 in ad spend, I think its a positive influence.

What is DevRel?

Developer relations is often defined as the link between the developers who use a product and the developers who build the product. DevRel is, therefore, more relevant and common among organizations whose product is meant for developers. For example, devTools and organizations that provide API access to their product.

DevRel professionals take feedback from the developer users and send it to the product team. They advocate that this feedback be incorporated and considered when creating product roadmaps.

They also take new product features and communicate their value and use to the developers, the intended users. They do this by ensuring that documentation is accessible and concise, providing technical examples and sample code, and being available to answer questions.

By this, DevRel cultivates a culture and community around the product and is responsible for nurturing and keeping it healthy.

The Is DevRel dead? Discourse

It is quite clear that DevRel plays an important role and is invaluable for developer-focussed products. But there has been discourse that periodically bubbles up about whether the function is stagnating or just straight up dying.

As long as developer-focused products exist, DevRel will always be needed. Its more a matter of evolving expectations and environment.

Why is DevRel Important?

DevRel is important to developers because it makes the product approachable. DevRel professionals ensure seamless onboarding, and that product documents make sense.

They act as a point of contact if you have trouble with the product and humanize the experience of interacting with and building with it.

For the organization, DevRel professionals keep users happy and engaged while increasing product awareness among developers outside the products circles. A well-functioning DevRel team increases product trust, loyalty, and sustained growth.

The Different Faces of DevRel

DevRel is wide and is generally built upon these pillars:

Developer Advocacy - This focuses on creating technical content, building relationships with the community, and taking feedback from the community to the product team.
Developer Experience - This aims to enhance developer productivity with your tools. It generally involves aspects such as clear documentation, creating SDKs for the community, and offering dependable example code snippets.
Community ManagementThis part focuses on community building and nurturing. It rewards active community members, creates ways for the community to participate, and creates a healthy community space.

Different organizations might have different titles and responsibilities for DevRel, but it will usually build upon the above pillars.

DevRel as Support

There is a lot of tech talk about whether or not DevRel is marketing or sales, but my personal take is that DevRel should be closer to technical support.

Considering that companies that need DevRel are targeting developers, their technical support is in service of their users, and their users are developers, it makes most sense that DevRel should do support.

Yes, marketing and sales are important, but I think DevRel working closely with the technical support team is the killer combo that serves all the purposes. Working with technical support will mean:

They understand their paying users and pain points.
They understand the reasoning behind why some of the users are paid, and some arent.
Based on this knowledge, they can better move the community down the funnel.
They can help correlate support data with their own observations from the community to inform a better product.
They can optimize onboarding materials and education materials to be more effective with the insights gained from technical support.

Ultimately, both functions serve the same-ish user profile (tech support probably serves more of larger enterprise customers). They would still be more effective if they internally collaborated more often.

Final Thoughts

Over the past year, Ive had the privilege of collaborating with DevRel teams across different organizations. The diversity of skills required to be badass at this amazes me.

DevRel professionals can remain technically skilled while developing deep expertise in skills like effective communication and collaboration. This is what draws me in. I love that I can continue to develop my core technical skills while helping educate the community and influencing the developer experience.

While I havent officially worked in a DevRel role, my experience contributing to communities, creating technical content, and collaborating with DevRel teams has made me appreciate the place of good DX.

]]>

How to Add SSR Auth to Astro with Supabase and Astro Actions

Fatuma Abdullahi — Mon, 17 Mar 2025 17:44:25 +0000

This blog will go through how to add authentication to a server-side rendered Astro project using actions and the Supabase SSR package.

Prerequisites

This blog assumes that you are familiar with the following concepts:

Web development frameworks
Basic authentication flows
Basic Backend-as-a-Service (BaaS)

What is Supabase?

Supabase is an open-source Backend-as-a-Service that builds upon Postgres. It provides common key features such as authentication, real-time, edge functions, storage, and more.

Supabase offers a hosted version that makes building and scaling production-ready apps easy and a self-hostable version that gives users full control.

What is Astro?

Astro is a UI-agnostic web framework. By default, it renders server-first, but it can be used with any UI framework, including Astro client components.

What are Astro Actions?

Astro actions allow you to write server-side functions that can be called without explicitly setting up API routes. Out of the box, they provide many useful utilities that simplify the process of running server logic.

Astro actions can be called from both client and server environments.

Understanding SSR Authentication

Server-side rendered (SSR) auth refers to handling authentication on the server. It is typically a cookie-based authentication method.

The server creates a session and stores a session ID in a cookie that is sent to the client.

The client (in this case, the browser) receives the cookie and automatically includes it in future requests so the server can use it to determine if the user is authenticated.

Since browsers cannot modify HTTP-only cookies and servers cannot access local storage, SSR authentication needs careful management to prevent security risks such as session hijacking and stale sessions.

SSR vs. SPA Authentication

On the other hand, Single-Page Applications (SPAs), like traditional React apps, handle authentication on the client side because they don't have direct access to a server.

SPAs typically use JWTs, which are stored in local storage, cookies, or session storage. When the application needs to communicate with a server, it sends these tokens in the HTTP headers.

Set Up Supabase Backend

To start, you will need a Supabase account. Then, follow the prompts to create a project. Go to the Authentication tab in the sidebar, click the Sign In / Up tab under Configuration, and enable user sign-ups. Then scroll down to Auth Providers and enable email.

Set Up the Frontend

Next, you will need to create an Astro project. Open your preferred IDE or Text editors integrated terminal and run the following command to scaffold an Astro project in a folder named ssr-auth. Feel free to use any name you like.

npm create astro@latest ssr-auth

Follow the provided prompts and choose a basic template to start with. When its done, change into the folder, then run npm install to install dependencies, followed by npm run dev to start the server, and your site will be available at localhost:4321.

Set Astro to run in SSR mode by adding output: "server", to the defineConfig function found in the astro.config.mjs file at the root of the folder.

Next, add an adapter to create a server runtime. For this, use the node.js adapter by running this command in a terminal: npx astro add node. This will add it and automatically make all relevant changes.

Finally, add Tailwind for styling. Run this command in a terminal window: npx astro add tailwind. Follow the prompts, and it will make any changes necessary.

At this stage, your astro.config.mjs should look like this:

// @ts-check
import { defineConfig } from "astro/config";

import node from "@astrojs/node";

import tailwindcss from "@tailwindcss/vite";

// https://astro.build/config
export default defineConfig({
  output: "server",

  adapter: node({
    mode: "standalone",
  }),

  vite: {
    plugins: [tailwindcss()],
  },
});

Set Up Supabase SSR

Open an integrated terminal window and paste this command to add both the supabase-js client library and the SSR auth package to the project:

npm install @supabase/supabase-js @supabase/ssr

Create an .env file in the root of the project and paste this into it.

SUPABASE_URL=<YOUR_URL>
SUPABASE_ANON_KEY=<YOUR_ANON_KEY>

Get the correct values from the Supabase dashboard:

Note: In Astro, all environment variables to be accessed on the client side need to be prefixed by PUBLIC, but in this case, we will be using Astro actions that run on the server, so we wont need the prefix.

Then, create a lib folder in the src folder and add a supabase.ts file. Paste this code into it:

import { createServerClient, parseCookieHeader } from "@supabase/ssr";
import type { AstroCookies } from "astro";

export function createClient({
    request,
    cookies,
}: {
    request: Request;
    cookies: AstroCookies;
}) {
    return createServerClient(
        import.meta.env.SUPABASE_URL,
        import.meta.env.SUPABASE_ANON_KEY,
        {
            cookies: {
                getAll() {
                    return parseCookieHeader(request.headers.get("Cookie") ?? "");
                },
                setAll(cookiesToSet) {
                    cookiesToSet.forEach(({ name, value, options }) =>
                        cookies.set(name, value, options)
                    );
                },
            },
        }
    );
}

This sets up Supabase to handle cookies in a server-rendered application and exports a function that takes in the request and cookies object. The function is set up like this because Astro has three ways to access request and cookie information:

Through Astros global object, which is only available in Astro pages.
Through AstroAPIContext object, which is only available in Astro actions.
Through APIContext which is a subset of the global object and is available through API routes and middleware.

So the createClient function accepts therequest and cookies objects separately to make it flexible and applicable in the different contexts in which it may need to be used.

Next, create a middleware.ts file in the src folder and paste this into it:

import { defineMiddleware } from "astro:middleware";
import { createClient } from "./lib/supabase";

export const onRequest = defineMiddleware(async (context, next) => {
    const { pathname } = context.url;

    console.log("Middleware executing for path:", pathname);

    const supabase = createClient({
        request: context.request,
        cookies: context.cookies,
    });

    if (pathname === "/protected") {
        console.log("Checking auth for protected route");

        const { data } = await supabase.auth.getUser();

        // If no sess, redirect to index
        if (!data.user) {
            return context.redirect("/");
        }
    }

    return next();
});

This file checks to see if there is an active user when we are on the protected route. If there is no user, it redirects to the index page, and if there is an active user, it allows the request to continue as is.

Thus guarding the protected route from unauthenticated access.

Set up the UI

Open the pages folder in the src and replace the contents of index.astro with:

---
import Layout from "../layouts/Layout.astro";
import { createClient } from "../lib/supabase";
import "../styles/global.css";

const supabase = createClient({
    request: Astro.request,
    cookies: Astro.cookies,
});

const { data } = await supabase.auth.getUser();

if (data.user) {
    return Astro.redirect("/protected");
}
---

<Layout>
    <section class="flex flex-col items-center justify-center m-30">
        <h1 class="text-4xl text-left font-bold mb-12">Sign In to Your Account</h1>
        <form id="signin-form" class="flex flex-col gap-2 w-1/2">
            <label for="email" class="">Enter your email</label>
            <input
                type="email"
                name="email"
                id="email"
                placeholder="youremail@example.com"
                class="border border-gray-500 rounded-md p-2"
                required
            />
            <button
                type="submit"
                id="sign-in"
                class="bg-gray-600 hover:bg-gray-700 p-2 rounded-md text-white font-bold w-full cursor-pointer disabled:bg-gray-500 disabled:hover:bg-gray-500 disabled:cursor-not-allowed"
                >Sign In</button
            >
        </form>
    </section>
</Layout>

Here, the frontmatter creates a supabase server client and then uses it to check if we have an active user. It redirects based on this information. This works because the front matter runs on the server side, and the project is set to server output.

The template displays a simple form with an email input. To complete it, add this below the closing </Layout> tag:

<script>
    import { actions } from "astro:actions";

    const signInForm = document.querySelector("#signin-form") as HTMLFormElement;
    const formSubmitBtn = document.getElementById("sign-in") as HTMLButtonElement;

    signInForm?.addEventListener("submit", async (e) => {
        e.preventDefault();
        formSubmitBtn!.disabled = true;
        formSubmitBtn!.textContent = "Signing in...";

        try {
            const formData = new FormData(signInForm);

            const results = await actions.signIn(formData);

            if (!results.data?.success) {
                formSubmitBtn.disabled = false;
                formSubmitBtn.textContent = "Sign In";
                return alert("Oops! Could not sign in. Please try again");
            }

            formSubmitBtn.textContent = "Sign In";
            return alert("Please check your email to sign in");
        } catch (error) {
            formSubmitBtn.disabled = false;
            formSubmitBtn.textContent = "Sign In";
            console.log(error);
            return alert("Something went wrong. Please try again");
        }
    });
</script>

This adds some vanilla JavaScript that calls the SignIn action on form submit, provides user feedback through the alerts, and manages the buttons text and disabled state. This effectively adds client-side interactivity to the page.

Next, create a new protected.astro file in the pages folder and paste this into it:

---
import Layout from "../layouts/Layout.astro";
import { createClient } from "../lib/supabase";
import "../styles/global.css";

const supabase = createClient({
    request: Astro.request,
    cookies: Astro.cookies,
});

const { data } = await supabase.auth.getUser();
---

<Layout>
    <section class="flex flex-col items-center justify-center m-30">
        <h1 class="text-4xl text-left font-bold mb-12">You are logged in!</h1>
        <p class="mb-6">Your user Id: {data.user?.id}</p>
        <button
            id="sign-out"
            class="bg-gray-600 hover:bg-gray-700 px-4 py-2 rounded-md text-white font-bold cursor-pointer disabled:bg-gray-500 disabled:hover:bg-gray-500 disabled:cursor-not-allowed"
            >Sign Out</button
        >
    </section>
</Layout>

<script>
    import { actions } from "astro:actions";
    const signOutBtn = document.getElementById("sign-out") as HTMLButtonElement;

    signOutBtn?.addEventListener("click", async (e) => {
        e.preventDefault();
        signOutBtn!.disabled = true;
        signOutBtn!.textContent = "Signing out...";

        try {
            const results = await actions.signOut();

            if (!results.data?.success) {
                signOutBtn!.disabled = false;
                signOutBtn!.textContent = "Sign Out";
                return alert("Oops! Could not sign Out. Please try again");
            }
            return window.location.reload();
        } catch (error) {
            signOutBtn.disabled = false;
            signOutBtn.textContent = "Sign Out";
            console.log(error);
            return alert("Something went wrong. Please try again");
        }
    });
</script>

This page gets the user data server-side in the frontmatter and displays it in the template along with a sign-out button.

The JavaScript in the script tags handle calling the sign-out action, user feedback, and button stat,e as in the index.astro page.

Set Up Astro Actions

Finally, add actions folder in the src folder and create an index.ts file to hold our logic. Paste the following into it:

import { defineAction, type ActionAPIContext } from "astro:actions";
import { z } from "astro:schema";
import { createClient } from "../lib/supabase";

const emailSignUp = async (
    {
        email,
    }: {
        email: string;
    },
    context: ActionAPIContext
) => {
    console.log("Sign up action");
    try {
        const supabase = createClient({
            request: context.request,
            cookies: context.cookies,
        });

        const { data, error } = await supabase.auth.signInWithOtp({
            email,
            options: {
                emailRedirectTo: "http://localhost:4321/api/exchange",
            },
        });

        if (error) {
            console.error("Sign up error", error);
            return {
                success: false,
                message: error.message,
            };
        } else {
            console.log("Sign up success", data);
            return {
                success: true,
                message: "Successfully logged in",
            };
        }
    } catch (err) {
        console.error("SignUp action other error", err);
        return {
            success: false,
            message: "Unexpected error",
        };
    }
};

export const server = {
    signIn: defineAction({
        accept: "form",
        input: z.object({
            email: z.string().email(),
        }),
        handler: async (input, context) => {
            return emailSignUp(input, context);
        },
    }),
    signOut: defineAction({
        handler: async (_, context) => {
            const supabase = createClient({
                request: context.request,
                cookies: context.cookies,
            });
            const { error } = await supabase.auth.signOut();
            if (error) {
                console.error("Sign out error", error);
                return {
                    success: false,
                    message: error.message,
                };
            }
            return {
                success: true,
                message: "Successfully signed out",
            };
        },
    }),
};

This action takes care of both the sign-in and the sign-out methods. A supabase server instance is created in the sign-in method, and the magic link method is used to sign in. It passes a redirect URL, which we have yet to create, and handles errors.

The sign-out method calls Supabases sign-out method and handles any potential errors.

The redirect URL refers to an API route that exchanges the code from the email Supabase sends for a session that Supabase handles.

In the pages folder, add an api folder and create within it exchange.ts file. Paste this into it:

import type { APIRoute } from "astro";
import { createClient } from "../../lib/supabase";

export const GET: APIRoute = async ({ request, cookies, redirect }) => {
    const url = new URL(request.url);
    const code = url.searchParams.get("code");

    if (!code) {
        return redirect("/");
    }

    const supabase = createClient({ request, cookies });
    const { error } = await supabase.auth.exchangeCodeForSession(code);

    if (error) {
        console.error("Error exchanging code for session:", error);
        return redirect("/404");
    }

    return redirect("/protected");
};

This grabs the code from the URL in the magic link sent, creates a server client, and calls the exchangeCodeForSession method with the code. It handles any error by redirecting to Astros built-in not-found page.

Otherwise, it will redirect to the protected page as Supabase handles the session implementation details.

Running the App

In an integrated terminal, run npm run dev to start the app, you should see this UI:

If you try to access the /protected page will redirect you back to this view until you sign in. Now, sign in, and you should get an email with a link that will redirect you to the /protected page. This is what you should see:

With that, the project now uses Supabase SSR and is set.

Notes and Resources

Here are some useful resources on SSR, Astro and Supabase:

Next Steps: Seeking New Opportunities in Frontend, Design Systems, and DX

Fatuma Abdullahi — Wed, 05 Feb 2025 05:43:38 +0000

Over the last couple of months, I have been working on migrating Wikimedias design system, Codex, to Penpot. So far, Ive successfully recreated over 1,000 components and variants, and Im about to start the final phase - piloting the new library and prepping reports.

While this was an exciting and fun project, its a short-term project. As it wraps up, Im actively looking for new opportunities in front-end development - ideally in open source, design systems, and accessibility.

The Backstory

My tech career has always been one of exploration, curiosity, and experimentation. Over the years, I have tried UI design, Frontend, Mobile Multi-platform, Serverless, Microservices, Databases, Open-source, and Technical writing. I even took a brief detour into DevOps - and quickly turned back 😅. It was clear that it just wasnt my thing.

This enabled me to gain a broad understanding of development work and clarified what I was good at and which parts I enjoyed the most. No surprise that, as a creative, artsy, and poetic person - I have firmly come back around to frontend, design systems, and product documentation.

Key Technical Achievements Im Proud Of

During my exploration stage, I had some technical achievements that I'm proud of, including:

Leading the exploratory transition of Wikimedias Design System from Figma to Penpot.
Simplified authentication for Flutter and Supabase users by contributing a helper auth library with ready-to-use widgets. The library has 13 contributors, 59 GitHub stars, and 29 forks. It is on Pub.dev and has a 73% popularity score.
Added a working mobile version of the playground editor, making learning Ocaml.org accessible to mobile users for the first time.
Increased web accessibility levels of OpenSauceds codebase by co-leading efforts with Nick Taylor, Developer Advocate at Pomerium, to enforce the standards via JSX-ally-plugin.
Added product guides to OpenSauceds documentation to help onboard new developers to common terms used in the open-source space.
Successfully migrated an unfamiliar JavaScript codebase over to using strict TypeScript.
Optimizing database reads by breaking apart large backend functions into smaller microservices.

Key Community and Content Engagements Im Proud Of

Beyond code, I also participate in the community by giving talks, writing tutorials, and organizing events. Some of the work Im most proud of includes:

Talking about accessibility and authentication at DevFest Pwani and getting featured in their highlight video.
Joining Supabases SupaSquad - an unofficial group of advocates.
Organizing multiple events for Supabases launch week across two cities, with a turnout of about 40%.
Getting accepted into Googles Road to GDE cohort 3 program
Becoming a FreeCodeCamp author.
Becoming a Guest Author on CSS-Tricks and Cerbos.
Becoming a volunteer community manager for Open Source Community Africa (OSCA).

So, Whats Next for my Tech Career?

My next goal is to land a remote full-time or part-time role, ideally within the open-source ecosystem.

The Perfect Organization

Id be most excited to work with organizations that are:

Open-source, open core, or that give back to open source in some way.
Concerned with building accessible products.
In the DevTool space or that are working towards a noble goal greater than themselves. For example, Wikimedias goal is to democratize the worlds knowledge.
Fully remote, hiring globally, or that are willing to offer relocation sponsorship.

The Perfect Role

Id be most excited to work on the following verticals:

Frontend heavy full-stack roles
Frontend roles that include building and maintaining design systems in code or design tools.
Frontend plus working on product documentation and tools.
Technical Developer Experience (DX) roles

Why You Should Hire Me

Here are some reasons Id be a fit for your team:

All-Rounded Product Developer - I have a broad general understanding of the entire product lifecycle, giving me a unique perspective on building user-friendly and scalable products.
Frontend and Design Systems- I have experience using modern technologies like React.js, Next.js, Astro, and Tailwind. I also have experience working with design systems.
Web Accessibility Advocate I co-led accessibility improvements in OpenSauceds codebase and actively share accessibility best practices.
Open-Source and Community Presence - I share what I learn and Im an active member of the tech community.
Remote experience - I have professional, remote, and open-source experience. I can work in async environments and collaborate across cultures and time zones.

When Can I Start?

Im ready to start in March 2025, when my current project at Wikimedia will be ending. You can reach me via Twitter, LinkedIn or Email.

You can also reach out to any of these amazing open-source developers Ive collaborated with:

Sabine Schmaltz, OCaml.org Maintainer, Developer Relations at Tarides- I worked closely with Sabine on making front-end changes to Ocaml.orgs website.
Tyler Shukert, Developer Relations at Supabase - I worked with Tyler to bring Flutter Auth UI to life.

Wrapping up

If youre building in open-source, DevTools, or accessibility-focused products and need a frontend developer who bridges design and loves documentation - please reach out! And if you know someone who does, please share my profile.

]]>