Forem: Leonardo Montini

Automate UI Bug Fixing with Chrome MCP Server and Copilot

Leonardo Montini — Mon, 24 Nov 2025 20:03:04 +0000

I recently had a look at the Chrome MCP server and it looks really cool. So, let me show you a quick example of what it can do.

Getting Started

First of all, if you don't have it installed yet, there are instructions available. Like every other MCP server, you just need to have somewhere in your client settings the configuration string.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

I'm using VS Code, which has a command in the CLI for this. You can just open a new terminal, paste the command, and that's basically it.

code --add-mcp '{"name":"chrome-devtools","command":"npx","args":["chrome-devtools-mcp@latest"]}'

In any case, full instructions are in the Chrome MCP server documentation.

If you want to make sure it is installed, you can open your user configuration (F1 => MCP: Open User Configuration) and find the server there. Also, as soon as you open a new chat, you can click the tools icon and find "Chrome tools" listed.

Demo Run

I have an application running on localhost, but there's a small UI issue. If you hover over a specific card, the text of some badges becomes unreadable. That's the bug we're going to validate and fix through the Chrome MCP server tools.

^ this screen has been taken by the MCP server itself!

Back to our project, I can ask the AI to navigate to the page with the bug and take action. This was my prompt:

Navigate here with the chrome-devtools mcp: http://localhost:3000/events/js-event-2026

You'll notice that if you hover on the cards on similar events, some tags are hard to read. Verify and fix that

The Fix in Action

Once the request is made, it starts launching the Chrome MCP server. A Chrome window appears, controlled entirely by the agent.

The first step it takes is to navigate to the page. Then, it takes a snapshot. This isn't just a screenshot, but a deconstructed view of the page where unique IDs are assigned to each text, link, or button. This allows the agent to understand the structure of the page by using way less tokens than a full HTML dump.

Here's an example:

# take_snapshot response
## Page content
uid=1_0 RootWebArea "JS Event - ConfHub" url="http://localhost:3000/events/js-event-2026"
  uid=1_1 banner
    uid=1_2 link "ConfHub" url="http://localhost:3000/"
      uid=1_3 StaticText "ConfHub"
    uid=1_4 navigation "Main"
      uid=1_5 link "Submit Event" url="http://localhost:3000/events/submit"
        uid=1_6 StaticText "Submit Event"
      uid=1_7 link "Communities"
...

It then identifies the correct element, in this case, the "React Conference 2026" card (via its uid=1_31), and decides to hover over it. I allow the action, and Chrome performs the hover automatically. It then takes a screenshot to visualize the problem within the chat context.

This is what the chat log looks like at this point, after the agent ran the tools provided by the MCP server:

After confirming the issue, the agent searches for the relevant component. it identifies the mistake, (in this case by checking the badge component) and applies a fix.

Validation

To ensure the fix works, the agent goes back to the page. Since the project has Hot Module Reload the changes should be immediate, but to be safe, it refreshes the page. It then attempts to hover again over the card.

^ yes, this screen has been taken by the MCP server too, to validate the fix!

The bug is now be fixed! The text is readable 👀

Conclusion

In this demo (as you can see in the video), I was allowing each tool call manually to maintain full control and explain them step by step. However, imagine letting this run on a cloud agent with all tools executable autonomously. It's impressive that an independent agent can navigate, interact, take screenshots, and validate fixes without constant human intervention.

The result will be a pull request containing not just the code changes, but also the validation screenshots, making the review process much easier.

That was just a quick showcase of one feature I recently tested on the Chrome DevTools MCP server. If you're curious about other MCP servers you want me to try, just let me know. Tell me the name of the server and I'm going to give it a try.

Thanks for reading!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

How GitHub Copilot Uses MCP Tools Behind the Scenes

Leonardo Montini — Tue, 18 Nov 2025 20:16:16 +0000

Before we dive into the details, here is the video version of this article if you prefer to watch it first and then come back here for a slower, written walkthrough. If you prefer to read, you can safely skip it and continue with the examples below.

Let's begin with an easy example to make things concrete.

You open a new chat and ask Copilot a simple but very practical question: "is there any pull request waiting for me?"

After a brief pause and some behind-the-scenes magic, Copilot replies with the exact list of pull requests that need your attention. No manual search, no switching tabs. In the rest of this article, we'll unpack what actually happened behind the scenes.

In this article, we'll look at how that "magic" of MCP Tools really works, using the GitHub MCP server as an example.

From a simple question to the right tool

In the pull request example above, when you ask Copilot about your pull requests, it is not "guessing" the answer as it can't know by itself. Instead, it is using a tool provided by the GitHub MCP server to search your repositories.

Installing an MCP server is basically telling the LLM client where the server lives and how to talk to it. For example, a server might be hosted at a URL like https://api.githubcopilot.com/mcp/, and the client can talk to it over HTTP.

But the location of the server is only part of the story. What really matters is which tools that server exposes.

From the GitHub Chat UI, if you click on the Tools button, for each server you see the list of registered tools together with their descriptions. In the GitHub MCP, for example, you'll find a tool that searches pull requests.

That's the one Copilot used to answer my question about open PRs.

How Copilot discovers the tools

So far we've focused on what the tools do, the next step is understanding how Copilot becomes aware of them in the first place.

The answer is in the Model Context Protocol (MCP) specification.

As soon as the client starts up, for example when VS Code launches, the MCP client asks each registered server for a list of tools.

The server replies with a list that includes, for each tool:

The tool name
A description
The input schema (which parameters it expects)

This list is then made available to the language model. In other words, Copilot can see a catalog like "there is a search_pull_requests tool that takes a query, an owner, and a repository."

From there, the model can decide which tool to call and how to fill in those inputs.

{
  "query": "repo:Balastrong/confhub is:open",
  "owner": "Balastrong",
  "repo": "confhub"
}

Copilot chooses the values for these fields based on your question, the current repository context, and other metadata. Then it sends that payload to the MCP server.

The server runs its own logic, talks to external APIs if needed, and returns a structured output.

{
  "total_count": 1,
  "incomplete_results": false,
  "items": [
    {
      "id": 3592203585,
      "number": 5,
      "state": "open",
      "locked": false,
      "title": "Modernize create community form with card-based layout and visual elements",
      "body": "The create community form ...",
      "created_at": "2025-11-05T17:57:06Z",
      "updated_at": "2025-11-08T15:46:28Z"
    },
    ...
  ]
}

Turning raw tool output into answers

The response coming back from the MCP server is not what you see in the chat.

The tool returns structured data: objects, arrays, fields with IDs, titles, URLs, and so on. This is extremely useful for the model, but not necessarily friendly for humans.

When Copilot receives that output, it treats it as additional context, not as the final answer. With this extra data, the model can:

Pick only the relevant fields
Format them nicely
Explain what is going on in natural language

This is the step where raw tool output becomes the clear answer in your chat, powered by real data from the MCP server.

