How does Vercel use swr?

[nandorojo]

I have a bit of a broader question about how Vercel uses this library. I'm curious to hear a bit about the architecture of a modern company with such a large product.

For example, how do you use the key prop? Do you provide the endpoint URL, like useSWR('/api/user') as shown often in the docs? Or do you use user IDs directly in keys to identify keys with users?

I'm curious about type-safety as well. If you call useSWR('/api/user'), do you have to cast the types on, like useSWR<User>('/api/user')? Or do you have some sort of code-gen fetcher/types generator that does this for you? And if you are casting, is this just using a shared types package with the backend?

Example

For context, at beatgig.com, we use swr. Our backend is made with Python and FastAPI (using the OpenAPI spec.) Every time our Python server deploys, it code-gens a TypeScript package with typed functions to all of it's endpoints.

The front-end installs the package from a NPM package, imports functions, and passes them to SWR directly.

import { getUser } from '@beatgig/backend'

const useUser = ({ userId }) => {
  return useSWR([userId, 'user'], getUser)
}

//...
const user = useUser({ userId })

user.data?.name // this comes with types built in!

That's a bit of a simplified version of what we do, but it gets the message across.

Overall, I'd love some advanced details on how Vercel does this stuff. I think this kind of content would be useful in general to the community. Thanks!

[shuding]

Thanks for creating this topic! We’re using RESTful APIs, so all our SWR hooks are similar to this:

function useUser(id: string, opts?: SWRConfig) {
  return useSWR<User>(`/api/user/${id}`, fetcher, opts)
}

Sometimes we also add some related logic into it, such as attaching a isLoggedIn field to the returned object.

I think we can probably write a blog post to share more ideas about this!

[shuding]

@lenis0012 SWR is backend agnostic, it doesn't know about the data fetching process. You can pass any async function that loads the data as the fetcher.

SWR has its own caching strategy (stale-while-revalidate on specific cases), but it's not based on the HTTP Cache-Control header. By default the data is cached in the memory of the current webpage JavaScript thread, when refreshing everything will be gone.

Let me know if there's any other question!

[shuding]

@dariye thanks for the great questions!

How do you approached app/component architecture with swr in the mix?

We use Next.js, and the application structure looks like this:

/components
  user-card.tsx
/pages
  index.tsx
  about.tsx 
/swr
  use-user.ts
  use-project.ts
/design-system
  button.tsx

All the data related hooks are under /swr, and they're just lightweight wrappers of the useSWR hook, with some preset options (and can be overridden).

Each component can directly import and use those hooks without worrying about duplicate requests (SWR handles it!), like this:

function UserCard({ id }) {
  const { user } = useUser(id)
  ...
}

We've added polling for some specific resource hooks, and auto redirection when logged out for the use-user hook.

Do you still have that separation of container and functional components? Or is the line blurred and you let component fetch what they need when they need it without any separation?

We do have a separate directory for the design system related components (container/button/...) that are more abstract and atomic. So all data requirements are tied to those under the /component directory, which have more business logic inside.

For example a <Profile> component might have <Avatar> (atomic component) and useUser (data) inside:

import Avatar from 'design-system/avatar'
import useUser from 'swr/use-user'

export default function Profile({ id }) {
  const { user, loading } = useUser(id)
  if (loading) return <Skeleton/>
  return <>
    <Avatar src={user.pic}/>
    <h1>{user.name}</h1>
  </>
}

Simple and clean, doesn't have to pass data between components.

How do you avoid needless re-renders app-wide? How do you minimise layout shifts?

