Renderizado del Lado del Servidor con Astro en Español

Hoy estamos encantados de anunciar el soporte experimental para el renderizado del lado del servidor (SSR) en Astro. Con SSR en Astro, hemos desbloqueado casos de uso completamente nuevos (¿e-commerce, alguien?) y una escala que simplemente no eran posibles antes. Nuestra implementación de SSR combina el enfoque único de Astro de priorizar el servidor con características dinámicas como autenticación de usuarios, flujos de inicio de sesión, acceso a bases de datos, obtención de datos y más.

Si estás listo para empezar, dirígete a la documentación y comienza.

Motivación

¡Te escuchamos! Una de las preguntas que recibimos con más frecuencia es "¿Puede Astro hacer SSR?"

Cuando nos propusimos construir Astro, decidimos centrarnos en la arquitectura de sitios estáticos preconstruidos popularmente llamada "Jamstack" (también conocida como generación de sitios estáticos o SSG). Este enfoque nos permitió iterar y lanzar nuevas características rápidamente, pero venía con algunas limitaciones importantes:

Los sitios grandes no pueden pre-renderizar a HTML estático sin introducir tiempos de build más largos o un renderizado del lado del cliente más lento del contenido dinámico.
Los sitios dinámicos no pueden pre-renderizar a HTML estático sin obligarte a reconstruir y redesplegar alguna parte de tu sitio cada vez que cambian tus datos.
Los sitios interactivos no pueden pre-renderizar a HTML estático sin mover todos los datos individualizados del usuario al cliente. Los nombres de usuario, avatares y permisos se vuelven más complicados cuando estás tratando con HTML estático preconstruido.

El e-commerce se ve especialmente afectado por los tres problemas anteriores. En una industria donde cada milisegundo de rendimiento de carga cuenta, ¿cómo puedes obtener el increíble rendimiento del HTML estático sin las limitaciones?

Desde el Día 1, supimos que el enfoque de Astro hacia la arquitectura de islas estaba únicamente posicionado para resolver este problema. Las islas permiten que las páginas se carguen rápidamente y se vuelvan interactivas de forma perezosa; el usuario ve y puede interactuar con las partes más importantes de la página, más rápido.

Entra: Renderizado del Lado del Servidor (SSR)

El renderizado del lado del servidor es una solución bien comprendida para escalar sitios web grandes, que se remonta a los primeros días de internet. SSR no es una bala de plata, pero, cuando se hace bien, SSR es una herramienta invaluable para ciertos casos de uso.

Toma la autenticación de usuarios, por ejemplo. Con la generación de sitios estáticos, tienes un par de enfoques diferentes:

Verificar si hay una cookie o JWT en localStorage, y luego redirigir a una página de inicio de sesión si el usuario no tiene una. Si usas una cookie, esto impide usar HttpOnly, exponiéndote a ataques maliciosos de JavaScript.
```
<script>
  if (!parseCookie(document.cookie).auth) {
    window.location = "/login"
  }
</script>
```
Además, ¿qué haces si el token no es válido? Aún necesitas verificar y responder en ese caso.
Llamar a una API que verifique si un usuario ha iniciado sesión, como /api/auth. Ir por este camino significará que necesitas mostrar indicadores de carga en cada una de tus islas mientras esperas la respuesta.
```
function App() {
  const auth = useAuth()
  if (auth.loading) return <AnnoyingLoadingSpinner />
  if (!auth.loggedIn) return <LoginPage />
  return <UserProfile user={auth.user} />
}
```

Sin importar tu enfoque, ir del lado del cliente para la autenticación siempre va a significar:

Las cosas no funcionarán si JavaScript está desactivado.
Tu servidor solo puede responder con códigos de respuesta 200 OK.
Es simplemente lento. El usuario tiene que esperar la respuesta completa de HTML (incluyendo JS, CSS, etc.) incluso si luego es redirigido inmediatamente. Esto crea múltiples solicitudes de página antes de que el usuario llegue a la página correcta.

Astro SSR: Diseñado para ser Simple

Next.js, Nuxt, Gatsby, SvelteKit y toda la pandilla de meta-frameworks modernos de JavaScript ya tienen alguna idea de SSR. ¿Qué hace que Astro SSR sea tan especial?

Astro tiene una ventaja clave sobre el conjunto actual de meta-frameworks centrados en JavaScript que han abordado el SSR antes que nosotros: Astro fue diseñado para ejecutarse en el servidor.

Con Astro eres libre de escribir tu código de servidor como funciona en tu mente, libre de las abstracciones innecesarias que vienen con otros frameworks “universales” centrados en SPA. Aunque el pensamiento centrado en SPA puede ser excelente para aplicaciones web con mucho estado (piensa en dashboards, apps, portales), es un costo que la mayoría de los sitios web centrados en contenido estarían mejor sin pagar.