At this point, you know how Copilot finds the right tool and turns its output into something readable. But there is still an interesting question left.

How does Copilot know who you are?

In the earlier example, the pull request search tool needs to know which user and repository it should work with.

If you look at the MCP output tab, you can see that the Copilot chat is initialized with your GitHub username and other pieces of repository context.

Out of curiosity, you can even ask Copilot directly: "what is my GitHub username?" It can answer based on the repository context and the information injected into the session.

More specifically, Copilot chat adds details like:

Your GitHub username
The repository you are working in
The current branch
And other metadata needed by tools

This is how the language model "knows" who you are inside Copilot chat: not by guessing, but because the client explicitly shares that information as part of the context.

Why understanding this matters

It is easy to look at these features and think that everything is pure magic.

But when you understand that there is a clear protocol, a list of servers, a list of tools, input schemas, and structured outputs, everything becomes much more tangible.

Knowing how things move behind the scenes gives you more control. You can:

Better understand what Copilot is capable of
Reason about which tools might be useful for your workflow
Design or configure MCP servers that expose exactly the tools you need

Magic is cool, but knowledge is your real power.

I'm planning to create more content exploring how VS Code, Copilot, and MCP work together, going beyond the "wow" moment and into the practical details.

Thanks for reading. I hope this answered some of your questions about how Copilot uses MCP tools.

See you in the next one!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

Codemotion Milan 2025: Why Large Tech Conferences Matter

Leonardo Montini — Wed, 22 Oct 2025 15:52:00 +0000

I have wanted to write about tech conferences for a while, and last week I was at Codemotion in Milan. Perfect excuse to finally do it.

If you follow me here you know I usually share tutorials and technical content, but there is another huge part of our craft that I discovered only a few years ago: conferences. They open new opportunities and new ways of thinking that you will miss if you only focus on the tech. That would be a shame.

While I am still wearing the conference badge, here is why I think you should go to large tech events, what to expect, the pros, and yes, the cons.

Watch the video

This article is actually an edited version of me rambling for ten minutes, you can watch it here:

Meet people

The biggest advantage is simple: meet people. It may sound weird at a technical conference with folks on stage talking about code, but the highest value often comes from the hallway track.

Even as an attendee in the audience you get to meet a lot of amazing people. At Codemotion this year there were roughly 3000 attendees in the same venue, so there is plenty of room to find interesting conversations. As developers we might not love chit chat, but conversations at conferences are nothing like daily standups or status meetings. It is a different vibe, and among thousands of people you will surely find someone you click with.

These events are also designed to help you connect, not only to listen or deliver great talks. One thing I love at Codemotion is the Tech Expert booths: tables with experts on specific topics. You walk up, start from a shared interest like React or machine learning, others join, and it quickly becomes a small group discussion. It is a great way to meet new people.

I usually go with friends I met at work or at other events, but even if you go alone you will find many ways to make new ones. In large conferences you will keep seeing the same faces across editions and your relationships get stronger. You never know how much value can come from those interactions.

Talking to people lets you see the world from different points of view. We all live in a company bubble, which is fine and inevitable, but hearing from other developers, PMs, and folks in the industry broadens your perspective. It helps shape your opinions. The more you know, the better.

Hard skills? Curiosity!

On paper the selling point of conferences should be the technical content. You go for the schedule of interesting talks. Sure, you can pick up hard skills from a session with an expert on stage, but for most talks the biggest takeaway is not learning a new syntax on the spot.

It is about getting inspired. A 30 to 40 minute session is not a course or a masterclass. You are not expected to walk out with deep understanding. Instead, you leave with a spark. You hear the right keywords, see a demo, and your curiosity switches on. Then when you get home you open your laptop and try it yourself. That is where the real learning happens. The talk gives you pointers and context so your research is faster and more focused.

Keynotes

Large events also bring in great keynotes. On day two at Codemotion we had Scott Chacon, co-founder of GitHub, on stage talking about the why behind things. Hearing stories from people who actually built something meaningful is a huge source of inspiration. You get a glimpse into their thought process and collect advice you can apply to your own career.

And the coolest part is that it is not a YouTube video. The person is there, in the same venue. If you are lucky you can even meet them, shake hands, and have a quick chat. In the era of AI generated content, real life human interactions keep gaining value.

Many parallel tracks

Not everything is perfect. The thing I like the least about large conferences is when there are too many parallel tracks. It is intentional and inevitable, but when there are six or seven tracks at the same time it gets hard to choose.

It is a happy problem to have many great options, but sometimes there are three talks you want to attend in the same slot and you can only pick one. Recordings help, but let's be honest: the magic is being there live. I do watch recorded talks, especially from events I could not attend, but for the ones I skip on site I rarely catch up later. You should, though. If recordings are available, watch them to fill the gaps.

Large crowd

Crowds can be a downside too. Venues are usually huge, so if the area near the stages is packed you can step outside and breathe. There is almost always space.

The tricky part is meeting someone specific. With so many people you will need to text and coordinate. It happened this year that I wanted to meet a couple of folks and never bumped into them. A simple tip: post on LinkedIn or your socials that you will be at the conference so friends and connections can plan to meet you at a specific spot.

Tickets and travel

Travel time and ticket costs are real tradeoffs. Big events tend to be pricey, but if you know you are going keep an eye on early bird tickets. They are usually much cheaper. The same applies to travel and accommodation: planning ahead saves money.

Should you go?

Wrapping up: large tech conferences get a big yes from me. You know the pros and the cons. Go there, learn, network, and most importantly have fun. We are there to meet people, grow, and enjoy the experience.

This one was about large events like Codemotion Milan. The world of tech events also includes medium and small conferences. I attended a couple of those this month, and one where I was a speaker, so I might write about them next. Stay tuned!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

ReactJS Day 2025: TanStack Start & Real World Experiences

Leonardo Montini — Mon, 20 Oct 2025 18:32:45 +0000

When I'm writing this I'm still on the train back from ReactJSDay, the largest conference on ReactJS in Italy, reflecting on something that happened from the audience.

I gave my talk about TanStack Start, showcasing why I like this full stack framework and how it is powered by TanStack Router, my favourite routing library as of today.

At the end of the session I got a question about how much effort would it take to migrate a very large React Router codebase to TanStack Router. My answer has been honest: I’ve been lucky enough to always start fresh with TanStack Router or only migrate smaller project so I didn’t have a direct experience to share. By the book it is indeed doable (and there’s a migration guide in the docs), but that was it from my side.

However, during lunch there was a board where attendees could reserve a spot for a lightning talk and to my surprise I’ve seen a proposal about "how we migrated a huge codebase from React Router to TanStack Router".

The attendee showed up on stage, opening up with "I heard the question from this morning talk, we did that migration on my team and I wanted to share how it went" and I absolutely loved it!

My talk was relatively easy, I had my slides, all demos prepared on vscode (thanks Elio for Demo Time, such an amazing tool for speakers) but showing up with a spontaneous and unprepared lighting talk, sharing about a real world experience, is just something else.