This is guaranteed by SWR. Since it deep compares the fetched data and only re-render when data is accessed and changes (https://swr.vercel.app/docs/advanced/performance), I don't think there are any "needless re-renders". Happy to know more about this.

The layout will be consistent since the same resource will be ready at the same time for all components consuming it. But for the other cases like dependent requests, we have three ways of avoiding layout shift: making sure the skeletons/spinners have the same size as the content, don't progressively reveal the content but wait for all data to be ready, use Suspense and SuspenseList when possible.

If you're interested in more details I can cover more with a blog post.

[lenis0012]

@lenis0012 SWR is backend agnostic, it doesn't know about the data fetching process. You can pass any async function that loads the data as the fetcher.

SWR has its own caching strategy (stale-while-revalidate on specific cases), but it's not based on the HTTP Cache-Control header. By default the data is cached in the memory of the current webpage JavaScript thread, when refreshing everything will be gone.

Let me know if there's any other question!

Thanks for answering 👍
How does swr decide when the content is stale?

I thought part of the benefit is that you can use the same url in multiple places, say /api/session/me wherever you need that and it will serve from the cache. But if that's the case, and you can't use Cache-Control headers, how does swr know when the data is fresh and when it is stale? Or is that just essentially the dedupingInterval and there is no way to determine this in the API where the data originates from

[shuding]

@lenis0012

How does swr decide when the content is stale?

When something is fetched, it immediately becomes stale because it can differ from the server value, unless it's somehow immutable. So I think in a distribute system, the data is always stale, and the tricky is to decide when we should revalidate it.

In SWR, there are a couple of default revalidation timings (with deduplication): when a component mounts, when the user re-focuses on the tab, when the network recovers. But you can also configure it manually (for example polling). We are also thinking about introducing some options to make it available for further configurations (immutability with a max-age).

And then, SWR fetches the data whenever it thinks it's good to do it. And the Cache-Control header will be considered by the browser, which is an upper layer. The browser can decide if a fresh new request is needed or not.

That's the current behavior, and the main reasons are:

• Usually for APIs, the server won't return any Cache-Control headers that have stale time.
• For web applications, usually the Cache-Control header takes effect when you refresh the page. The browser won't refetch for you when it expires. That's why we need SWR.
• For immutable resources, you can use useSWRImmutable

[arunppsg]

I am looking to adopt a dir structure for my project and I have a question: how is design-system directory different from components dir? If I am not wrong, design-system contains atomic components, like buttons, avatar and components contain components which are composed of Atomic Components. Also, the atomic components don't depend on any external data but component may depend on external data, thereby importing from swr right?

[shuding]

Repost here for more visibility, asked by @dariye:

This is great! I literally typed the exact same thing in google :D ... My question @shuding is how the app is wrapped. How do you approached app/component architecture with swr in the mix? Do you still have that separation of container and functional components? Or is the line blurred and you let component fetch what they need when they need it without any separation? How do you avoid needless re-renders app-wide? How do you minimise layout shifts?

---

How do you approached app/component architecture with swr in the mix?

We use Next.js, and the application structure looks like this:

/components
  user-card.tsx
/pages
  index.tsx
  about.tsx 
/swr
  use-user.ts
  use-project.ts
/design-system
  button.tsx

All the data related hooks are under /swr, and they're just lightweight wrappers of the useSWR hook, with some preset options (and can be overridden).

Each component can directly import and use those hooks without worrying about duplicate requests (SWR handles it!), like this:

function UserCard({ id }) {
  const { user } = useUser(id)
  ...
}

We've added polling for some specific resource hooks, and auto redirection when logged out for the use-user hook.

Do you still have that separation of container and functional components? Or is the line blurred and you let component fetch what they need when they need it without any separation?

We do have a separate directory for the design system related components (container/button/...) that are more abstract and atomic. So all data requirements are tied to those under the /component directory, which have more business logic inside.

For example a <Profile> component might have <Avatar> (atomic component) and useUser (data) inside:

import Avatar from 'design-system/avatar'
import useUser from 'swr/use-user'

export default function Profile({ id }) {
  const { user, loading } = useUser(id)
  if (loading) return <Skeleton/>
  return <>
    <Avatar src={user.pic}/>
    <h1>{user.name}</h1>
  </>
}

Simple and clean, doesn't have to pass data between components.

How do you avoid needless re-renders app-wide? How do you minimise layout shifts?

This is guaranteed by SWR. Since it deep compares the fetched data and only re-render when data is accessed and changes (https://swr.vercel.app/docs/advanced/performance), I don't think there are any "needless re-renders". Happy to know more about this.

The layout will be consistent since the same resource will be ready at the same time for all components consuming it. But for the other cases like dependent requests, we have three ways of avoiding layout shift: making sure the skeletons/spinners have the same size as the content, don't progressively reveal the content but wait for all data to be ready, use Suspense and SuspenseList when possible.

If you're interested in more details I can cover more with a blog post.

[dariye]

Thanks for the great write up, @shuding . I'm keen on reading the blog post to learn more.

The re-renders I've experienced have mostly been dealing with lists so perhaps unrelated to swr.

[grvv]

@shuding just started using SWR and your answer really helped in structuring the application. and I'd totally love the blog post if you still want to do it.

[kylemh]

Amazing write-up. Perhaps it could use a refresher given App directory is nearing a beta exit?

Just saw #2218 and I'm also curious if this pattern is still somehow viable in app directory Next.js apps. Mainly, I'm interested in seeing how I can do RSC + optimistic updates (with or without SWR)

[raiyansarker]

@shuding how can I use it with next 14? I mean is there any concept of initial data as there is in tanstack query?

[Grohotun]

Why Vercel doesn't update SWR package? Where are many issues that causing improper hydration & React bugs. Almost 4 months since last release and shady dev activity.