Así es como funciona la autenticación de usuarios en Astro SSR, usando solo 5 líneas de JavaScript:

---
// In an Astro component (*.astro), you write server code directly
// in the component front matter (this space between the two --- fences).

// 1. Import any dependencies (Full support for JavaScript/TypeScript)
import { getUser } from "../api/index.js"

// 2. Check that the user token exists and is not malicious.
const user = await getUser(Astro.request)

// 3. If no user was found, return a redirect. This instantly
//    completes the response with the correct status code & headers.
if (!user) {
  return Astro.redirect("/login")
}

// 4. If the user is logged in, you can now use the `user` object
//    right in your page template to show an avatar, name, etc.
---

<html>
  ...
  <h1>Hello {user.name} 👋</h1>
  <img src={user.avatar} alt={user.name} />
  ...
</html>

El front matter de Astro es como una única llamada a una función que recibe una solicitud y devuelve una plantilla renderizada. Dado que es una llamada a una función, puedes manejar la solicitud, obtener datos para alimentar la plantilla y salir temprano (como con la redirección) si es necesario.

Rutas de API

El enfoque de Astro de priorizar HTML para el desarrollo web te llevará bastante lejos por sí solo, pero Astro también soporta UI interactiva usando tu framework favorito (como React). Cuando construyes para el cliente, a menudo necesitas endpoints para leer y escribir datos entre el usuario y el servidor. Las rutas de API integradas están aquí para cubrir esa necesidad.

En Astro, una ruta de API es un archivo .js o .ts en la carpeta src/pages/, que recibe una solicitud y devuelve una respuesta. Las rutas de API fueron diseñadas para máxima flexibilidad:

Construye un manejador de envío de formularios para envío de formularios sin JS.
Construye un manejador de subida para envíos de archivos de usuarios.
Construye una API REST basada en JSON para que el cliente se comunique con ella.
Construye una ruta de assets dinámica para devolver cualquier tipo de archivo, incluyendo imágenes y videos.

Las rutas de API funcionan exportando una función que implementa un método HTTP. Aquí hay un ejemplo de ruta de API que guarda un perfil de usuario:

export async function post(params, request) {
  const profile = await request.json()
  await saveProfile(profile)
  return new Response(JSON.stringify({ ok: true }), {
    status: 200,
    headers: {
      "Content-Type": "application/json",
    },
  })
}

Adaptadores: Despliega Astro en Cualquier Lugar

Los hosts web modernos establecen un estándar alto para la experiencia del desarrollador. Los desarrolladores esperan que los frameworks se integren con sus proveedores favoritos, sin demasiada configuración o preparación.

Cuando construimos Astro SSR, evaluamos las diferentes formas en que otros frameworks abordan este problema. Al final, decidimos seguir los pasos de SvelteKit y Remix y adoptar la idea de host conectable adaptadores. Los adaptadores son integraciones simples y conectables que configuran automáticamente tu build para tu host favorito.

El modelo de adaptadores no solo es fácil de configurar para los desarrolladores, sino que también nos permite soportar la mayor cantidad de tipos diferentes de hosts posibles, incluyendo:

Ejecutar completamente en el edge con Cloudflare y Deno Deploy.
Ejecutar en una plataforma de desarrollo moderna como Netlify y Vercel.
Ejecutar en una función serverless bare-metal en AWS, Azure y Google Cloud.
Ejecutar en un runtime de servidor de JavaScript que puedes desplegar tú mismo, como Node.js y Deno.

El soporte de SSR en Astro todavía es experimental. Durante los próximos dos meses, estamos emocionados de trabajar con todos los principales proveedores de hosting para lanzar más adaptadores y alianzas para cada plataforma que les importa a nuestros usuarios. Si eres un proveedor de hosting interesado en construir tu propio adaptador para Astro, comunícate con nosotros en Discord o por correo electrónico: partner@astro.build.

Para celebrar este anuncio, tuvimos la suerte de trabajar con nuestro socio de lanzamiento (y patrocinador oficial de hosting) Netlify, para lanzar un adaptador oficial, desde el primer día, para la plataforma Netlify. El adaptador de Netlify configura tu build de Astro SSR para ejecutarse en Netlify Functions con solo una línea de código:

import { defineConfig } from "astro/config"
import netlify from "@astrojs/netlify/functions"

export default defineConfig({
  adapter: netlify(),
})

Para desplegar, ejecuta tu astro build y luego despliega en Netlify:

Próximos Pasos

El renderizado del lado del servidor está disponible hoy como una API experimental en Astro 1.0 Beta. Esta versión se centra en proporcionar las primitivas de bajo nivel y una base sobre la cual construir.

Para aprender más:

Consulta la documentación para aprender la API de SSR.
Visita nuestro canal de Discord para obtener soporte y contribuir a estabilizar las APIs.
Síguenos en Twitter donde publicaremos más guías sobre SSR más tarde esta semana.