I feel bad I didn’t take a picture of the lightning talks board and I only remember the attendee is called Linus, if you get to see this post please let’s connect!

Thank you Grusp for having me on stage, Claranet Italia for supporting my DevRel journey and everyone who attended the event, such a magical one!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

TanStack Router: Go to Previous page after Sign In

Leonardo Montini — Tue, 16 Sep 2025 14:36:21 +0000

Welcome back to the TanStack Router series, today going double digits with chapter 10!

Let's fix a very common UX issue when implementing authentication flows. You navigate to a page then you're forced to sign in, but then you get redirected to the homepage. Maybe you set some filters or data, now everything is gone.

In this article I will show two approaches to redirect users back to the page they were on right before signing in, keeping any query parameters intact. First the classic explicit redirect, then an alternative that can capture the previous location automatically.

Video version here: https://youtu.be/MXffKeNfOvQ

The problem in one sentence

You sign in and get redirected to the homepage, losing the page and search parameters you had before.

Approach 1: explicit redirect via search param

This is the straightforward and reliable solution. We explicitly pass a redirectTo param everywhere the user can navigate to the sign in page and we use it to go back after signing in.

Our Sign In form component will look like this, it defaults to the homepage or redirects to the provided URL after a successful sign in.

export const SignInForm = ({ redirectTo = '/' }: { redirectTo?: string }) => {
  const navigate = useNavigate();

  const signIn = () => {
    // Your sign in logic here

    navigate({ to: redirectTo });
  };

  return (
    <form onSubmit={signIn}>
      {/* form fields */}
      <Button type="submit">Sign In</Button>
    </form>
  );
};

But where does redirectTo come from? Let's add it as a search parameter to the sign in route.

import { createFileRoute } from '@tanstack/react-router';
import { SignInForm } from 'src/components/auth/sign-in-form';
import { Layout } from 'src/components/layout';
import { z } from 'zod';

export const Route = createFileRoute('/sign-in')({
  component: RouteComponent,
  validateSearch: z.object({
    redirectTo: z.string().optional().catch('/'),
  }),
  // ...
});

function RouteComponent() {
  const { redirectTo } = Route.useSearch();

  return (
    <Layout>
      {/* ... */}
      <SignInForm redirectTo={redirectTo} />
      {/* ... */}
    </Layout>
  );
}

What is that validateSearch doing? It uses Zod to parse the search parameters and extract redirectTo, defaulting it to / if not provided. Then in the component we read it with Route.useSearch() and pass it down to the SignInForm.

If you want to learn more about handling search parameters with TanStack Router, check out my previous article: Handling Query Parameters.

The next steps is to ensure that every link to the sign in page includes the redirectTo parameter. Here's an example in the Header component:

import { useRouter } from '@tanstack/react-router';
import { ButtonLink } from '../button-link';

export const Header = () => {
  const router = useRouter();

  return (
    <header>
      {/* ... */}

      <ButtonLink to="/sign-in" search={{ redirectTo: router.state.location.href }}>
        Sign In
      </ButtonLink>
      {/* ... */}
    </header>
  );
};

What is ButtonLink? It is just a styled wrapper around the Link component from TanStack Router. You can use Link directly if you prefer or learn how to create your own custom link component in a video I made about it: https://youtu.be/-kmf3ZYlduU

With this, after a successful sign in you will land back on the original page including all the search parameters.

Tradeoff of the explicit approach

You must remember to add the redirectTo param in every link to the sign in page. Not a big issue though, and you can wrap it in a helper or custom hook like a "go to sign in" utility, but it is still one more thing to do.

Approach 2: capture previous location automatically

I also experimented with a small hook that tracks the previous location without passing any search parameters to the sign in page. I'm not entirely sure how stable and reliable this is, but it worked well in my tests so I thought it was worth sharing:

function usePreviousLocation() {
  const router = useRouter();
  const [previousLocation, setPreviousLocation] = useState<string>('/');
  useEffect(() => {
    return router.subscribe('onResolved', ({ fromLocation }) => {
      setPreviousLocation(fromLocation?.href ?? '/');
    });
  }, []);
  return previousLocation;
}

This hook subscribes to the router's navigation events and captures the "from" location after each navigation. It stores it in state so it can be used later.

With this alone you can forget about everything we already said, you'll no longer need to pass redirectTo in each navigation or handle search params. Just use the hook in your sign in form:

export const SignInForm = () => {
  const navigate = useNavigate();
  const previousLocation = usePreviousLocation();

  const signIn = () => {
    // Your sign in logic here

    navigate({ to: previousLocation });
  };

  return (
    <form onSubmit={signIn}>
      {/* form fields */}
      <Button type="submit">Sign In</Button>
    </form>
  );
};

Combine both for a robust UX

The two approaches might also work well together. You can prefer the explicit redirectTo when provided, and fall back to the previously captured location when it is not. This covers both deliberate redirects and default behavior without extra effort.

export const SignInForm = ({ redirectTo }: { redirectTo?: string }) => {
  const navigate = useNavigate();
  const previousLocation = usePreviousLocation();

  const signIn = () => {
    // Your sign in logic here

    navigate({ to: redirectTo ?? previousLocation });
  };

  return (
    <form onSubmit={signIn}>
      {/* form fields */}
      <Button type="submit">Sign In</Button>
    </form>
  );
};

Notes

This article focuses on TanStack Router, but the same idea works in TanStack Start too.
If you are using authenticated routes or guards, you might also like this related article: Authenticated Routes and Guards.

Conclusion

That is it. With either the explicit redirect or the previous location approach, you can make your sign in flow return users to exactly where they left off, preserving query parameters and their context.

If you have different ideas or improvements, let me know in a comment.

Code is taken from the ConfHub project, you can find it here: https://github.com/Balastrong/confhub

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

4 Free Methods to use LLM APIs in Development

Leonardo Montini — Tue, 09 Sep 2025 10:16:55 +0000

You might be in the situation I was the other day: I wanted to develop a small AI feature for learning purposes on my side project, but I didn’t want to pay for an api key.

So I did some research: let me show you 4 different ways I found to do that for free, with also the possibility of switching between a wide range of models, so you can pick the best for your usecase.

My first attempt obviously went to Ollama to run models locally, then I had a go at the free tiers of some hosted providers.

You can hear me talking about those and showing some steps and demos in this YouTube video or you can keep reading below.

Code setup

Let's begin with some good news: all the four methods work with the exact same code as luckily they all support the OpenAI SDK. The only change will be setting the right values in your environment variables.

If you're curious you can find here the actual code I'm using in my demo, including the system prompt and my silly attemps to force the model to behave and answer as I want.

Anyway, I don't want to add any unnecessary complexity to this article so I'll just show a summary that you can use as a starting point:

import OpenAI from 'openai';

