Vercel e Shopify Estão Reconstruindo o Hydrogen O Que Muda pro Dev Brasileiro

Por que o Hydrogen precisava de um rewrite

Olha só: o Hydrogen deixou os storefronts headless da Shopify fáceis de subir, mas não eram portáveis. Você ficava preso a um runtime específico e cada time escrevia o mesmo código de cola do zero. Isso não escala, né?

Na Vercel Ship 26, em Nova York, a Vercel e a Shopify anunciaram que estão reconstruindo o Hydrogen do zero. A nova versão é open source e runtime-agnostic — roda em qualquer lugar onde JavaScript roda. Pode usar Svelte, Nuxt, Next.js ou até trazer seu framework customizado. Vamos lá!

A arquitetura foi dividida em três camadas: core, client e server. Cada uma resolve um tipo específico de repetição que devs de e-commerce vêm duplicando há anos.

Segundo o anúncio original da Vercel, é uma aposta de longo prazo em neutralidade de framework, não em template de vendor único.

Camada Core: pare de reescrever glue code da API da Shopify

A camada core é aquele JavaScript que todo mundo escrevia pra API da Shopify e nunca compartilhava. Pega o formatMoney — a web aberta já resolveu isso com Intl.NumberFormat:

const price = new Intl.NumberFormat("pt-BR", {
  style: "currency",
  currency: "BRL",
}).format(19.99);
// "R$ 19,99"

Mas a API da Shopify não te entrega um number. Ela responde com um tipo customizado, MoneyV2, e o valor é um decimal serializado como string. É aí que entra o core do Hydrogen:

import { formatMoney, type MoneyV2 } from "@shopify/hydrogen";

export function formatPrice(money: MoneyV2, locale = "pt-BR") {
  return formatMoney(money, { locale }).toString();
  // R$ 19,99
}

O resultado é o mesmo, mas você não escreve nem mantém mais o glue code. Quando a API muda, o upgrade é trivial. Centraliza o core e você conserta cada bug uma vez só, distribui a melhoria pra todo mundo e volta a construir o que importa.

Camada Client: estado do carrinho em um único import

Renderizar o que o core retorna envolve as mesmas decisões repetidas. Estado de carrinho é o exemplo clássico. Quem já construiu um app de e-commerce escreveu algo assim:

import { createContext, useContext, useState, useCallback } from "react";

const CartContext = createContext(null);

export function CartProvider({ children }) {
  const [cart, setCart] = useState(null);

  const addLine = useCallback(async (variantId, quantity) => {
    // código customizado que todos nós escrevemos
  }, []);
  const updateLine = useCallback(async (variantId, quantity) => {
    // código customizado que todos nós escrevemos
  }, []);
  const removeLine = useCallback(async (variantId, quantity) => {
    // código customizado que todos nós escrevemos
  }, []);

  // applyDiscount, note, currency, error state, cross-tab sync, refetch on focus, etc.

  return (
    <CartContext.Provider value={{ cart, addLine, updateLine, removeLine }}>
      {children}
    </CartContext.Provider>
  );
}

export const useCart = () => useContext(CartContext);

Código diferente toda vez, todos perseguindo a mesma coisa. Com a nova camada client do Hydrogen, isso vira um import:

import { createCartComponents } from "@shopify/hydrogen/react";

const { useCartForm } = createCartComponents();

function AddToCartButton({ variantId }) {
  const { formProps, register } = useCartForm();

  return (
    <form {...formProps}>
      <input type="hidden" {...register("variantId", variantId)} />
      <button type="submit">Adicionar ao carrinho</button>
    </form>
  );
}

Centralizando isso você ganha as melhores práticas de graça. Já está disponível pra React hoje no branch de preview do Hydrogen, com mais frameworks chegando.

Camada Server: full-stack sem lock-in

Devs precisam de acesso full-stack pra construir storefronts que escalam sem sacrificar performance. Conteúdo estático deve servir instantaneamente de um CDN enquanto dados dinâmicos (tipo estoque) chegam em streaming.

