{"id":9689,"date":"2026-05-18T09:16:41","date_gmt":"2026-05-18T14:16:41","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=9689"},"modified":"2026-05-18T09:16:42","modified_gmt":"2026-05-18T14:16:42","slug":"react-server-components-in-tanstack","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/react-server-components-in-tanstack\/","title":{"rendered":"React Server Components in TanStack"},"content":{"rendered":"\n

This post is about React Server Components<\/a> (or RSC) in TanStack Start<\/a>. The implementation is radically different, and in my opinion, better than the RSC implementation you’ve likely seen in Next.js.<\/p>\n\n\n\n

This post will not be a direct 1:1 comparison. Instead, I’ll introduce this feature from first principles, as it exists in TanStack.<\/p>\n\n\n\n

What are React Server Components<\/h2>\n\n\n\n

Server Components are normal React components with one key feature: they run on the server, and only<\/em> on the server. This leads to a few key differences.<\/p>\n\n\n\n

RSCs can be async and can request data directly from within the component. It can await<\/code>, well, anything that yields data. That could be a fetch from a 3rd-party API, or a direct call to your database. Since RSCs only run on the server, you don’t have to worry about your browser hopelessly failing to establish a TCP connection to your Postgres box, nor do you have to worry about secrets like connection strings being exposed to end users.<\/p>\n\n\n\n

The other key difference with RSC is hidden in plain sight, as we’ve already discussed: since these components only ever run on the server, their code will never be shipped to the client. RSCs simply send the final rendered markup, without the code that created it, to your client bundles.<\/p>\n\n\n\n

Since RSCs only exist on the server, they cannot have any state or user-facing interactivity. They cannot use hooks like useState<\/code>, or have event handlers like onClick. If you need to integrate interactive content like that with RSC, you can, and we’ll go over how. But the RSCs themselves are React components that exist to run on the Server, and generate static content that’s shipped to the client (possibly with client components intermixed).<\/p>\n\n\n\n

What RSC is Not<\/h2>\n\n\n\n

Don’t be mistaken: RSC is not<\/em> a solution for loading<\/span> data more conveniently. TanStack Start already ships extremely simple, streamlined data-loading options. You have nested, isomorphic loaders for every level in your routing hierarchy. These loaders run on the server for your initial render and then on the client thereafter. This enables the deep integration with react-query<\/a> TanStack Start offers, along with fine-grained data invalidation. I wrote all about this in a previous introduction to TanStack Start<\/a>.<\/p>\n\n\n\n

RSC is also not a way to server-render content. TanStack Start (and Next.js for that matter), already<\/em> server renders your initial navigation, and always has. Your normal, old-school components always render on the server, and then re-render on the client, wiring up event handlers and effects in a process known as “hydration.” RSCs also render on the server, but they only<\/em> render on the server.<\/p>\n\n\n\n

Where RSC Shines<\/h2>\n\n\n\n

By rendering only on the server, your client bundles avoid the cost of all the code required to render your content. That means component trees that are large and expensive, with minimal client-side interactivity, are a prime candidate.<\/p>\n\n\n\n

The original blog post announcement<\/a> for TanStack’s RSCs discussed using them for content with code samples. By moving the code to parse, style, and format displayed code to the server, those libraries were removed from client-side bundles, saving non-trivial amounts of space.<\/p>\n\n\n\n

In this post, we’ll simulate another good use case: content that’s mostly non-interactive, with many conditional imports and conditional rendering. Imagine an application shell, or layout, that can look lots of different ways depending on who’s viewing it: non-authenticated users, authenticated users, admin users, or even just authenticated users with varying permissions, which affect the content they’re shown.<\/p>\n\n\n\n

To keep things simple, we’ll build a dirt-simple application layout, but use some trickery to bloat the component bundle, so we can see how much lighter it is when we switch to RSC. We’ll then see about adding interactivity.<\/p>\n\n\n\n

Getting Started<\/h2>\n\n\n\n

Check the docs<\/a> for instructions on configuring Vite for RSC.<\/p>\n\n\n\n

The repo for what we’ll be building is here<\/a>. It’s essentially an empty web application, with a skeleton layout that looks like this:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If the icons in the side panel don’t make much sense, it’s because they’re randomly chosen in a way that guarantees the entirety of the lucide-react<\/a> icon package cannot be tree shaken. This is how we’re simulating a large component tree that’s not needed on the client.<\/p>\n\n\n\n

In the header, the avatar is clickable and opens a side panel, driven by the shadcn\/ui Sidebar<\/a> component.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The Normal Way<\/h2>\n\n\n\n

Building out this UI with standard, non-RSC components is a familiar process for anyone who’s worked with TanStack.<\/p>\n\n\n\n

We render our application shell from our root component, which handles the root layout. To simulate loading our logged-in user, we’ll add a loader to this same root layout.<\/p>\n\n\n

loader: async<\/span> () => {\n  const<\/span> user = new<\/span> Promise<\/span><{ name: string<\/span>; avatar: string<\/span> }>((res<\/span><\/span>) =><\/span> {\n    setTimeout(()<\/span> =><\/span> {\n      res({ name: \"Adam Rackis\"<\/span>, avatar: \"https:\/\/d193qjyckdxivp.cloudfront.net\/avatar.jpg\"<\/span> });\n    }, 1000<\/span>);\n  });\n  return<\/span> { user };\n},<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
We won’t mess with real data, just a (long) manual delay, and we send data back. Actually, we send our data in<\/em> a promise<\/em>. TanStack Start allows us to return promises from loaders, which get streamed to the UI once ready. This will be a nice opportunity for us to see Suspense-based streaming both with and without RSC.<\/p>\n\n\n\n
And here’s our non-RSC application shell component<\/p>\n\n\n
type<\/span> ApplicationShellProps = {\n  user: Promise<\/span><{\n    name: string<\/span>;\n    avatar: string<\/span>;\n  }>;\n};\n\nexport<\/span> const<\/span> ApplicationShellNonRSC: FC<PropsWithChildren<ApplicationShellProps>> = props<\/span> =><\/span> {\n  const<\/span> { children, user } = props;\n\n  return<\/span> (\n    <main className=\"h-screen\"<\/span>>\n      <header className=\"fixed top-0 left-0 right-0 h-12 z-10 bg-blue-200 flex items-center px-4 gap-4\"<\/span>>\n        <Suspense fallback={<span className=\"w-6 h-6 bg-gray-400 rounded-full\"<\/span>><\/span>}>\n          <UserHeaderMenu user={user} \/<\/span>>\n        <\/Suspense>\n        <span>Header<\/<\/span>span>\n      <\/header>\n      <section className=\"fixed left-0 top-12 bottom-0 w-60 overflow-auto \">\n        <SideBarContent \/<\/span>>\n      <\/section>\n      <section className=\"max-w-[600px] pt-16 mx-auto h-full\">\n        <div className=\"flex flex-col gap-2 h-full\">\n          <section className=\"min-h-[200px]\">{children}<\/<\/span>section>\n          <footer className=\"px-4 fixed bottom-0 left-0 right-0 h-12 z-10 bg-blue-200 flex gap-4 items-center\"<\/span>><\/footer>\n        <\/<\/span>div>\n      <\/section>\n    <\/m<\/span>ain>\n  );\n};<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Notice that we pass that same promise<\/em> with our user data over to UserHeaderMenu<\/code>, which itself is wrapped in a Suspense tag. Here’s that component.<\/p>\n\n\n
const<\/span> UserHeaderMenu: FC<{ user: Promise<\/span><{ name: string<\/span>; avatar: string<\/span> }> }> = props<\/span> =><\/span> {\n  const<\/span> { user } = props;\n  const<\/span> { name, avatar } = use(user);\n\n  return<\/span> <SidePanelTrigger name={name} avatar={avatar} \/>;\n};<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
We call use<\/code> on the user info promise, a special pseudo-hook exported by React (version 19 and beyond). The use<\/code> function causes our component to suspend and render the fallback from the Suspense<\/code> tag.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
When the data are ready, the promise resolves, and our content shows our full UI.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
The Non-RSC Payload<\/h2>\n\n\n\n
As I said above, I’ve used some trickery to force the entire Lucide React package to be bundled, simulating a deeply nested component hierarchy.<\/p>\n\n\n\n
On a production build, a total of 308 KB of JavaScript is sent down.<\/p>\n\n\n\n
Rendering with RSC<\/h2>\n\n\n\n
Let’s start with the simplest possible RSC component, which takes no props. It won’t even take children, which itself is just a prop. Here’s a new version of our application shell.<\/p>\n\n\n
import<\/span> { type<\/span> FC } from<\/span> \"react\"<\/span>;\nimport<\/span> { SideBarContent } from<\/span> \".\/SideBarContent\"<\/span>;\n\ntype<\/span> ApplicationShellProps = {};\n\nexport<\/span> const<\/span> ApplicationShellEmptyRSC: FC<ApplicationShellProps> = ()<\/span> =><\/span> {\n  return<\/span> (\n    <main className=\"h-screen\"<\/span>>\n      <header className=\"fixed top-0 left-0 right-0 h-12 z-10 bg-blue-200 flex items-center px-4 gap-4\"<\/span>>\n        <span>Header<\/span>\n      <\/<\/span>header>\n      <section className=\"fixed left-0 top-12 bottom-0 w-60 overflow-auto \"<\/span>>\n        <SideBarContent \/>\n      <\/section>\n      <section className=\"max-w-[600px] pt-16 mx-auto h-full\">\n        <div className=\"flex flex-col gap-2 h-full\">\n          <section className=\"min-h-[200px]\"><\/<\/span>section>\n          <footer className=\"px-4 fixed bottom-0 left-0 right-0 h-12 z-10 bg-blue-200 flex gap-4 items-center\"<\/span>><\/footer>\n        <\/<\/span>div>\n      <\/section>\n    <\/m<\/span>ain>\n  );\n};<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
To be clear, this component is useless. It does not display our header, nor does it display the actual, currently rendered page (via children). But it will let us see how to render an RSC that takes no props.<\/p>\n\n\n\n
Let’s see how to render it as an RSC.<\/p>\n\n\n\n
First, we’ll import it into our root layout (or any layout, or route, or component), as well as a new helper from TanStack<\/p>\n\n\n
import<\/span> { ApplicationShellEmptyRSC } from<\/span> \"#\/components\/ApplicationShellEmptyRSC\"<\/span>;\nimport<\/span> { renderServerComponent } from<\/span> \"@tanstack\/react-start\/rsc\"<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Then we’ll create a serverFn<\/code> to turn this component into an RSC stream.<\/p>\n\n\n
const<\/span> getAppShell = createServerFn({\n  method: \"GET\"<\/span>,\n}).handler(async<\/span> () => {\n  return<\/span> renderServerComponent(<ApplicationShellEmptyRSC \/>);\n});<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Now we just need to call<\/em> our server function. We can do this anywhere. For our purposes, we’ll just call it in our loader and send the result down.<\/p>\n\n\n
  loader: async<\/span> () => {\n    const<\/span> appShell = await<\/span> getAppShell();\n    return<\/span> { appShell };\n  },<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
In our React component, we grab that payload and render it.<\/p>\n\n\n
function<\/span> RootDocument<\/span>({ children }: { children: React.ReactNode }<\/span>) <\/span>{\n  const<\/span> { appShell } = Route.useLoaderData();\n\n  return<\/span> (\n    <html lang=\"en\"<\/span> suppressHydrationWarning>\n      <head>\n        <HeadContent \/>\n      <\/head>\n      <body>\n        {\/<\/span>* render the RSC *\/}\n        {appShell}\n      <\/<\/span>body>\n    <\/html>\n  );\n}<\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
This works! Simple as that.<\/p>\n\n\n\n
The thing I like most about TanStack Start’s RSC implementation is that it’s very explicit. You have a clear API for declaring what you want to be rendered as an RSC.<\/p>\n\n\n\n
Rendering Interactive Content<\/h2>\n\n\n\n
We could end this blog post pretty abruptly and simply render our SidePanelTrigger<\/code> component directly from our RSC. That would work fine, so long as we do one thing: place the \"use client\"<\/code> pragma at the top of the file that contains this component. That would work, and we would be done.\u00a0<\/p>\n\n\n\n
But instead, let’s do it a slightly harder way, so we can explore another feature of RSC: passing props. Instead of rendering SidePanelTrigger<\/code> from the RSC, we’ll\u00a0pass\u00a0<\/strong>this component to the RSC\u00a0as a prop\u00a0<\/em>and render it from there. While overkill for this use case, it’ll show off some of the amazing flexibility RSC offers, enabling a single Server Component to render different content via different props passed to the RSC.<\/p>\n\n\n\n
Passing Props to our RSC<\/h2>\n\n\n\n
Let’s finish this up. We need some new helpers.<\/p>\n\n\n
import<\/span> { createCompositeComponent, CompositeComponent } from<\/span> \"@tanstack\/react-start\/rsc\"<\/span>;<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Props in RSC<\/h3>\n\n\n\n
It\u2019s important to remember that, by the time our Server Function runs and we return the shell component, our component has already rendered<\/em>.<\/p>\n\n\n
return<\/span> renderServerComponent(<ApplicationShellEmptyRSC \/>);<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
 It’s done. It rendered on the server<\/em> and the thing we’re holding, returned from our server function and renderServerComponent<\/code> (or createCompositeComponent<\/code>) is, conceptually, the final markup for the RSC.<\/p>\n\n\n\n
We’ll be putting it in our component tree, but again, and this cannot be overstated, the RSC itself has already rendered<\/em>.<\/p>\n\n\n\n
That means, if you think you can just pass some data into the RSC, and use that data to adjust the content that’s rendered, you fundamentally do not understand how RSCs work: again, by the time you attempt to display it in your component tree, the RSC component has already rendered<\/em> on the server, and produced markup. This makes any attempt to pass props from the client to the RSC to influence said markup a non-sequitur<\/p>\n\n\n\n
So how can we pass props?<\/h3>\n\n\n\n
What RSCs do allow is to pass in children<\/code> content, or other components<\/em> as props. The RSC recognizes these props and renders “holes” or “slots” (in a generic sense) for them to be dumped into.<\/p>\n\n\n\n
Let’s take a look.<\/p>\n\n\n\n
Adding Props to our RSC<\/h3>\n\n\n\n
Here’s our new server function.<\/p>\n\n\n
const<\/span> getAppShell = createServerFn({\n  method: \"GET\"<\/span>,\n}).handler(async<\/span> () => {\n  return<\/span> createCompositeComponent(\n    (\n      props: PropsWithChildren<{\n        HeaderContent: FC<{ name: string<\/span>; avatar: string<\/span> }>;\n      }>,\n    ) => <ApplicationShell children={props.children} HeaderContent={props.HeaderContent} \/>,\n  );\n});<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
We’re using createCompositeComponent<\/code> which allows us to declare props. We’re using the PropsWithChildren<\/code> generic helper, which implicitly declares a children prop of type ReactNode<\/code>, and we’re adding a HeaderContent<\/code> prop, which is a component.<\/p>\n\n\n\n
One neat thing about TanStack’s RSC implementation is that props passed like this are automatically<\/em> client components; you don’t have to add \"use client\"<\/code> to the file, although it’s fine if you do. Note that this applies to components you pass<\/em> to props. Content you render<\/em> as children<\/code> can include RSC content if you’d like. You’d render other RSC content exactly like we did above, with {appShell}<\/code>.<\/p>\n\n\n\n
As before, we load our RSC in our loader.<\/p>\n\n\n
  loader: async<\/span> () => {\n    const<\/span> appShell = await<\/span> getAppShell();\n    return<\/span> { appShell };\n  },<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Then grab it in our component.<\/p>\n\n\n
const<\/span> { appShell } = Route.useLoaderData();<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
And now we can render this with the CompositeComponent<\/code> helper. We render CompositeComponent<\/code> like a component, and pass the RSC result as the src<\/code> prop, as well as any other props we may have.<\/p>\n\n\n
<CompositeComponent<\/span> src<\/span>={appShell}<\/span> HeaderContent<\/span>={SidePanelTrigger}<\/span>><\/span>\n  {children}\n<\/CompositeComponent<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
Loading Data in RSC<\/h3>\n\n\n\n
Now let’s look at our actual RSC.<\/p>\n\n\n
import<\/span> { Suspense, type<\/span> FC, type<\/span> PropsWithChildren } from<\/span> \"react\"<\/span>;\nimport<\/span> { SideBarContent } from<\/span> \".\/SideBarContent\"<\/span>;\n\ntype<\/span> ApplicationShellProps = {\n  HeaderContent: FC<{ name: string<\/span>; avatar: string<\/span> }>;\n};\n\nexport<\/span> const<\/span> ApplicationShell: FC<PropsWithChildren<ApplicationShellProps>> = props<\/span> =><\/span> {\n  const<\/span> { children, HeaderContent } = props;\n\n  return<\/span> (\n    <main>\n      <header>\n        <Suspense fallback={<span><\/span>}>\n          <UserHeaderMenu HeaderContent={HeaderContent} \/<\/span>>\n        <\/Suspense>\n        <span>Header<\/<\/span>span>\n      <\/header>\n      <section>\n        <SideBarContent \/<\/span>>\n      <\/section>\n      <section>\n        <div>\n          <section>{children}<\/<\/span>section>\n          <footer><\/footer>\n        <\/<\/span>div>\n      <\/section>\n    <\/m<\/span>ain>\n  );\n};<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Notice this piece.<\/p>\n\n\n
<Suspense fallback={<span><\/span>}>\n  <UserHeaderMenu HeaderContent={HeaderContent} \/<\/span>>\n<\/Suspense><\/span><\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
We’re rendering another component, UserHeaderMenu<\/code> within a Suspense<\/code> tag, and passing through the HeaderContent prop, which again is a React client component that takes in a name and an avatar prop. Let’s see it next<\/p>\n\n\n
async<\/span> function<\/span> UserHeaderMenu<\/span>(props: { HeaderContent: FC<{ name: string<\/span>; avatar: string<\/span> }> }<\/span>) <\/span>{\n  const<\/span> { HeaderContent } = props;\n\n  await<\/span> new<\/span> Promise<\/span>(resolve<\/span> =><\/span> setTimeout(resolve, 1000<\/span>));\n  const<\/span> avatar = \"https:\/\/d193qjyckdxivp.cloudfront.net\/avatar.jpg\"<\/span>;\n  const<\/span> name = \"Adam Rackis\"<\/span>;\n\n  return<\/span> <HeaderContent name={name} avatar={avatar} \/>;\n}<\/code><\/span>Code language:<\/span> TypeScript<\/span> (<\/span>typescript<\/span>)<\/span><\/small><\/pre>\n\n\n
Since we’re in an RSC, we don’t have to use the use<\/code> pseudo-hook. We can just await<\/code> our data however we want, and while those data are pending, the Suspense boundary’s fallback will render without blocking the rest of the content, as before. Then, a second later, our data will be ready, and our avatar will show.<\/p>\n\n\n\n
This works and produces the same experience we saw originally, with the client-rendered version, except now as an RSC.<\/p>\n\n\n\n
The Total Savings with RSC<\/h2>\n\n\n\n
What are the savings? The non-RSC version pushed 308KB of JavaScript into the client. The RSC version reduces it to 203KB (both measurements are from production builds).<\/p>\n\n\n\n
When to use RSC<\/h2>\n\n\n\n
Please don’t think this is a panacea, or even something you should use in every project. The larger and more expensive the component tree, the larger your potential savings. But if your component tree isn’t doing much, isn’t pulling in heavy dependencies (which don’t need state or interactivity), doesn’t have a wide import graph with things that are conditionally rendered, then there’s a good chance RSC will offer you minimal benefit.<\/p>\n\n\n\n
This is a tool like any other, and like any other tool, you need to know when to reach for it, and when not to.<\/p>\n\n\n\n
Concluding Thoughts<\/h2>\n\n\n\n
TanStack’s implementation of RSC is what I wanted all along, without ever knowing it. Data fetching in TanStack is already simple; RSC exists to provide a more performant rendering idiom where things don\u2019t exist on the client when they don\u2019t need to, or when existing on the client would be expensive.<\/p>\n","protected":false},"excerpt":{"rendered":"
RSCs in TanStack Start are server-only executed code \u2014 perhaps a significant improvement over the Next.js implementation.<\/p>\n","protected":false},"author":21,"featured_media":9703,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[62,435,240],"class_list":["post-9689","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-react","tag-rscs","tag-tanstack"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2026\/05\/RSCs.jpg?fit=2000%2C1200&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/9689","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=9689"}],"version-history":[{"count":11,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/9689\/revisions"}],"predecessor-version":[{"id":9726,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/9689\/revisions\/9726"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/9703"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=9689"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=9689"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=9689"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}