const token = process.env.LLM_TOKEN!;
const endpoint = process.env.LLM_ENDPOINT!;
const model = process.env.LLM_MODEL!;

export async function prompt(userPrompt: string) {
  const client = new OpenAI({ baseURL: endpoint, apiKey: token });

  const response = await client.chat.completions.create({
    messages: [
      { role: 'system', content: 'You are a helpful assistant.' },
      { role: 'user', content: userPrompt },
    ],
    model: model,
  });

  console.log(response.choices[0].message.content);
}

1. Ollama - Run models locally

Homepage: https://ollama.com/

That's the first thing I tried as I wanted to see how it works to run models locally. Long story short: they made it so easy it's like pulling docker images. There's literally a ollama pull command.

You can install the app from the website then you'll find the ollama command line tool in your path. Actually when I did it a couple of weeks ago the app was almost empty, now I see they started adding features like a UI where you can chat with your installed models (in addition to talking with the in the terminal) and some other nice touches.

At this point you might want to have some models, right? You can find a list in their Models page then open a terminal and run ollama pull <model-name> to download it. Before picking a model have a look at the size (might be many GB) and get ready to have slow responses if your machine is not powerful enough.

You can see at any time what models you have with ollama ls.

Back to our quest of learning how to use LLMs in our code, now that you have Ollama up and running with at least a model downloaded, you can set these values for your environment variables:

LLM_TOKEN=ollama
LLM_ENDPOINT=http://localhost:11434/v1
LLM_MODEL=<your_downloaded_model>

You're good to go!

2. GitHub Models - Hosted

Homepage: https://github.com/marketplace?type=models
Free Tier: https://docs.github.com/en/github-models/use-github-models/prototyping-with-ai-models#rate-limits

Ollama was fun but I wasn't using really smart models and at some point I wanted to push my AI feature to production so... I couldn't just say "works on my machine with Ollama", I had to find a hosted solution. For free.