A comunidade open source resolveu isso com frameworks como Next.js, Nuxt e SvelteKit — capacidades full-stack sem lock-in a runtime proprietário. O Hydrogen agora se pluga nesses frameworks em vez de substituí-los:

import { PRODUCT_QUERY } from "@/lib/gql";
import { storefrontConfig } from "@/lib/config";
import { cacheTag } from "next/cache";
import { createStorefrontClient } from "@shopify/hydrogen";

// Função cacheável para dados de produto, com revalidação sob demanda
export async function getProductData({ handle }) {
  "use cache";
  cacheTag(handle);

  const client = createStorefrontClient({
    type: "private_shared_rate_limit",
    config: storefrontConfig,
  });

  const { data } = await client.graphql(PRODUCT_QUERY, {
    variables: { handle },
  });

  return data;
}

A Shopify já suporta esses frameworks pelo canal Headless, mas até agora cada time escrevia seus próprios bindings pro mesmo contrato de API. Nessa camada, a solução é orientação, não mais código. Humanos e agentes de IA precisam saber como usar o que os frameworks já fazem.

Essa orientação vem como documentação, templates e skills — incluindo skills estruturadas pra agentes cobrindo i18n, markets e menus.

Comparação camada por camada

Limitações e pontos de atenção

• Só branch de preview (React). A camada client ainda não é estável em todos os frameworks. Suporte a Nuxt e Svelte está no roadmap, não foi lançado.
• Convergência com o vercel.shop pendente. O template vercel.shop da própria Vercel vai ser absorvido pelo Hydrogen quando estabilizar — ou seja, os padrões atuais do vercel.shop são transitórios.
• Interações com Cache Components. No Next.js 16 com cacheComponents: true, trocar next/link pelo Link do next-intl quebra o prerender. A orientação avisa explicitamente: você troca alguns redirects de middleware por um prerender limpo.
• Skills de agente são opinativas. A skill de i18n assume localePrefix: "always" e sem integração com Shopify Markets. Se você precisa de preço/estoque region-aware, tem que usar outra skill.
• Não é bala de prata pra migração. Apps Hydrogen existentes vão precisar de um plano de migração — a divisão em três camadas muda imports e layout de arquivos significativamente.

O que estudar a seguir

1. Fundamentos do Next.js App Router — root params, cacheComponents, samples de instant. A camada server do Hydrogen depende muito disso.
2. Padrões de roteamento do next-intl — URLs com prefixo de locale, catálogos de mensagens por locale, e como evitar forçar render dinâmico em árvores cacheadas.
3. GraphQL com clients tipados — o padrão createStorefrontClient do Hydrogen é um ótimo template pra qualquer camada de API tipada.
4. Skills de agente como formato de entrega — o padrão da skill enable-i18n (frontmatter + passo a passo + verificação) é um modelo reutilizável pra entregar orientação interna a agentes de código.

Se você curte entender como grandes plataformas gerenciam dados em escala, dá uma olhada nesse breakdown sobre como a Netflix gerencia milhões de ativos de dados com data projects. E se você acompanha o lado de tooling pra agentes de IA da Vercel, checa o Grok Build 0.1 no Vercel AI Gateway.

Resumindo

Vercel e Shopify estão apostando que e-commerce headless não deveria exigir reescrever o mesmo glue code em cada projeto. A divisão em três camadas — core, client, server — é uma resposta arquitetural limpa pra uma década de copy-paste.

O teste real não é o anúncio; é se a promessa de framework-agnostic se sustenta quando o suporte a Nuxt e Svelte sair. Por enquanto, times React no branch de preview do Hydrogen levam a maior vitória imediata: estado de carrinho como um único import, e um client Shopify tipado que sobrevive a mudanças de API.

Testa, dá fork e ajuda a moldar o que vem por aí — o repo tá aberto no GitHub.