ISR stands for Incremental Static Regeneration – a mouthful I know, but this is something that will take your [Next.js](https://nextjs.org/) apps to the next level.

When building a site where most (if not all) of your pages are being statically generated, you may run into long build times. This can suck if you need to make a small change but you have to wait that long period of time to rebuild the site in its entirety. This is where ISR comes into play!

When choosing to implement ISR, there are 2 main benefits that you need to choose from – this can impact your end-users experience. You want to decide whether you want ***faster builds*** or ***more caches***. Let's talk more about these two in-depth:

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FjoOEgL4DvxVyDppOnWAseb3LIMM2%2FB0E1ByROBwgO2aLCKWey%2F67959abd-a6e3-4e4e-ba30-bb9523c14264.png?alt=media&token=661ab675-254b-42be-b244-8eba797aed43","id":"67959abd-a6e3-4e4e-ba30-bb9523c14264","width":1392,"height":784,"filename":"isr-1.png","type":"image/png","caption":"Choose whether pages are generated when building or on-demand","border":false}]}
```

### **Faster Builds**

How can we achieve faster builds? The easiest way is to reduce the number of pages that have to be built! For our guestbook example *(I'll discuss this later)*, everyone that signs the guestbook has their own page `/guest/{username}`. If 10,000 people sign the guestbook, it could take some time to build all those pages. Instead, we can build a subset of those 10,000 pages to get faster build times. Let's say at build time, we'll only build pages for the 500 guests who sign the guestbook the most. This will **drastically** reduce the time it takes to build our site since we reduced the number of pages we're building.

### **Cache More**

We may decide we want more pages to be readily available and accessible to our users – that's when we'd choose this approach. This simply means that we increase the number of pages we generate at build-time. For instance, instead of generating the 500 guests who sign the guestbook the most, we can increase that to 1,000! This allows users to view more static content whilst keeping our overall build times relatively fast.

> You may want to do this if you have an e-commerce store where you want to show the most searched products quickly. By caching more products, your users get fast page loads for common and expected results ✨

You may be wondering *"what about the other 9,000+ pages?"* – this is a super valid question with a super valid answer 😅. This is where the power of ISR comes into play: the other 9,000+ pages can be generated on-demand by specifying a `fallback` option. This option enables different behaviors for those pages that haven't been generated yet.

* When set to `"blocking"`, the page will be [server-side rendered](https://www.educative.io/edpresso/what-is-server-side-rendering).
* When set to `true`, a loading state will be displayed until the page re-renders with the fetched data.

> It's important to note that regardless of what `fallback` option you choose, future requests to those pages will be served from the cache.

### **What does ISR look like?**

This is my favorite part, seeing it in action! I built a little something cool that should supplement what you just read – it's a guestbook\* that is statically generated and has dynamic routes for guests where you can see their last message. Check it out [here](https://isr-guestbook.vercel.app/) ✨

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FjoOEgL4DvxVyDppOnWAseb3LIMM2%2FB0E1ByROBwgO2aLCKWey%2F46b7b59a-f2c1-454c-81df-0bf1bedb6eed.png?alt=media&token=f8dd7f4a-a65b-443a-a11b-e0a888b98656","id":"46b7b59a-f2c1-454c-81df-0bf1bedb6eed","width":1386,"height":776,"filename":"SCR-20220127-plg.png","type":"image/png","caption":"How pages are generated and served with ISR","border":false}]}
```

I like this diagram because it showcases at what point ISR kicks in and saves the day – at the revalidation marker! What I want you to do is sign in, leave a message and let's talk about what you might experience. Initially, you might not notice anything but wait about 60 seconds...

> In the meantime, follow me on [Twitter](https://twitter.com/gt_codes) if you're not already 😅

Okay, we're back! Refresh the page and you should see your message at the top of the guestbook! Exciting, right? We updated a statically generated page without having to *rebuild the entire site* – this is major and all thanks to ISR! Wanna see it again? Try clicking on your message, it'll take you to **your** **unique page** where people can see the last message you left. You should see the message you just created. Leave another message, go back to your guest page, and wait a bit *(60 seconds at most)*. You'll see your **new message** on your guest page!

> It's important to note that this entire site is statically generated, yet we're able to deliver ***updated*** and ***dynamic*** content to our users ✨

## Wrap up

I won't go over everything you can utilize ISR with, I just wanted to show it off a bit because it truly is a game-changer! If you add ISR to your app, I'd love to know what you use it for; give me a shout on [Twitter](https://twitter.com/intent/tweet?text=@gt_codes)! Also, if you're interested in the code for the guestbook, you check it out [here](https://github.com/gt-codes/isr-guestbook).

---

\* guestbook: a way for a visitor to acknowledge they visited a site and leave details such as their name or comment.

---

❤️ Open Source Software

Ever tried ISR in Next.js?

[SWR](https://swr.vercel.app/) is a **fast**, **lightweight**, and **reusable** data fetching library from the good folks at [Vercel](https://vercel.com/) that I use in my [Next.js](https://nextjs.org/) apps! SWR stands for stale-while-revalidate; if you're not familiar with that concept, here's a bit of background:

> **A cached response is *stale* when it exceeds the `max_age` specified in its `Cache-Control`  header. When a request is made and the response is fresh (newer than the `max_age`), the cached data is returned. However, if the cached response is stale – a revalidation of the response occurs which then caches the new response for future use.**
>
> *[Web.dev Reference](https://web.dev/stale-while-revalidate/)*

### **Data Fetching**

In its simplest form, this is how you use SWR:

```typescript
const { data, error } = useSWR('/api/user', fetcher)
```

What I like about SWR is that data is tied to a key (usually an endpoint), so whenever you need that data, instead of hitting the endpoint again, you get the cached data from SWR. Oftentimes, I create a custom hook and call that hook in different places within my app so everything stays consistent.

> For instance, when I update my avatar on the profile page, it instantly gets updated in the sidebar because both components are pulling from the same resource!

Why is this a good thing? Take this screenshot of an example app below. There are 3 components (`<Sidebar />`, `<UpdateProfile />`, and `<Groups />`) that use the code snippet above to get the signed-in user's data. The beauty of this is that since the data is tied to a key, ***only one request*** will be sent! SWR dedupes\*, caches, and shares the data across all instances; in this case, all components receive the data from the response.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FjoOEgL4DvxVyDppOnWAseb3LIMM2%2FLQLce18jFiGffgZkvPJd%2F9a25a0c9-cb28-45dc-b589-096cfa5e3d68.png?alt=media&token=84af9fa0-60bb-4678-975a-8c698ec7eed6","id":"9a25a0c9-cb28-45dc-b589-096cfa5e3d68","width":5184,"height":3351,"filename":"swr-png.png","type":"image/png","caption":"","border":false}]}
```

### **Optimistic UI**

Let's keep the "*updating your profile"* scenario, it's relatable! Say you're updating your avatar and you press save and it immediately updates! You might say *wow, that was super fast!* More times than not, that's optimistic UI. What's happening behind the scenes is the new data is being sent to the UI immediately while the request happens in the background. If there's an error with the request, the new data is removed and the UI goes back to its original state. This makes your app feel smooth and snappy which greatly impacts your users' overall experience!

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FjoOEgL4DvxVyDppOnWAseb3LIMM2%2FLQLce18jFiGffgZkvPJd%2Fe64962af-88a3-4981-9073-6fe4e1b0f715.gif?alt=media&token=7742260a-941d-41b5-9d0d-f5fdadee1af7","id":"e64962af-88a3-4981-9073-6fe4e1b0f715","width":3228,"height":1932,"filename":"oui-gif.gif","type":"image/gif","caption":"Loading state (left) vs. Optimistic UI (right)","border":false}]}
```

> Notice how on the left, showing a loading state temporarily pauses the user from interacting with our app. This delay can get longer depending on the user's network connection. On the right, however, the user can get back to using our app immediately and if something goes wrong with the request, the data seamlessly rolls back to its original state ✨

You can achieve optimistic UI with SWR pretty easily. When mutating, three things happen:

* the query's cache is immediately updated with the new data

* a request to the server is fired in the background *(to perform the mutation)*

* the query is then revalidated

Remember how I told you that data is tied to a key? When a query's cache is modified, the data is broadcasted to all instances of that query so you don't have to revalidate each instance separately. This makes for *real-time updates* across your app, making the experience that much more delightful! I was chatting with [Shu Ding](https://twitter.com/shuding_), core maintainer of SWR, about some interesting behavior I encountered and it led to this ***recommended*** ***implementation*** of optimistic UI.

```typescript
mutate(updateUser(data), {
  optimisticData: data,
  populateCache: true,
  revalidate: true,
  rollbackOnError: true,
});
```

> It's pretty clear to see the fine-grained control you have over such a critical piece of the user's experience!

### **Some Cool Nuggets**

* SWR allows for different revalidation methods – queries automatically revalidate when refocusing on the window but you can also revalidate after a certain amount of time or even when you reconnect to the internet ✨

* You can use *GraphQL* with SWR 🚀 Just update the `fetcher` to use a library like [`graphql-request`](https://github.com/prisma-labs/graphql-request) or [`urql`](https://github.com/FormidableLabs/urql)

* Take advantage of [React 18's Suspense mode](https://www.youtube.com/watch?v=FpFetyxapto&list=LL&index=1) in SWR by adding\
  `{ suspense: true }` to an individual query our target all queries by adding it to the global config (`<SWRConfig />)`  at the root of your project.

* You can also use regular expressions to mutate multiple keys. Check out the  [custom hook](https://gt.codes/dYyeUWqh0vHj6z2tiUpz) 👀

---

\* dedupe: a technique for removing duplicate/repeating data

---

❤️ Open Source Software

Simple Data Fetching with SWR

Part of choosing a frontend framework is understanding how pages can be delivered to your users. Choosing the right method can enable major performance improvements or introduce unwanted drawbacks in your app. [Next.js](https://nextjs.org/) allows us to choose different rendering methods on a ***per page basis***, giving us the tools to iterate and deliver a better experience to users ✨ In this chat, we'll discuss the different rendering methods *(listed below)* Next.js provides so you can understand which method is right for your use case:

* client-side rendering

* server-side rendering

* static site generation

* incremental static regeneration

### **Client-side Rendering** (CSR)

Client-side rendering allows you to statically generate parts of a page without data, and fetch that data on the client-side. This is useful for pages you don't want to server-side render but are still unique to each user.  With this method you do get faster build times but it's important to note the fetched data is never cached and you won't have SEO indexing either.

### **Server-side Rendering** (SSR)

Server-side rendering is when a page is pre-rendered on the server on *every request*. You'd want to use this approach for pages that are either unique to each user or updated frequently. This method creates a slower [TTFB](https://web.dev/time-to-first-byte/) *(time to first byte)* but ensures that visitors requesting this page will always get the most up-to-date content!

### **Static Site Generation** (SSG)

Static site generation allows Next.js to pre-render your pages at build time, regardless if they have data or not. All pages that don't export `getServerSideProps` will be pre-rendered at build time. This is optimal when your content doesn't change, which means it should be delivered as quickly as possible. By using this method, pages are globally cached by a CDN and served instantly. This gives your site high availability, even if your backend is down – making this method more performant than **SSR**. A caveat is that your data could be stale at request time – but don't worry, we have a solution for that.

### **Incremental Static Regeneration** (ISR)

Incremental static regeneration allows you to add and update statically pre-rendered pages incrementally *after* build time. This means you can deliver static pages with **SSG** and update them after they've been pre-built! You can simply add a revalidation time when you return from `getStaticProps` like below:

```typescript
export function getStaticProps() {
  // ...
  return {
    props: {
      // ...
      revalidate: 60
    }
  }
}
```

> This snippet is telling Vercel to rebuild and cache the page every `60` seconds. I go more in depth about ISR in this [artcle](https://gt.codes/B0E1ByROBwgO2aLCKWey).

You may experience unnecessary reads to your database if you use **ISR** on a page that doesn't frequently update. You can still deliver dynamic content in static pages with **On-demand ISR**. This feature allows you to revalidate a page whenever you want *(via webhook, mutations via endpoints, etc.)*, giving you full control over the dynamism of your static pages. Here's how:

```typescript
// pages/api/user.ts

export default function handler(req, res) {
  const { userId, data } = req.body;
  
  await updateUser(userId, data);
  await res.unstable_revalidate(`/u/${userId}`);

  res.status(200).end();
}
```

> The `res.unstable_revalidate` method can be used anywhere `res: NextApiResponse` is available and simply pass it the route you want to revalidate.

Using on-demand ISR eliminates any unnecessary reads to your database when regenerating static pages.

### **Let's Build 🚀**

We'll build an [app](https://gallery.vercel.zone/) that allows users to add their favorite [Unsplash](https://unsplash.com/) photos to a public gallery. This app will showcase the different rendering methods Next.js offers. We'll have the following routes:

`/` : The index route will be **client-side rendered** to display all images from users.

`/i/[id]` : A dynamic route for each individual image – this will be **statically generated** at build time.

> Why should these dynamic routes be statically generated? ***Once uploaded, this data won't get updated, meaning it's static content and should be delivered as fast as possible ✨***

`/u/[id]` : A dynamic route for each user showing their uploaded images– this will also be **statically generated** and updated using **ISR**. We're using this approach since users can upload new images over time but we still want the content to be fast!

Since the `/` *(index route)* is being **client-side rendered**, we're data fetching when the component first loads via `useEffect` like so:

```typescript
useEffect(() => {
  const fetchData = async () => {
    setLoading(true);
    
    const res = await fetch('/api/links/getAll');
    const data = await res.json();
    
    setPosts(data);
    setLoading(false);
  };

  fetchData();
}, []);
```

To generate the dynamic paths for `/i/[id]` *(dynamic image pages)*, we need to use `getStaticPaths` to get all of the routes – this is pretty simple:

```typescript
export async function getStaticPaths() {
  const posts = await prisma.post.findMany();
  const paths = posts.map((post) => ({
    params: { id: post.id },
  }));
  
  return { paths, fallback: true };
}; 
```

> 💡 If a user visits a route that hasn't been built yet *(/i/random-route)*,  `fallback: true` allows us to generate a loading state while the page gets rendered and cached globally!

Now that we have each route, we need to statically generate and pre-render the page:

```typescript
export async function getStaticProps({ params }) {
  const post = await prisma.post.findUnique({
    where: { id: params?.id as string }
  });

  if (!post) {
    return {
      notFound: true,
      revalidate: 10,
    };
  }

  return { 
    props: { 
      post 
    } 
  };
}; 
```

> 💡 If the user visits a route where there is no post *(image)*, we redirect them to a 404 page and `revalidate` every 10 seconds in the case that post is added to the database.

We use a very similar approach with `/u/[id]` *(dynamic user pages)*:

```typescript
export async function getStaticPaths() {
  const users = await prisma.user.findMany();
  const paths = users.map((user) => ({
    params: { id: user.id },
  }));
  
  return { paths, fallback: true };
}; 
```

```typescript
export async function getStaticProps({ params }) {
  const user = await prisma.user.findUnique({
    where: { id: params?.id as string }
  });

  if (!user) {
    return {
      notFound: true,
      revalidate: 10,
    };
  }

  return { 
    props: { 
      user 
    } 
  };
}; 
```

The only difference with this dynamic user page is that I have an API route that revalidates `/u/[id]` whenever someone uploads a new image. It looks like this:

```typescript
export default async function handler(req, res) {
  const { url, email } = req.body;

  const post = await prisma.post.create({
    data: {
      url,
      userEmail: email,
    },
  });

  await res.unstable_revalidate(`/u/${post.user.id}`);
  res.status(200).json({ status: 'Success' });
}
```

> 💡 Remember that `res.unstable_revalidate` rebuilds pages on-demand, which allows us to serve static user pages while always being up-to-date ⚡

### **Wrap Up**

Understanding how your pages are delivered to users is an important part of providing them with a great experience. I hope you have a better understanding of the different rendering strategies in Next.js ✨ You can view the app [here](https://gallery.vercel.zone/) and check out the full source-code [here](https://github.com/gt-codes/rendering) 😄.

---

❤️ Open Source Software

Rendering in Next.js

### **`useMatchMutate`**

A custom hook to revalidate multiple queries in [SWR](https://swr.vercel.app/) using regular expressions with. Thanks [Lazar](https://twitter.com/NikolovLazar) for this ✨

```typescript
import { useSWRConfig } from "swr";

export function useMatchMutate() {
    const { cache, mutate } = useSWRConfig();
    return (matcher, ...args) => {
        if (!(cache instanceof Map)) {
            throw new Error(
                "matchMutate requires the cache provider to be a Map instance",
            );
        }

        const keys = [];

        for (const key of cache.keys()) {
            if (matcher.test(key)) {
                keys.push(key);
            }
        }

        const mutations = keys.map((key) => mutate(key, ...args));
        return Promise.all(mutations);
    };
}
```

### **`keyExtractor`**

Part of my advanced TypeScript learning, extracting keys from an object array using *Generics*. This really improves the developer experience when I write my own utilities ✨

```typescript
function keyExtractor<Data, Key extends keyof Data>
(data: Data[], key: Key) => return data.map(el => el[key]);
```

### **`formatToMilitary`**

I've found myself in this dilemma of converting a number and it's meridiem to a proper 24 hour time when generate ISO timestamps. Simple, yet convenient ✨

```typescript
function formatToMilitary(hour: number, meridiem: string) {
  if (meridiem === "AM") {
    if (hour === 12) return 0;
    return hour;
  } else {
    if (hour === 12) return 12;
    return hour + 12;
  }
} 
```

Some Cool Nuggets

### What is Heaust?

I'd say my family is pretty traditional – we usually do the holiday family gatherings and other annual celebrations too. Time and time again, I see the issue of not knowing ***who*** was supposed to bring ***what*** to these events, caused by clear miscommunication that could've been averted. I wanted to build something to help my family since we host a lot of gatherings but realized this could actually help more people. I'm building **`Heaust`** – a simple way to keep track of guests and what they bring to your next event. Simply create an event, share it with others, and view who all is coming and if they're bringing something!

### The Tech Stack

* [Remix.run](https://remix.run)

* [Chakra UI](https://chakra-ui.com)

* [TypeScript](https://www.typescriptlang.org)

* [Prisma](https://www.prisma.io)

* [PlanetScale](https://planetscale.com)

### Routing

You'll have to excuse my background in web development; my existing knowledge stems from static HTML sites straight to React so I never really heard about [nested routes](https://remix.run/docs/en/v1/guides/routing#what-are-nested-routes) until now! Nested routing allows you to render components under a specific URL. That's how the web works currently but nested routes take it to another level – especially when it comes to dynamic data.

> With nested routes, I can render a modal or a drawer by going to a specific URL! In this case, when someone goes to `/events/new`, a drawer pops out allowing them to create a new event; **I find this to be so dope!**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FjoOEgL4DvxVyDppOnWAseb3LIMM2%2Fj4GmtmAIR8GBKAgVyjtv%2Fed2f196a-c273-4988-97ba-b0caddac28a0.png?alt=media&token=64ed31c4-8f68-477b-a9bc-b69ed6af5a52","id":"ed2f196a-c273-4988-97ba-b0caddac28a0","width":4320,"height":2700,"filename":"Screen Shot 2021-12-16 at 9.37 1.png","type":"image/png","caption":"Triggering a drawer with nested routes","border":false}]}
```

I really like nested routes because it gets me thinking about layout more than individual pages. Might sound weird but here's what I mean. For **Heaust**, there are multiple events, of course, but  there are two main components to each event page: details and activity. Instead of worrying about rendering them both at the same time or having client-side state, I can take advantage of nested routing to conditionally render that specific UI.

Here's what it looks like: `/events/event-id/details` renders only the details page and `/events/event-id/activity` only renders the activity page. What's great about this approach is that all routes are server-side rendered so I can add authentication logic to block off requests to certain routes! This also means my queries live where my UI lives, which is [colocation](https://twitter.com/housecor/status/1214536685138186243) *(a term I've recently learned and like a lot)*. All this talk about routes and queries is a perfect segue into the next piece we all know and love, data fetching!

### Data Fetching

Simply put, Remix gives you a `loader` function where you can run whatever queries and business logic you need, on the server. You then consume your data on the client with a nice hook Remix gives to you called `useLoaderData()`. Combine this with nested routes and you'll only fetch data for that particular route.

> Navigating to `/events/event-id/details` will only fetch data for the details page and never the activity page – this is major!

### Prisma

I'm so glad Prisma is a thing; SQL and I don't necessarily match so it's nice that I can execute SQL queries from a type-safe API! I've never heard of an [ORM (object-relational mapping)](https://www.prisma.io/docs/concepts/overview/prisma-in-your-stack/is-prisma-an-orm#what-are-orms) until Prisma but through building queries and mutations, I have a better understanding of what that really means. What's interesting is my Prisma schema would have more fields than what my PlanetScale database has *(image below)* and that confused me at first but then I realized that Prisma handles the relationships that you specify *(hence, the term ORM and my low SQL knowledge).*

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FjoOEgL4DvxVyDppOnWAseb3LIMM2%2Fj4GmtmAIR8GBKAgVyjtv%2F851d5620-1ea1-4cd6-a6d6-74a66a161d2a.jpg?alt=media&token=430c49f9-3153-4d91-87df-d4d58fb47e30","id":"851d5620-1ea1-4cd6-a6d6-74a66a161d2a","width":3873,"height":2406,"filename":"schema.jpg","type":"image/jpeg","caption":"Prisma schema (left) and PlanetScale schema (right)","border":false}]}
```

### PlanetScale

Who would've thought I'd break the hold [Firebase](https://firebase.google.com) had on me and start using a SQL database again?! I've been wanting to try the infamous Prisma-PlanetScale combo for a while now and I'm glad I finally tried it out! PlanetScale is dope because it brings familiar git concepts ***(branching and pull requests)*** into the realm of databases. With a free account, you get 3 branches for your project and this is pretty nice because you can use them for your `main` branch, a `shadow` branch *(I'm still learning it's purpose)*, and the 3rd would be for your deploy requests *(like pull requests but for your database schema) so you can easily test out changes*.

> Here's a [nice walkthrough](https://docs.planetscale.com/tutorials/automatic-prisma-migrations) of working with Prisma and PlanetScale.

### Some Cool Nuggets

* Remix fetches all assets and bundles for ***only*** the nested routes that are being used. For example, with the following file structure:

```markdown
routes/
  events/
    $id.tsx
    new.tsx
  events.tsx
  index.tsx
```

When navigating to `/events/new`, Remix will run the loaders *(data fetching)* for both `/events`  and  `/events/new`.

* You know how the `useState` hook is for keeping track of data in React applications? Apparently, the web already does this for you...with `FormData`. Simply add a `name` attribute to your `<input />` and you can access it's value like so:

```typescript
const body = new FormData(form);
const email = body.get("email");
```

> BTW, Remix does a good job of this when [submitting forms in your routes](https://remix.run/docs/en/v1/guides/data-writes#html-form-post).

* Prisma queries allow you to `include` relations in what is returned to you! Kinda reminds me of GraphQL, how you can structure the response to your specific needs.

### Final Thoughts

Using this tech stack for **Heaust** has been really fun and insightful! This stack allows me to move more freely and quickly so I can cut down on engineering time, which is always a plus! My plan of action with **Heaust** is to make it mobile responsive and do a little bit of touching up so it has a dope UX *([framer-motion](https://www.framer.com/motion/) might help with this) before I launch it*. If you want to know when Heaust goes live, [let me know](https://tally.so/r/mJWWJ3)!

Hopefully this was a good read and provided some value to you! Be sure to follow me on [Twitter](https://twitter.com/gt_codes) for more nuggets!

The Tech Stack Behind Heaust

Starting a new job at Vercel ✨ https://twitter.com/gt_codes/status/1518635979023654912?s=20&t=wvmIu-50oswZ6hEitXZidw

Sales Engineer

Issue #3

Issue #2

Issue #4

Code Snippets

~ Here are some nuggets I think are handy

Issue #1

A Raycast extension to create beautiful images of your code using ray.so

Ray.so Extension

Heaust allows you to manage your event's necessities with ease. Simply create an event, add the items you need guests to bring, and share the event with others!

Heaust

Wheredyougo is a new way to document your travel! After taking a trip, you can let others know what you did and where you went. Currently crossing our *t*s and dotting our *i*s. Built with Next.js, Prisma, and Planetscale ✨

Wheredyougo (WIP)

A decentralized photo-sharing app made with Next.js and Solidity.

Waver

Performed data analysis on a new proof of concept
that leverages big data using GPUs to create visual
dashboards for clients. Hands-on experience with the
AGILE Methodology involving the deployment of a
machine-learning algorithm.

Software Engineering Intern

An immerse, one-year program where I work
alongside other HBCU/HSI students and learn
computer science topics taught by Google engineers
and researchers at their Silicon Valley campuses for
an entire academic year.

Google Tech Exchange Program

Worked on Google Search where I modeled components from Google’s design system and created data-driven prototypes to help bridge the gap between Design and Engineering.

UX Engineer Intern

Coordinating with cross-functional teams to establish a consistent design language for our designers and front-end devs. Introduced Next.js to upgrade our design system documentation for more collaboration and transparency.

Garrett Tolbert

Side Projects

Writing

Work Experience

Education

Contact