The first service I tried was GitHub Models. It basically offers some of the most recent models with a free tier (you don't even need a Copilot subscription) that you can test already in the browser.

You can also use them in your app and you just need a single API key: a GitHub Personal Access Token (PAT).

You can generate one from your developer settings, but on the Models marketplace you'll find a direct link to make it literally one click. It should also work from here: https://github.com/settings/personal-access-tokens/new

Once you have the token, set it in your environment variables and again you're good to go!

LLM_TOKEN=<your_github_pat>
LLM_ENDPOINT=https://models.github.ai/inference
LLM_MODEL=<model_name>

In my app I just set these variables on Netlify to make the AI feature work on my production site.

3. Open Router - Hosted

Homepage: https://openrouter.ai/
Free Tier: https://openrouter.ai/docs/api-reference/limits

I was happy with GitHub Models but for the sake of a good research I wanted to try multiple providers. Open Router is another hosted solution that offers a free tier but on some selected models.

You can find them all by filtering the list for :free in the model name.

Once you sign up you can get your API Key from the settings and put it in your environment variables as usual:

LLM_TOKEN=<your_open_router_api_key>
LLM_ENDPOINT=https://openrouter.ai/api/v1
LLM_MODEL=<model_name:free>

4. Groq - Hosted

Homepage: https://groq.com/
Free Tier: https://console.groq.com/docs/rate-limits#rate-limits

The first thing I said when a colleague told me about Groq is "wait isn't it called Grok?" and no it wasn't a typo, they're two very different things.

Groq is a hardware company that runs LLMs on their own chips.

Similarly to Open Router, with a Groq API key you can access a selection of supported models and switch between them by changing the model name in your environment variables.

You can get the key after signing up, but you shouldn't be surprised now after reading the previous sections. Luckily, most of these providers work in a very similar way.

LLM_TOKEN=<your_groq_api_key>
LLM_ENDPOINT=https://api.groq.com/openai/v1
LLM_MODEL=<model_name>

Bonus

These approaches I tried were all giving the possiblity to switch between different models, which is great to find the best one for your usecase.

In any case, all LLMs providers usually have their own free tiers. There's plenty of options you can pick directly from the vendor, be it OpenAI, Anthropic, Google, etc.

When it's time to go to production... well, that's another story.

What are you using for development? And what are you using in production? Let's discuss in the comments!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

TanStack Start: light, dark, and system theme without flickers

Leonardo Montini — Mon, 25 Aug 2025 12:33:00 +0000

Having multiple themes is a common request on (web) applications nowadays, at least having light, dark, and system (define dark/light automatically from the user's system).

If your application has also some sort of server-side rendering, this seemingly simple request might quickly become more complex than expected, in particular once you start seeing issues like:

The app initially loads with the wrong theme (FOUC: Flash Of Unstyled Content)
You refresh the page and the theme is gone
The user changes the system theme and the app doesn't follow
Some weird errors are logged as client-only APIs are called on the server
Hydration issues everywhere
... the list goes on

Implementation Details

I recently took some time to implement a robust approach for a TanStack Start application (code here) and I recorded a video where I explain step by step all the moving parts, you can watch it here and keep this written article as reference for later.

The two theme types

Let's begin with the types definition. I like to distinguish between what the user chooses and what the app actually renders:

export type UserTheme = 'light' | 'dark' | 'system';
export type AppTheme = Exclude<UserTheme, 'system'>;

UserTheme is the user's explicit choice, while AppTheme is the resolved theme that the app actually uses for rendering.

Storage that doesn't break SSR

Let's persist the user's choice through localStorage.

Wait... but isn't it a client only API? Yes it is, the usual architectural choice is between localStorage and cookies. I'll get a bit more into detail at the end of the article if you're curious, but for now let's go with the localStorage approach.

Rule number 1 is: never touch window or localStorage when running on the server. There's another interesting rule but I'll tell you later... ok no let me put it now, when doing the first render (on the server) you can't rely on js or you'll get hydration errors and weird flashes. We'll see that in practice in the theme switcher.

here's the approach through some utility methods: a safe getter that returns 'system' on the server and validates values on the client; and a setter that no‑ops on the server.

function getStoredUserTheme(): UserTheme {
  if (typeof window === 'undefined') return 'system';
  try {
    const stored = localStorage.getItem(themeStorageKey);
    return stored && themes.includes(stored as UserTheme) ? (stored as UserTheme) : 'system';
  } catch {
    return 'system';
  }
}

function setStoredTheme(theme: UserTheme): void {
  if (typeof window === 'undefined') return;
  try {
    localStorage.setItem(themeStorageKey, theme);
  } catch {}
}

Resolving the system theme

Browsers expose the OS preference via matchMedia('(prefers-color-scheme: dark)').

function getSystemTheme(): AppTheme {
  if (typeof window === 'undefined') return 'light';
  return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
}

With that alone if the user changes preference (for example in the OS settings) while your page is loaded, the app won't reflect that change until a full reload occurs. The cool thing is that you can subscribe to that.

function setupPreferredListener() {
  const mediaQuery = window.matchMedia('(prefers-color-scheme: dark)');
  const handler = () => handleThemeChange('system');
  mediaQuery.addEventListener('change', handler);
  return () => mediaQuery.removeEventListener('change', handler);
}

Why is this function returning a cleanup function? No mistery, we're going to use it inside a useEffect, it's the cleanup function for the event listener to avoid memory leaks.

Applying the theme to the DOM

The DOM definition of the theme is on a class in the <html> element, either light, dark. If it's system, we'll also set that in the <html> element.

function handleThemeChange(userTheme: UserTheme) {
  const root = document.documentElement;
  root.classList.remove('light', 'dark', 'system');
  const newTheme = userTheme === 'system' ? getSystemTheme() : userTheme;
  root.classList.add(newTheme);

  if (userTheme === 'system') {
    root.classList.add('system');
  }
}

The ThemeProvider

Probably the most common usecase for React Context, the ThemeProvider component makes it easy to access and update the theme throughout your application.

On mount, set the initial theme from storage and wire the system listener only if userTheme === 'system'.

When setting a new theme: update state, persist to storage, and re‑apply classes to <html>.

The implementation might be something like:

type ThemeContextProps = {
  userTheme: UserTheme;
  appTheme: AppTheme;
  setTheme: (theme: UserTheme) => void;
};
const ThemeContext = createContext<ThemeContextProps | undefined>(undefined);

type ThemeProviderProps = {
  children: ReactNode;
};
export function ThemeProvider({ children }: ThemeProviderProps) {
  const [userTheme, setUserTheme] = useState<UserTheme>(getStoredUserTheme);

  useEffect(() => {
    if (userTheme !== 'system') return;
    return setupPreferredListener();
  }, [userTheme]);

  const appTheme = userTheme === 'system' ? getSystemTheme() : userTheme;

  const setTheme = (newUserTheme: UserTheme) => {
    setUserTheme(newUserTheme);
    setStoredTheme(newUserTheme);
    handleThemeChange(newUserTheme);
  };

  return (
    <ThemeContext value={{ userTheme, appTheme, setTheme }}>
      <ScriptOnce children={themeScript} />

      {children}
    </ThemeContext>
  );
}

export const useTheme = () => {
  const context = use(ThemeContext);
  if (!context) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
};

The crucial inline script: no FOUC

If you're already into the cookie vs localStorage debate, you know that in order to make this work you need to inject a tiny inline script that runs immediately, before hydration, to set the correct class on the root element. If you also have a sharp eye you noticed that <ScriptOnce children={themeScript} /> in the previous snippet.

The easiest way in TanStack Start to inject this inline script is to use the ScriptOnce component, which allows you to run a script only once during the initial render.

One tiny annoyance with inline scripts is that you write them as plain strings... so here's a magic trick to write it as a proper js function, enjoying linters and all kind of IDE support, then putting it the toString version inside an IIFE

const themeScript: string = (function () {
  function themeFn() {
    try {
      const storedTheme = localStorage.getItem('ui-theme') || 'system';
      const validTheme = ['light', 'dark', 'system'].includes(storedTheme) ? storedTheme : 'system';

      if (validTheme === 'system') {
        const systemTheme = window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
        document.documentElement.classList.add(systemTheme, 'system');
      } else {
        document.documentElement.classList.add(validTheme);
      }
    } catch (e) {
      const systemTheme = window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
      document.documentElement.classList.add(systemTheme, 'system');
    }
  }
  return `(${themeFn.toString()})();`;
})();

With this tiny bit of logic, that is converted to a string, you make sure as soon as possible to add the correct css class.

What happens without this? You'll get a flash: the page loads in the default style, then flips after React mounts. The inline script prevents that by writing the class during the initial HTML paint.

For clarity, here's the "too late" version using only useEffect so you can compare the behavior:

useEffect(() => {
  handleThemeChange(userTheme);
}, []);

You do this anywhere in your app? You get a FOUC. That's why we did the inline script magic.

Let CSS, not JS, drive the toggle UI

Here's the rule number 2 I mentioned earlier.

Because initial values settle before React, UI that depends on JS state will likely flicker as the server renders something (e.g. the icon for the light theme) but then on the client it gets overridden by the actual state and replaced with the dark theme... because you're using the dark theme, right?

The safest approach is to let CSS decide visibility based on the root classes. With Tailwind v4 you can use :not() and class selectors to keep it simple.

Here's an example:

const themeConfig: Record<UserTheme, { icon: string; label: string }> = {
  light: { icon: '☀️', label: 'Light' },
  dark: { icon: '🌙', label: 'Dark' },
  system: { icon: '💻', label: 'System' },
};

export const ThemeToggle = () => {
  const { userTheme, setTheme } = useTheme();

  const getNextTheme = () => {
    const themes = Object.keys(themeConfig) as UserTheme[];
    const currentIndex = themes.indexOf(userTheme);
    const nextIndex = (currentIndex + 1) % themes.length;
    return themes[nextIndex];
  };

  return (
    <Button onClick={() => setTheme(getNextTheme())} className="w-28">
      <span className="not-system:light:inline hidden">
        {themeConfig.light.label}
        <span className="ml-1">{themeConfig.light.icon}</span>
      </span>
      <span className="not-system:dark:inline hidden">
        {themeConfig.dark.label}
        <span className="ml-1">{themeConfig.dark.icon}</span>
      </span>
      <span className="system:inline hidden">
        {themeConfig.system.label}
        <span className="ml-1">{themeConfig.system.icon}</span>
      </span>
    </Button>
  );
};

You can userTheme the theme coming from the hook at any other time, for example to cycle between themes on user click, but on the initial render you can't. CSS will drive your button.

TanStack Start primitives: clientOnly and createIsomorphicFn

To avoid manual typeof window !== 'undefined' checks, you can use the Start utilities so you can define client‑only logic or dual client/server logic without sprinkling conditions everywhere.

clientOnly(fn): throws on server, runs on client
createIsomorphicFn({ server, client }): given the isomorphic nature of some functions, lets you define different behaviors on client and server

They're perfect for storage helpers and DOM‑touching functions, look at how expressive the code becomes:

const getStoredUserTheme = createIsomorphicFn()
  .server((): UserTheme => 'system')
  .client((): UserTheme => {
    try {
      const stored = localStorage.getItem(themeStorageKey);
      return stored && themes.includes(stored as UserTheme) ? (stored as UserTheme) : 'system';
    } catch {
      return 'system';
    }
  });

const setStoredTheme = clientOnly((theme: UserTheme) => {
  try {
    localStorage.setItem(themeStorageKey, theme);
  } catch {}
});

Validate with Zod

Instead of hand‑checking strings from storage, define a Zod enum with a catch('system'). Then call schema.parse(value) and you're guaranteed a valid UserTheme.

const UserThemeSchema = z.enum(['light', 'dark', 'system']).catch('system');
const AppThemeSchema = z.enum(['light', 'dark']).catch('light');

export type UserTheme = z.infer<typeof UserThemeSchema>;
export type AppTheme = z.infer<typeof AppThemeSchema>;

const getStoredUserTheme = createIsomorphicFn()
  .server((): UserTheme => 'system')
  .client((): UserTheme => {
    const stored = localStorage.getItem(themeStorageKey);
    return UserThemeSchema.parse(stored);
  });

const setStoredTheme = clientOnly((theme: UserTheme) => {
  const validatedTheme = UserThemeSchema.parse(theme);
  localStorage.setItem(themeStorageKey, validatedTheme);
});

Cookies vs LocalStorage (and when to use them)

To be honest I don't have clear evidence that one approach is absolutely superior than the other as they both come with their own trade-offs. In most cases it doesn't matter that much anyway, just pick the approach that seems more reasonable and you'll be fine.

The localStorage approach lives in the browser only which is good but requires js to run (on hydration) and you have to do those CSS tricks to control the initial render. Besides, the server has no knowledge of the user's preference.

The cookie approach makes the server aware of the theme, but it also means the browser has to deal with the server for each theme change that should just be a client function.

In any case, on the same repo you can find in the commit history a version with the cookie approach: https://github.com/Balastrong/start-theme-demo/tree/077010bee3ca25ba775a4d452d55244cf8971637

Wrap‑up

So here's the full flow:

Keep UserTheme ('light'|'dark'|'system') separate from AppTheme ('light'|'dark') and derive the latter.
Use safe storage helpers that default on the server and validate localStorage values on the client.
Write classes on document.documentElement (light/dark and optional system) whenever the theme changes.
Provide userTheme, appTheme, and setTheme via Context and listen to prefers-color-scheme when on system.
Inject a tiny inline script to set the initial html class before hydration to eliminate FOUC.
Let CSS driven by root classes control the toggle UI so it renders correctly on first paint.
Optionally use TanStack Start clientOnly/createIsomorphicFn and Zod enums to simplify and validate logic.

Before going, here some useful links:

Live Demo: https://tanstack-start-theme-demo.netlify.app/
GitHub Repository: https://github.com/Balastrong/start-theme-demo
Walkthrough Video: https://youtu.be/NoxvbjkyLAg

Now some homework for you, feel free to leave a star to the repo and like the video and... enjoy!

Also any comment or feedback, please, let me know!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

I vibe coded an online visitors counter for my blog

Leonardo Montini — Wed, 16 Jul 2025 09:56:21 +0000

You know that old-style "X users online" counter on a website? I've recently seen it on roe.dev's blog and I though: it shouldn't be too difficult for a naive implementation, let's vibe code it!

The stack: my blog is a static site built with Astro and hosted on Netlify, so I needed a way to track active visitors without a full backend. The goal was to create a simple counter that shows how many people are currently browsing the site, updating in real-time, without any annoying flickering.

Netlify Server Functions

The main engine for this whole thing is Netlify's server functions. After all, I just needed a simple endpoint to ping when a visitor comes in, which also returns the current count of active users.

I asked Copilot to write the logic in javascript and with a couple of iteration I already had a working demo on my local machine.

Bonus points: since it recognized I was in a Netlify project, it automatically added the function to the right folder and set up the correct export.

Storage on Redis

Ok this might have been overkill, but I wanted a quick solution to store the data since the netlify function runs in a serverless environment, meaning it doesn't have persistent storage.

I just googled "free redis hosting" and found Upstash, created an account and already had a Redis instance.

Time to write a quick prompt for Copilot to use Redis as storage. Since I mentioned I wanted to track not who's exactly online but how many users visited in the past 30 minutes, it suggested a TTL (time to live) of 30 minutes for each key. Cool, I don't even need to worry about cleaning up old data.

await redis.set(`online:${anonymizedIp}`, '1', { ex: 60 * 30 });

As easy as that, there's the ex option that sets the expiration time in seconds.

Reading values is also simple, just count the keys with a pattern like online:*:

const keys = await redis.keys('online:*');
const count = keys.length;

Avoid flickering

Once the backend was working, the next step was getting that counter to show up nicely on my static site without any annoying flickering.

The problem is that since the page is static, the "dynamic" part (the counter) needs to be fetched after the page loads. If I just rendered the counter with the initial value, it would show zero until the fetch completed, which is not ideal. Oh, and this on each page load or navigation!

So here's the plan, use 1 as default value to immediately show something, then fetch the actual count in the background and update it once we have the real number.

With that alone I had the jump from 1 to the real number at each navigation though, so the first naive solution that came to my mind was to store the value in local storage and read it on each page load. This way, the counter would show the last known value immediately, and then update in the background.

Local debugging

Just type netlify dev and you can run your Netlify functions locally, as easy as that, really!

So what?

I'm sure there's a million better ways to build this tiny feature, but it's been fun to use AI to quickly build something that kinda works.

Ah by the way, this wasn't a sponsored post (I wish it was!) but I think finding the right tools and services is relevant these days, in particular now that writing code goes much faster with AI.

If you want to see the live result just head over https://leonardomontini.dev/ or have a look at the video where I walk through the whole process and code:

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

Modernizing a large multi-team application with Micro Frontends

Leonardo Montini — Fri, 27 Jun 2025 13:32:49 +0000

Here’s a quite common scenario: you have a web application, built years ago, with deeply intertwined modules and dependencies. To make things worse, there are layers of legacy code built on top of each other, and multiple teams are dealing with the same codebase daily.

Each team struggles to implement new features without stepping on each other’s toes, app-wide updates are a long and dangerous process and updating only a portion is just adding one more layer of tech debt and inconsistencies.

The result? Slower development cycles, frustrated developers, and a product that struggles to keep up with user expectations and the market in general.

One of our clients has been in a similar situation, here’s how we’re taking care of that with Micro Frontends.

Modernizing with Micro Frontends

The main React application has almost 10 years and is bundled with an old version of Webpack while the new micro frontends are React apps running on Vite.

The approach is to gradually extract smaller applications from the old system, using the long-time domain and project knowledge to properly know where to set the boundaries.

Each smaller project has a unique goal in the system and is assigned to a dedicated and autonomous team. This brings a lot of advantages as each team can independently develop, deploy, and maintain their own portion of the system.

Communication between the systems is mostly through custom events.

With that in place, micro frontends enable incremental upgrades, allowing the legacy codebase to coexist with the new technologies. The teams can replace old modules one by one rather than rewriting the entire application all at once.

Downsides you better not ignore

Before going all-in into your next huge refactor to adopt micro frontends, there are some downsides you must understand.

To begin with, to reduce complexity of your old legacy system you’re going to adopt an architecture that for sure fixes some of the flaws but also brings some more complexity in other areas of your application. To name a few, passing data between components of a single app might be trivial nowadays but sharing the state and communicating between micro frontends might not be that obvious. There’s plenty of solutions, but the team must get used to them.

Separating all the moving parts might seem a simplification but now you must handle each one of them independently, including deployment and versioning. It’s an aspect you might see as a benefit, but it undeniably adds complexity.

Consistency can also be a challenge if not handled properly, as autonomous teams can easily drift and lose sight of the bigger picture. A common outcome can be large differences in UI components giving an unpolished look at the final product.

DOs and DON’Ts

A few tips to guide your implementation to maximise the benefits and avoiding some common mistakes. Some of these are common sense, some we banged our heads on during the project.

DOs

1. Do define clear boundaries for each micro frontend
We all should have learned the lesson from microservices, using the wrong criteria to break down the monolith and set boundaries will inevitably do more harm than good. Make sure each micro frontend represents a distinct feature or domain.

2. Do ensure independent deployment
Micro frontends should be deployable independently. If you end up in the situation where you consistently can no longer deploy one sub-system by itself, you’re coupling too much and losing the benefits of having separate frontends.

3. Do use shared libraries
Leverage shared libraries for common functionality like design systems, authentication, or API clients to reduce duplication of logic and inconsistencies. Module federation easily allows setting up shared libraries, use it.
This should also help in making sure the user experience remains consistent through a centralized design system.

4. Do start small
Begin with a single feature or module to test the waters. Gradually expand the micro frontend architecture as you gain confidence and refine your processes.
If you’re transitioning from an old and large system this is even more relevant to avoid unexpected issues.

DON'Ts

1. Don’t overcomplicate your architecture
Once you unlock the power of splitting into separate apps you might enjoy it too much. You can’t look at micro frontends as if they were simple folders in your monolithic app. Splitting and organizing components into separate folders is as easy as (auto) updating the imports, doing the same over many micro frontends can be way more painful.
Avoid immediately splitting your application into too many micro frontends without a strong rationale.

2. Don’t ignore cross-team collaboration
While micro frontends promote autonomy, teams must still collaborate to ensure consistency and avoid duplication. Regular communication and alignment are essential. Some code and logic will be duplicated, that’s fine, just make sure it’s intentional and under control.

3. Don’t use different frameworks for the sake of it
Although micro frontends allow flexibility in technology choices, using entirely different frameworks (React for a module and Angular for another) can complicate integration and increase onboarding time for new developers.
Just because you can doesn’t mean you should.

4. Don’t forget testing
Each micro frontend must be thoroughly tested both independently and as part of the larger application. Skipping integration tests can result in unexpected issues when modules interact with each other.

5. Don’t forget about versioning
Proper version control is critical for shared libraries and APIs used across micro frontends. Ensure backward compatibility to avoid breaking changes that disrupt other modules. If you end up having breaking changes all the time, maybe moving over to micro frontend wasn’t the right choice (or you’re doing it wrong!)

6. Don’t skip documentation
Document the architecture, module boundaries, communication protocols, and deployment processes thoroughly. This ensures smooth onboarding for new developers and reduces confusion over time.

Conclusions

Micro frontends are indeed an interesting and valuable architecture bringing several benefits, as in our case it allowed us to gradually upgrade the system without the risks of a full rewrite by keeping the teams almost independent from each other.

However, it’s worth mentioning that it’s not always the best solution and it should be considered only if some conditions are met (application size, team(s) size, technical complexity, etc...). Smaller applications or teams may not benefit from the added overhead of managing multiple micro frontends, and simpler architectures might suffice for less complex systems.

This architecture doesn’t magically get rid of complexity, but it shifts it to other places trying to make it more manageable. If you and your team are not ready to manage that new kind of complexity, think again if this is really what you’re looking for.

As always, bad adoption of good practices can do more harm than good, do your research thoroughly and if you think you’ve got what it takes, then go for it and enjoy the flexibility of micro frontends!

How we'll measure performance of our DevRel activities

Leonardo Montini — Mon, 23 Jun 2025 14:31:13 +0000

▶️ This article is extracted from a video transcript, slightly tweaked for better readability. Watch the original: https://youtu.be/OabGHQ133zg

Welcome to the second update of me trying to launch a DevRel program in the company I work for. Today’s topic is going to be: metrics.

So here’s the idea. Overall, right now we’re trying to launch the program. We're doing some activities, creating content, and pretty much everything we can to start and get the wheel spinning. But on a parallel track, something else we already had to take care of is trying to answer a really simple question: okay, cool, but is this thing actually working? How can we tell if the activities or the time spent doing those are actually worth the effort?

I think today’s update is going to be around the difference between output and outcome. They might seem similar, but they’re actually two very different things.

Let’s begin with output. Output is kind of easy to measure. You can say, "Yeah, during these first six months we’ve written 10 articles, we created that amount of LinkedIn posts, we had so many views, so many interactions." So you already have kind of a number you can put in an Excel sheet and compare. But is it actually relevant? That’s another interesting question.

How much time are we spending creating the articles? Is that a measure to know the success of the project? Well, actually, no, it’s not. It is indeed something interesting to measure and keep track of, but the goal is not to focus on the output, as I said, but on the outcome.

The idea is: okay, we wrote 10 articles, cool. What impact did those articles generate? That’s what matters. The most interesting metric we agreed on with management is lead generation. So it’s not how much time we spent or how much effort we put into creating the articles, but how many leads did the article generate? That’s a really relevant metric that measures if the project is actually working.

However, this doesn’t mean at all that the output isn’t relevant. We still want to keep track of the effort, how much time we put into creating the content, and the output: how much content we can actually generate, how many articles. I keep saying articles, but it may be webinars, it may be talks we deliver at conferences, everything has to be measured and tracked. But that’s not how we measure the success of the project. The project is measured through the outcome.

And even if we agree that outcome is what we want to measure to keep track of success, where should we put our thresholds? Like I said, lead generation, okay, awesome. How many leads do we want to take in order to consider the project successful? One? Five? Ten? And only leads? Do we want to keep track of actual customers? How many conversions do we have? Do we want 10%? 50%? 90%?

That’s also another challenge that we’re facing right now, at least in this early phase, as we hardly have any other numbers or references to use. In our case, at least for our company, it’s the first time we’re trying to do something like this. So it’s even difficult to say, "We want three leads in the next two months." What does even three mean? Or five? Or ten or twenty?

That’s also another really interesting topic we’re just exploring. As time goes by, we might want to set some thresholds and see, in six months, how far are we from the threshold? Did we do twice that number? Did we do half that number? And even at that point, we should be smart enough to say, "Okay, we did twice our goal, was it because we were so good and we did a lot of generation? Or did we do twice our goal because we were just kind of naive and picked the wrong number, a goal that was just too easy to reach?"

Or, if we under-delivered, did we under-deliver because we didn’t create enough content? Because our content wasn’t good enough? Because it just didn’t work? Or simply because we were way too optimistic in the beginning and picked a number that was impossible to reach, and even if we did our best, we just didn’t get there?

It’s going to be fun to do this kind of analysis in the next few months, and that’s obviously another topic I want to bring here to the channel. Maybe at the beginning of next year I’m going to say, "Hey, we had this metric, this is what we reached, and this is our analysis after all the work was done."

Wrapping up:

Keep track of the effort, to know how much time you’re spending doing the activity.
Keep track of the output, to measure your firepower, how many things you can actually do and deliver.
Keep track of the outcome, the results you can achieve. That is the category of metrics that will, in fact, measure the success of your program.

That’s pretty much how we think right now. I hope it’s the right direction. In any case, if you have any kind of advice about measuring developer relations activities, please let me know in the comments. As always, I’m happy to have a chat.

That’s it. That was the end of today’s video. Thanks for watching, wish me luck again, and see you in the next update. See you!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

TanStack Router: How to protect routes with an authentication guard

Leonardo Montini — Sun, 22 Jun 2025 14:49:00 +0000

Some routes in your application require authentication or other conditions to be met before users can access them. TanStack Router provides a powerful guard mechanism to handle these scenarios through the beforeLoad function, which allows you to intercept route navigation and enforce access control rules before any components are rendered.

Protecting a route

When you define a route with createFileRoute you have can specify a function in the beforeLoad property. This function will be called before the route is loaded, allowing you to perform checks and potentially redirect the user if they don't meet the required conditions.

An example:

import { redirect, createFileRoute } from '@tanstack/react-router';
import { isAuthenticated } from '../utils/auth';

export const Route = createFileRoute('/profile')({
  component: RouteComponent,
  beforeLoad: () => {
    if (!isAuthenticated()) {
      throw redirect({ to: '/' });
    }
  },
});

With this setup, the page will not be loaded at all if the user is not authenticated (e.g. the component will not be rendered). Instead, the user will be redirected to the home page.

Protecting multiple routes

With the previous example you're already protecting the /profile route, and potentialy every other child route as each beforeLoad function is called when traversing the route tree.

However, in some cases you might not have a single route (and its children) to protect, but a series of sibling routes. While you can indeed replicate the same logic in each route's beforeLoad, there are better ways to handle this.

An approach is to follow the same pattern you would do to create shared layouts and add the guard logic in there. For example, your route tree could look like this:

src/
├── routes/
│   ├── __root.tsx
│   ├── index.tsx
│   ├── login.tsx
│   └── (authenticated)/
│       ├── route.tsx
│       ├── profile.tsx
│       ├── settings.tsx
│       └── dashboard.tsx

Inside the (authenticated) folder you can find three "regular" routes, but also a route.tsx file, a special name that will not define a specific route but will be used as common layout for all the routes inside the folder. This is where you can add the guard logic:

import { createFileRoute, redirect } from '@tanstack/react-router';
export const Route = createFileRoute('/_authenticated')({
  beforeLoad: () => {
    if (!isAuthenticated()) {
      throw redirect({ to: '/' });
    }
  },
});

Shared layouts - optional

Notice how this route doesn't have a component property. This is optional as we're using the route only to group the authentication logic (so we don't need it on each sibling route) and not to render a specific component.

Once you have this setup though, this would be the first step to have a common layout (not part of this article) but all you really need is to define a component and make sure to add the <Outlet /> component inside it (imported from ), so the child routes can be rendered.

  component: () => (
    <>
      This text will show on all sibling and child routes
      <Outlet />
    </>
  ),

Pathless route (folder)

Also notice how the authenticated routes are grouped in a folder named (authenticated) with its name enclosed in parentheses. This is a convention in TanStack Router to indicate that this folder will not appear in the URL, this is optional but often used so you can have your-site-com/profile instead of your-site-com/authenticated/profile.

More on guards and authentication

This was just a short extract with the core concepts, you can find an extensive and step by step guide on the following video.

The video includes how to integrate with a real authentication service and how to use hooks through Router's context to access the authentication state in your routes and components.

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!

I'm starting a Developer Relations program, somehow 🤷

Leonardo Montini — Tue, 17 Jun 2025 12:49:06 +0000

▶️ Video version on YouTube: https://youtu.be/ERWzk5iOAiU

Hey everybody, look at that! I finally had a chance of using the LinkedIn template with the airplanes, and that's the announcement number one.

But actually, the announcement number two is that I just added DevRel to my job title. So here's a story.

If you follow me, you know that I kind of have a passion for sharing content and sharing knowledge. The idea was to match this passion to the other passion that I have, that is: getting a salary from a company I work for. How can I make these two different worlds live next to each other, or at least have some kind of intersection between my work as a front-end developer and the passion of sharing content?

That's pretty much trying to launch a developer relations program right here at the company I'm currently working for.

But here's the fun part: I have no idea how to actually run a proper developer relations program, as sharing videos on my personal channel on YouTube is kind of a different story. And it's also the first time for my company to have an official DevRel program. It's going to be fun.

You may ask, why am I even sharing this here on my personal channels? Someone else might be in a similar position, working in a company that might benefit from a DevRel program, but they don't know how to start. And I also don't know how to start. That's awesome!

The idea is to share here the experiments we try, the lessons we learn every time we fail at something, and every time we succeed at something.

So if you're interested, if you're curious and want to follow my DevRel journey, I got this idea of sharing even more videos about that in the near future.

This doesn't mean that I'm going to quit talking about JavaScript. That's still what pays most of my salary, and I will still be a developer for quite some time. But there it is, one more interest that I have, one more challenge that I'm going to face, and one more topic that I can bring here.

My primary goal, or my personal and romantic way of seeing this kind of new experiment, is to try to contaminate my colleagues and get most of them into this passion for sharing knowledge.

So how can we, the employees and the company, find a match and kind of win together? The idea is that everyone who's passionate about something can have the chance of sharing knowledge about that specific topic, and in return, the company gets some more visibility and can demonstrate the expertise.

If in the company we have some employees that are super skilled and super specialized in some specific technologies, or on how to solve specific problems, it also kind of benefits the company in proving that they have that kind of expertise.

Because here's one more fun, tiny challenge in my journey: my current company, Claranet Italy, is not a product company. We're a consultancy company. We sell our expertise in solving our customers' needs.

But I still want to believe that everyone, the company and the employees, can benefit from kind of a DevRel program.

All of that just to say that if you're curious, stay tuned, wish me luck, and hopefully see you soon in the next update about this new developer relations journey.

Thanks for reading, and see you soon. Bye!

Thanks for reading this article, I hope you found it interesting!

Let's connect more: https://leonardomontini.dev/newsletter

Do you like my content? You might consider subscribing to my YouTube channel! It means a lot to me ❤️
You can find it here:

Feel free to follow me to get notified when new articles are out ;)

Leonardo MontiniFollow

Awarded GitHub Star since 2023 ⭐️ and Microsoft MVP since 2024 🔷 I talk about Open Source, GitHub, and Web Development. I also run a YouTube channel called DevLeonardo, see you there!