
I am a massive fan of [React Query](https://tanstack.com/query/v4). It has grown on me to the point that it's now one of the first tools I set up when I start on a new project. If you're not familiar with React Query, at a high level it's a library that helps you manage your data fetching and client-side caching in React applications.

React Query makes it easy to write declarative data fetching code that gets access to all sorts of nice features like request states (`isLoading`, `isFetched`, etc), query deduping, query cancellation, cache control and persistence, and a [whole lot more](https://tanstack.com/query/v4/docs/comparison) &mdash; and it gives you the power to manipulate your client-side cache in pretty much any way you might need.

If you just need to fetch some data you can use [`useQuery`](https://tanstack.com/query/v4/docs/reference/useQuery) with one or two lines of code and be on your way, but as your application grows in complexity you may find yourself wanting to connect to a websocket to receive real-time updates from your server. Fortunately, React Query makes this quite painless.

## Querying data

When you're ready to start updating your client via websockets, if you're already using React Query, the good news is that nothing really changes with the way you fetch your data.

```js
const { data } = useQuery({
  queryKey: ['replies', postId],
  queryFn: () => fetchReplies(postId),
});
```

Here we've got a `fetchReplies` function that returns a promise that resolves to an array of replies for a given post. We're using the `queryKey` to identify this query, and we're using the `queryFn` to call our `fetchReplies` function.

## Subscribing to a websocket

In this example, we're going to use [Pusher](https://pusher.com). I like Pusher because they have an [open specification](https://pusher.com/docs/channels/library_auth_reference/server-library-reference-specification/) and there are other, self-hostable [alternatives](https://soketi.app/) that implement the Pusher spec. Meaning you can build on Pusher and if your application scales to the _incredibly expensive_ tiers of Pusher.com, you don't have to rewrite your entire socket architecture to cut some costs. You can just host your own server.

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (event) => {
    /* ... */
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

## Interacting with the cache

There are two ways that I typically approach passing a socket message along to React Query. Each are useful in different contexts, so we'll cover both and when you might want to use one over the other.

The first is to invalidate the query by `queryKey`, so that the next time that query is needed it'll fetch fresh data from the server. This approach minimizes the amount of data over the wire via the websocket and allows users to only fetch the data that they need, when they need it.

The second approach is to send the updated data through the websocket and then manually update the `queryClient` cache with that new data. This approach is better if you expect to have a frequent, small updates or if you expect a large number of concurrent consumers &mdash; and want to avoid triggering a thundering herd every time new data is available.

### Invalidate Query

When a socket event occurs, we'll use [`queryClient.invalidateQueries`](https://tanstack.com/query/v4/docs/reference/QueryClient#queryclientinvalidatequeries). The nice thing about React Query here is that if the query is actively being used, it'll refetch that data in the background and show the stale data in the UI until the new data is available. If that query is _not_ actively being used, React Query marks it as invalidated and fetches it the next time the user needs it. 

Using the same example from above, we'll fill out the `newReply` event handler.

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (postId) => {
    queryClient.invalidateQueries({
      queryKey: ['replies', postId]
    })
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

Now on the server, you can send a message to the `post-replies` channel with the `postId` as the event data:

```js
pusher.trigger('postEvents', 'newReply', postId);
```

### Manually update the cache

If you expect to have frequent, small updates &mdash; like a chat feature &mdash; or a large number of concurrent users it is probably better to ship the updated data over the websocket and update the cache by `queryKey` directly using [`queryClient.setQueryData`](https://tanstack.com/query/v4/docs/reference/QueryClient#queryclientsetquerydata).

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (reply) => {
    queryClient.setQueryData(
      ['replies', reply.postId],
      (cacheData) => [...cacheData, reply]
    );
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

In this case, we're still updating the same record by `queryKey` but instead of telling React Query to fetch the data next time it needs it, we just take the cached value as a parameter in our update function and append our new comment entry to the array.

And on the server side, rather than just sending the `postId` we'll send the entire `reply` object.

```js
pusher.trigger('postEvents', 'newReply', reply);
```



Using Websockets with React Query


I honestly can't tell if the Twitter acquisition is going off the rails or according to plan.

I'm not sure what will happen to Twitter over the coming weeks and months, but it seems inevitable that the outcome will at minimum be fragmentation of the various communities that I've followed and engaged with over the years.

If you're part of the contingent that's bailing on Twitter, I'm [@jonbellah@mastodon.social](https://mastodon.social/@jonbellah).

Bye bye, Birdie


After almost a decade working as an individual contributor — with a few short stints in engineering leadership-adjacent roles — I've decided to finally make the
jump to engineering management.

Today is my first day as an Engineering Manager at [Endeavor](https://www.endeavorco.com/story/).

Beyond learning an entirely new skillset, I'm particularly excited about this new role for a few key reasons.

First, Endeavor is just an incredibly interesting and exciting company to go to work for. They've got their hands in a broad swath of the sports and entertainment
industries, from being one of the largest [talent agencies](https://www.wmeagency.com/expertise/) and [sports and event management](https://img.com/expertise/)
companies in the world to being the parent company of the [UFC](https://ufc.com) and [PBR](https://pbr.com/) &mdash; and so, so much more.

Secondly, I'll be working with _several_ friends from my time at TED. The TED Tech team was one of the smartest and most close-knit groups that I've ever worked
with and getting a chance to go work with a bunch of them again is super exciting.

And lastly, I'll be leading a team at an internal incubator charged with innovating and building the next generation of Endeavor's business. The William
Morris Agency &mdash; the precursor to today's Endeavor &mdash; was formed almost 124 years ago&hellip; and a company doesn't survive for 124 years by remaining
stagnant. Endeavor has innovated and grown their business decade-after-decade and I'm looking forward to playing a (small) part in writing the next chapter of
that story.

I'll likely be hiring for my team very soon, so if you're interested in working with me, don't hesitate to [reach out](https://jonbellah.com/contact)!

Making the Jump to Engineering Management


In my [last post](https://jonbellah.com/articles/renewed-focus), I talked a bit about migrating this blog over from Gatsby to Next.js. One thing I had to
sort out in that migration was moving from the relatively-straightforward implementation of `gatsby-plugin-feed` to building a custom-rolled RSS feed.

It actually turned out to be a relatively painless process, so I thought I'd share how it works.

## A Bit of Background

First, it's probably helpful to cover how I've got things set up. I write everything in markdown (mdx) and have it sitting in a `content` directory,
alongside the `src` and `public` directories in my codebase.

Here's roughly the file structure we'll be working with in this tutorial:

```
blog/
├─ src/
│  ├─ pages/
│  │  ├─ api/
│  │  │  ├─ rss/
│  │  │  │  ├─ index.ts
│  │  │  │  └─ feed.json
├─ scripts/
│  └─ rss.mjs
├─ content/
│  └─ blog-post.mdx
└─ package.json

```

The way that this will end up working is that we will use a `prebuild` hook in our `package.json` to run a node script that will grab all of our posts
and format them into a `feed.json` file. From there we'll create an API route that will use that json file to serve up our RSS feed. Lastly, we'll use our
`next.config.js` file to add a rewrite, so that we can serve the RSS feed from `/rss.xml`.

## The Node Script

This node script will be run on a `prebuild` hook. When we build our site to deploy, the script will run through the `content/` directory, grab all of our posts
loop through them and format them into a `feed.json` file that we can deploy alongside our API endpoint.

The primary reason for generating this JSON file is so that we don't have to do a bunch of file system reads when someone requests the RSS feed.

Here's the script in full:

```js
// scripts/rss.mjs
import fs from 'fs';
import matter from 'gray-matter';
import path from 'path';

const generateRss = async () => {
  const POSTS_DIR = path.join(process.cwd(), 'content');
  const posts = fs
    .readdirSync(POSTS_DIR)
    .filter((filePath) => filePath !== '.DS_Store') // only needed for macOS
    .map((filePath) => {
      const source = fs.readFileSync(path.join(POSTS_DIR, filePath));
      const { content, data } = matter(source);

      return {
        content,
        data,
        filePath,
      };
    })
    .sort(
      (a, b) =>
        new Date(b.data.date).getTime() - new Date(a.data.date).getTime(),
    );

  // Create sitemap file
  fs.writeFileSync('src/pages/api/rss/feed.json', JSON.stringify(posts));
};

generateRss();
```

The way this works is that we're calling `readdirSync` on the directory that contains all of our mdx files to get an array of file names,
then filtering out the `.DS_Store` file (only necessary for macOS), and then mapping over that list of files.

When we map over the array of file names, we then call `readFileSync` to read the individual file and use the `gray-matter` package to extract the
frontmatter into an object, and return all of that data to make our `posts` variable an array of objects that contain all of our posts and their frontmatter.

Finally, we sort the posts by publish date and then call `fs.writeFileSync` to write a `feed.json` file into the `pages/api/rss` directory; where it'll sit next
to the API endpoint handler.

## The Prebuild Hook

Not much to this one. When you run `npm run build`, the `prebuild` hook will run before the build process begins. We'll use this hook to run the node script we just built.

```json
{
  "scripts": {
    "generate:rss": "node scripts/rss.mjs",
    "prebuild": "npm run generate:rss"
  }
}
```

## The API Route

This is the meat and potatoes of serving up the RSS feed. We're using a custom [API route](https://nextjs.org/docs/api-routes/) to run a lambda function that
loads up the JSON file that we generated in the previous step, formats it into an XML document, and returns it back to the requester.

```js
// src/pages/api/rss/index.ts
import { NextApiRequest, NextApiResponse } from 'next';
import nc from 'next-connect';

import { BlogPost } from 'lib/types';

import feed from './feed.json';

const metadata = {
  title: 'JonBellah.com',
  description: 'About my site!',
  link: 'https://jonbellah.com'
}

const handler = nc();

/**
 * Respond with an rss.xml
 *
 * @param {object} req NextApiRequest
 * @param {object} res NextApiResponse
 */
handler.get(async (req: NextApiRequest, res: NextApiResponse) => {
  try {
    const postItems = feed
      .map((page: BlogPost) => {
        const url = `${
          process.env.NEXT_PUBLIC_ROOT_URL
        }/articles/${page.filePath.replace('.mdx', '')}`;

        return `<item>
          <title>${page.data.title}</title>
          <link>${url}</link>
          <guid>${url}</guid>
          <pubDate>${page.data.date}</pubDate>
          ${
            page.data.excerpt &&
            `<description>${page.data.excerpt}</description>`
          }
          ${/**
           * NOTE: page.content on the next line should be wrapped with
           * the CDATA tag, but it breaks my _actual_ RSS feed if I
           * include it. Check the link to the source at the bottom
           * of this post for the actual code.
           */}
          <content:encoded>${page.content}</content:encoded>
        </item>`;
      })
      .join('');

    // Add urlSet to entire sitemap string
    const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
    <rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
      <channel>
      <title>${metadata.title}</title>
      <description>${metadata.description}</description>
      <link>${metadata.link}</link>
      <lastBuildDate>${feed[0].data.date}</lastBuildDate>
      ${postItems}
      </channel>
      </rss>`;

    // set response content header to xml
    res.setHeader('Content-Type', 'text/xml');

    return res.status(200).send(sitemap);
  } catch (e: unknown) {
    if (!(e instanceof Error)) {
      throw e;
    }

    return res.status(500).json({ error: e.message || '' });
  }
});

export default handler;
```

It's worth noting, too, that if you're using a CMS that has a REST API &mdash; like [WordPress](https://wordpress.org/) &mdash; you can fetch the list of posts in this
lambda function and build your RSS feed on-the-fly. If your content _is_ stored in an external CMS, you can skip the `prebuild` script and just use the API route.

Another thing worth noting is that the `url` variable within the `postItems` map assumes that the path for posts will be `articles/{post-slug}`. Be sure to change that to
whatever path you prefer for your own site.

## Configure the Next Rewrite

The final step to get this up and running is to use our `next.config.js` file to add a rewrite, so that we can serve the RSS feed from `/rss.xml` instead of `/api/rss`.

Feel free to make the `source` route whatever you prefer, especially if you're trying to preserve the route to an existing RSS feed.

```js
// next.config.js
module.exports = {
  rewrites: async () => [
    {
      source: '/rss.xml',
      destination: '/api/rss',
    },
  ],
};
```

Now once you deploy your site to Vercel, you can visit `yoursite.com/rss.xml` and see your RSS feed!

## Source

You can find the source code for this tutorial [here](https://github.com/jonbellah/tutorials/tree/main/apps/nextjs-rss-feed).


Adding an RSS Feed to a Next.js Blog


Last year, I announced the launch of a project called JSFoundry. At the time, my objective was to build a place to put all of my tutorials,
courses, and other teaching-related materials with a goal of separating those materials out into their own "brand", so that (eventually)
I could tap into other educators and begin building up a community.

Today, I'm announcing that I'm shutting it down.

## What happened?

Well... _:gestures_wildly:_ a lot of things. The pandemic might be one (small) factor, but it was certainly not the only one.

On top of a couple of job changes, being a dad, and working on a long-running freelance retainer; the simple truth is that pretty much as soon as I
launched the site I lost sight of the core objective. I was exhausted by trying to figure out "if I write this blog post, where should it go?" or "do I
want to spin up a separate YouTube channel for new tutorials?" and all of the other strategic questions that, honestly, I should've thought through before
building out the site.

I had analysis paralysis. For no real reason.

It was a good learning experience, but not exactly time well-spent.

As I continued to stew on the strategic questions, I realized that ultimately my goal is and always has been to build a SaaS business, not necessarily an
info product business. I have always wanted to build my own company &mdash; and eventually work for myself &mdash; and, at the end of the day, I feel that
building software is a better fit for what I envision that work to be. I love teaching, but I've always enjoyed the work of actually writing code more than
writing blog posts or recording and editing tutorials.

At the same time, though, I have always felt &mdash; and continue to feel &mdash; strongly about the value of teaching and developer education work. I honestly
believe it has the power to change peoples lives. Helping people along their journey, particularly towards their first developer jobs, is one of the most rewarding
feelings ever. So, it's something that I absolutely plan to continue doing... just without the pressure of trying to build up some brand or business.

## Well, what now?

First off, while this site may look the same as it has for a while, I've migrated it over from Gatsby to Next. I've moved all of my blog and course-related code
into a [Turborepo](https://turborepo.org/), where I can more easily manage everything.

I took a bit of time to tear apart my course platform and trim it down to only the absolute essentials, improved those features deemed essential, and relaunched
the LMS at its original location: [courses.jonbellah.com](https://courses.jonbellah.com).

The migration and cleanup process was actually quite fun: I migrated from Mongoose to Prisma, MongoDB to MySQL (hosted on [PlanetScale](https://planetscale.com/)),
from PassportJS to [next-auth](https://next-auth.js.org) with magic link sign-in, and from a custom Stripe Elements implementation to a very hands-off Stripe Checkout
process. I also finally moved all my remaining projects over to [Vercel](https://vercel.com/).

I also took a little bit of time to redesign and relaunch [LearnStateMachines.com](https://learnstatemachines.com) as its own standalone course site again. There's been
a lot of movement on the [XState V5](https://github.com/statelyai/xstate/pull/898) PR and I still intend to release a new version of the course when that lands. I'm quite
happy with how the design turned out and am looking forward to dusting off that course again soon.

In the end, the best part was being able to delete _so_. _much_. _code_.

Now things are much more clear and everything has its place. No more distractions. No more clutter.

## What's next?

Finally making the decision to throw away all that work actually feels pretty great. There was an immediate feeling of clarity, like a dam had been broken.

As for what's next, I'm going to continue putting work into the same projects that I have been... now just with more precise focus around the goals, objectives, and motivations.

[BugCatcher](https://bugcatcher.io) is still in its early days &mdash; having taken about a year of real time to do ~3 months of work, due to the aforementioned juggling
of a freelance project &mdash; but I'm very excited about the problem space and the people we're solving the problem for. We've got a lot of interesting work on the roadmap.

As for writing and teaching, I'm hesitant to promise that I'll be any better about publishing content more regularly. The truth is that I've always been terrible at building
a habit of writing or recording tutorials. I _will_ say that it's something I'm keen to improve on, though. One idea that I'm kicking around is to share some of the under-the-hood
work I'm doing on BugCatcher, either as pre-recorded videos or as a livestream. And, of course, releasing a new version of Learn State Machines once XState V5
lands.

Lastly, I've got some pretty exciting career-related news that I'll be talking about more soon!


Entrepreneur, software engineer, and amateur photographer.

Using Websockets with React Query

Bye bye, Birdie

Making the Jump to Engineering Management

Adding an RSS Feed to a Next.js Blog

A Renewed Sense of Focus

Stay up to date

From YouTube