No sabes cómo hacer SSR

Rate this content
Bookmark

Un recorrido por la evolución del SSR en los últimos doce años. Cubriremos cómo han cambiado las técnicas, los problemas típicos, las herramientas que puedes utilizar y diversas soluciones, todo desde el punto de vista de mi experiencia personal como consumidor y mantenedor.

23 min
15 Feb, 2024

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla cubre el viaje personal del orador hacia el renderizado del lado del servidor (SSR) y la evolución de los frameworks de desarrollo web. Explora el uso de jQuery para animaciones en SSR, los desafíos enfrentados al integrar React con Umbraco y la creación de un framework SSR personalizado. La charla también discute los beneficios de Next.js y el uso de artefactos sin servidor para la implementación. Por último, destaca las características de Astro, incluida su capacidad de función por ruta.

Available in English

1. Introducción a SSR y Mi Viaje Personal

Short description:

Hoy les hablaré sobre SSR y mi viaje personal en SSR. Primero, vamos a sumergirnos en ello. Mi nombre es Emanuele Stoppo, soy italiano y vivo en Irlanda. Soy un colaborador principal del proyecto Biome y pertenezco al equipo de plataforma del proyecto Aster. Comenzaremos nuestro viaje hablando sobre este marco de codificación, que es básicamente mi primera experiencia con SSR. Y terminaremos nuestro viaje con Astro. Ahora, ¿qué es el renderizado en el lado del servidor? Es cuando un servidor te proporciona HTML y renderizas una página en tu servidor. Comencemos con mi primera experiencia en 2010 como desarrollador de PHP trabajando con Codingigniter, un marco basado en MVC.

¡Hola a todos! Hoy les hablaré sobre SSR y mi viaje personal en SSR. Vamos a sumergirnos en ello. Primero, las presentaciones en orden. Mi nombre es Emanuele Stoppo, soy italiano, como podrán entender por mi acento, y vivo en Irlanda. Soy un colaborador principal del proyecto Biome y pertenezco al equipo de plataforma del proyecto Aster. También soy un ávido jugador de consola.

Para cuando este video se publique, probablemente estaré jugando Final Fantasy 7. Ahora, comenzaremos nuestro viaje hablando sobre este marco de codificación, que es básicamente mi primera experiencia con SSR. Y terminaremos nuestro viaje con Astro. Ahí es donde las cosas se pondrán interesantes. Ya verán por qué.

Primero que nada, ¿qué es el renderizado en el lado del servidor? La cosa es que ha cambiado a lo largo de los años. Cuando comencé, el renderizado en el lado del servidor era la forma en que se creaban los sitios web. Así es como se hacían. Pero luego llegó Node.js, nuevos patrones, nuevas posibilidades, nuevas herramientas, y así sucesivamente. Las cosas cambiaron, nuevos patrones, y demás. Básicamente, es cuando un servidor te proporciona HTML y tú se lo das a tu cliente. Así que renderizas una página en tu servidor y eso es todo. Muy básico, ¿verdad? Ahora entendemos qué es SSR.

Comencemos con mi primera experiencia. Fue en 2010, justo después de salir de la universidad. PHP fue mi primera experiencia. Era un desarrollador de PHP. Tuve la oportunidad de trabajar con Codingigniter, que es un marco basado en MVC, que significa Modelo-Vista-Controlador. Solo para darles una idea de qué es este patrón. Básicamente, tienes tu propia clase, que es el controlador que tiene toda la lógica de negocio de tu página. Luego tienes el modelo. El modelo es generalmente esa entidad que se encarga de todo lo relacionado con tus datos.

2. Operaciones CRUD, Lenguajes de Plantillas y jQuery

Short description:

Entonces, las operaciones CRUD. Validaciones y demás. Se conecta con la base de datos y se comunica con la base de datos. Luego, tienes la vista. Puedes tener múltiples vistas o reutilizar todas las vistas. La vista suele ser un lenguaje de plantillas. jQuery llegó como una revolución. Es cómo aprendí JavaScript. Aquí tienes un ejemplo de cómo lo usé con SSR. Teníamos requisitos para animaciones sin salir de la página del usuario. Así que creamos un nuevo punto final con un modelo de controlador vista y mostramos solo el HTML deseado.

Entonces, las operaciones CRUD. Validaciones y demás. Se conecta con la base de datos y se comunica con la base de datos. Y luego tienes la vista. Entonces, la vista generalmente, la llamas dentro de tu controlador. También puedes tener múltiples vistas o reutilizar todas las vistas. Y la vista, generalmente es un lenguaje de plantillas. Este es un ejemplo de un lenguaje de plantillas. Si usas, por ejemplo, Vue y Svelte, ya sabes qué es un lenguaje de plantillas. Y así es como solía hacerlo en aquel entonces. No ha cambiado mucho. Como con Vue y Svelte, tienen una sintaxis diferente. Pero, quiero decir, el concepto. Es el mismo. Interpolamos el lenguaje de plantillas con las variables. Generamos HTML y se lo damos al navegador. Eso es lo que hice al principio. Así es como empecé.

Y luego llegó jQuery. jQuery fue una revolución en ese momento. Es cómo aprendí JavaScript. Y aquí tienes un ejemplo de cómo lo usé con SSR. Así que tenía mi jQuery. Y había otro marco de MVC que se llama Grails. Grails se basa en este lenguaje llamado Groovy. Se compila en JVM. Como dije, sigue siendo un MVC. Y lo que hice fue básicamente que teníamos algunos requisitos donde queríamos tener algunas animaciones sin salir de la página del usuario. Entonces, lo que solías hacer en ese momento era crear un nuevo punto final con un modelo de controlador vista. Específicamente, para estas necesidades, generabas solo el HTML que deseabas tener.

3. jQuery, Central Touch y React

Short description:

Con jQuery, podías reemplazar un HTML por otro utilizando animaciones. La representación del lado del cliente era realmente interesante. Yo estaba a cargo de los controladores y las vistas. Luego tenemos Central Touch, un marco móvil todo en uno para aplicaciones web. No generó mucho interés. Luego llegó React con características refrescantes. Quería usarlo, pero había un pero. Mi gerente dijo, vamos a usarlo.

Y luego con jQuery, simplemente haces un get. Obtienes tu HTML y luego haces animaciones y así sucesivamente. Entonces, con jQuery, podías reemplazar un HTML por otro utilizando animaciones. Y así es como era la representación del lado del cliente en aquel entonces. Fue realmente... Sí, quiero decir, al final, podías hacer todas tus estrategias y cosas así. Pero así fue como pude jugar con este tipo de cosas. Fue realmente, realmente interesante. Y también estaba a cargo de los controladores y las vistas. Así que simplemente podía ir allí en el marco, crear un nuevo controlador, hacer parámetros, y fue realmente divertido en ese momento.

Luego tenemos Central Touch. No voy a molestarte con Central Touch. Esencialmente, es un marco móvil todo en uno para construir aplicaciones web. Tienes tus tiendas, tienes tus componentes, vistas, modelos y todo. Pero no despertó mucho interés. Fue unos años antes de que llegara React. Fue realmente aburrido. No es que... Quiero decir, aprendí muchas cosas, pero básicamente estabas encerrado en el marco. Y ahora es donde empezamos a obtener cosas interesantes. Sí. Luego llegó React y tenía características realmente agradables. Y algunas de estas características eran realmente refrescantes. Y quería usarlas. ¿Verdad? Así que, sí. Pero, no. Siempre hay un pero. Así que tenía este proyecto. Quería usar mucho React. Y mi gerente dijo, vamos a usarlo.

4. Using React with Umbraco

Short description:

En un mundo empresarial con restricciones, el sitio web estaba impulsado por Umbraco, similar a WordPress. Pero yo quería usar React. Así que escribí mi propio marco de SSL y seguí tres principios. Se utilizaron Go Blast state manager y Redux. Node.js fue el tiempo de ejecución.

Pero aún así, estamos en un mundo empresarial, por lo que las cosas no son perfectas. En este proyecto, había algunas restricciones. Por lo tanto, el sitio web estaba impulsado por un marco de Microsoft.NET. Específicamente, un CMS llamado Umbraco. Y parecía ser como un WordPress. Tienes tu oficina de respaldo. Puedes personalizarlo. Pero también, el sitio web es proporcionado. El sitio web real es renderizado por WordPress. Lo mismo ocurre con Umbraco. Entonces... Pero yo quería usar React. Entonces... ¿Cómo lo hice? Bueno... Sí, escribí mi propio marco de SSL. Y, sí. Como tú... Sí, es un meme. Pero, quiero decir, eso es cierto. Pero lo que pasa es que en ese momento no había frameworks para hacer eso. Ni siquiera en .NET. Quiero decir, estaba escribiendo en terreno desconocido en ese momento. Así que tuve que idear algo. Bueno, lo que pasa es que escribir tu propio marco de SSL no es tan difícil. En realidad, es más fácil de lo que piensas. Solo hay, como, tres principios que debes seguir. Entonces, debes tener un Go Blast state manager. En ese momento, Redux era el lugar al que ir. Necesitas tener un tiempo de ejecución. Entonces, en ese momento, Node.js era la opción a seguir.

5. Creating an SSL Framework

Short description:

No podías extenderlo por todas partes. Una vez que tengas estas tres cosas, puedes tener tu propio marco de SSL. Tenía un marco .NET con un motor de plantillas. Una biblioteca permitía pasar un marco de React para obtener el HTML real en tiempo de ejecución. Los fundamentos para crear tu propio marco de SSL implican conectar estos fundamentos utilizando bibliotecas disponibles.

No podías extenderlo por todas partes. Simplemente lo ejecutas y te da lo que necesitas usando un script. Y luego, simplemente accedes a la página.

Entonces, una vez que tengas estas tres cosas, puedes tener tu propio marco de SSL. Veamos brevemente lo que hice en ese momento. Tenía un marco .NET. Había un motor de plantillas, como vimos antes. Por lo general, accedes a una página y tienes tu propio estado global de Redux. Ese es un objeto global. Y, básicamente, para cada página, inyectas el estado global inicial de tu página. ¿De acuerdo?

Luego, debes tener este runtime. Afortunadamente, en ese momento, existía esta biblioteca que te permitía pasar un marco de React. Y era capaz de darte el HTML real. Era, como, en tiempo de ejecución dentro del motor de plantillas. Era realmente rápido. No había ninguna sobrecarga, incluso porque, por lo general, las páginas que contienen componentes de React eran realmente pequeñas. Entonces, no necesitábamos renderizar toda la página. ¿De acuerdo? Teníamos páginas donde teníamos, como, un componente de React aquí o un componente de React allá. Entonces, era una mezcla de HTML estático y componentes de React. Una vez que tienes este HTML, lo tienes en tu motor de plantillas. Y al final, volvemos a nuestra página. Necesitamos obtener realmente el ID donde se renderizó el componente de React e iterarlo. Como puedes ver, no es tan difícil. Estos son los fundamentos para crear tu propio marco de SSL. Y luego solo necesitas conectar estos fundamentos utilizando las bibliotecas que tienes. Y el trabajo está hecho. No es ciencia espacial. De hecho, estaba realmente orgulloso de ese trabajo. Y fui a verificarlo. Este webpack todavía utiliza la misma lógica.

6. Introducción a Next.js y Restricciones Empresariales

Short description:

Esa fue una elección realmente buena. Next.js es un gran marco de trabajo que facilitó la vida con GetStaticProps. Sin embargo, las restricciones empresariales plantearon desafíos ya que nuestro backend solo utilizaba lambdas. La versión inicial del sitio web fue penalizada negativamente para SEO.

Entonces, quiero decir, esa fue una elección realmente buena. Claro, las cosas han cambiado. Pero aún funciona. De acuerdo.

Ahora vamos con un enfoque más moderno. Y ahí es donde entra en juego Next.js. Sí, también trabajé con Next.js. Es un marco de trabajo realmente genial. Y con GetStaticProps, la vida fue mucho, mucho más fácil. Como, GetStaticProps eliminó una gran parte de la red que expliqué, porque eso es lo que Next.js hacía en ese momento. Entonces, crea tu propio estado global y demás. Pero Next.js también tiene más, como enrutamiento progresivo del lado del cliente y otras cosas. Es un marco de trabajo realmente bueno. De hecho, lo es. Pero, ya sabes, la empresa es diferente, sí. Entonces, en ese momento, teníamos restricciones realmente extrañas.

Entonces, nuestro backend no tenía ningún servidor en absoluto. Pero solo podíamos usar lambdas. Como, el backend estaba utilizando lambdas. Y para ellos, era genial. Pero para nosotros, eso fue bastante desafiante. La versión inicial del sitio web fue SPAS. Entonces, teníamos una página HTML. Estudiamos JavaScript. Y así, no. No. CreateRectApp. Entonces, fue un fork de CreateRectApp. Pero el SEO del sitio web fue penalizado negativamente.

7. Exportando Páginas como Artefactos Serverless

Short description:

Next.js introdujo la opción de exportar cada página como un artefacto serverless. Construí mi propia capa de implementación, un metaframework, que se conectaba a la construcción serverless de Next.js. Esto nos permitió crear lambdas para cada página, implementarlos y tener navegación del lado del cliente. La capa compacta traducía el evento pasado desde la lambda a la página de artefacto.

Entonces, tuvimos que hacer algo. En ese momento, Next.js introdujo una nueva opción llamada salida serverless, o algo así. Y permitiría exportar cada página como un artefacto serverless. No una lambda, un artefacto serverless. Y fue genial para nosotros. Fue genial.

Entonces, ¿qué hicieron? Bueno. Adivina qué. Construí mi propia capa de implementación. Es como si hubiera construido mi propio metaframework. Exactamente eso. Y fue realmente, realmente divertido.

Ahora, veamos qué hice. Muy bien. Entonces, Next.js, como dije antes, crea este artefacto para cada página. Muy bien. Luego, mi metaframework se conecta esencialmente a la construcción serverless de Next.js. Entonces, programáticamente, ejecutamos la construcción. Esta construcción me proporciona toda la información necesaria para crear una lambda para cada página. Al final de la construcción, teníamos todas estas lambdas que podíamos implementar en los diferentes entornos, ejecutarlas en cada solicitud y obtener solo la página que solicitamos, y tener navegación del lado del cliente desde allí. Y así es como Next.js solía funcionar en ese momento.

Entonces, esta lambda, en realidad, no es solo una lambda. Así que fui más allá. De acuerdo. En realidad, hay una lambda real construida dinámicamente. Luego teníamos la capa compacta. Una capa compacta que toma el evento pasado desde la lambda y crea una solicitud de respuesta. Y estas solicitudes de respuesta se pasaban a la página de artefacto. Porque el artefacto no era, como dije antes, compatible con AWS lambda. Solo toma, como, una solicitud entrante similar a Node.js. Entonces, necesitábamos una capa compacta para traducir esta información.

8. La Capa Compacta, Terraform y Astro

Short description:

Necesitábamos una capa compacta para traducir la información. Todo lo que hice de código abierto ahora está archivado. Eventualmente, llegamos a Astro, donde SSG es SSR con un paso adicional. Astro tiene una forma genérica de exportar páginas y los adaptadores pueden manipular los artefactos según los requisitos. Además, creé características específicas en Astro, como función por ruta.

Entonces, necesitábamos una capa compacta para traducir esta información. Y luego teníamos las fuentes de Terraform. Entonces, el marco beta creaba dinámicamente todos los archivos de Terraform que luego se llamaban al final de la construcción.

Entonces, eventualmente, ¿qué hice? Todo lo que hice de código abierto. Tomé toda la lógica que construí para la empresa. Solo agregué una CLI al frente con algunas opciones. Y, sí, quiero decir, pensé que había hecho algo genial. Quiero decir, seguro, es un caso muy específico lo que tengo. Pero tal vez alguien más esté enfrentando el mismo problema. Así que lo hice de código abierto. Pero ahora está archivado porque Next.js eliminó la opción serverless. Entonces, quiero decir, ya no podemos usarlo. Y eventualmente, llegamos a Astro. Entonces, trabajo en Astro y en realidad construí algunas cosas interesantes que te voy a mostrar. Pero antes de eso, voy a revelar algunos secretos sobre Astro. Entonces, conoces sobre SSG, generación de sitios estáticos o sitios web estáticos. ¿Pero sabes que en realidad SSG en Astro es SSR con un paso adicional? Sí, porque cuando lo construimos, en realidad ejecutamos SSR.

Creamos todas estas páginas, como archivos de artefactos correctos. Los importamos, los ejecutamos y luego fueron como una respuesta solicitada cuando obtenemos su respuesta, el HTML, y lo renderizamos. Y los ponemos en un archivo HTML. Así que es SSR en todas partes, ¿sabes? Pero entonces, ¿qué es SSR en Astro? Bueno, en realidad es SSR con un paso de construcción diferente. Entonces, solo tenemos una configuración diferente y emitimos estos artefactos de una manera diferente, de manera genérica. Entonces, los adaptadores realmente pueden consumirlos y construirlos, en realidad, como prefieran. Entonces, tenemos una forma genérica de exportar y también una interfaz para exportar las páginas de las rutas, llamémoslas así.

Y luego los adaptadores, como Node.js, Deno, Vercel, Cloudflare, Netlify, y así sucesivamente, que tienen diferentes requisitos, pueden tomar estos artefactos, manipularlos si es necesario, y crear sus propias configuraciones basadas en sus necesidades. Es como lo que hice antes, como con el metaframework. Esencialmente, eso es lo que hace Astro. Pero hay más. Recientemente, creé un par de características específicas, realmente buenas, en Astro, utilizando SSR y varias otras herramientas.

9. Astro's Function per Route

Short description:

La función por ruta de Astro permite múltiples puntos de entrada y es útil para páginas pesadas con mucho código.

Una de ellas es la función por ruta. Entonces, ¿qué significa esto? Por defecto, así es como se ve SSR en Astro. Tenemos un solo archivo que maneja todas tus rutas. Entonces, cuando golpeamos y cuando el servidor, en realidad el cliente, solicita una ruta, lo que hacemos es importar dinámicamente el artefacto que pertenece a esa página y devolver su respuesta. En cambio, con la función por ruta, tenemos múltiples puntos de entrada. Entonces, es realmente un caso específico. Nadie necesita algo así. Pero si tienes páginas realmente pesadas con mucho código, mucho JavaScript, a veces este caso de uso puede ayudarte, porque esencialmente es como dividir el código en la plataforma serverless. De acuerdo. Otra cosa increíble es el Middleware de Edge. Hace unos meses, lancé y desarrollé, y lanzamos el Middleware de Astro, y unos meses después, agregamos el Middleware de Edge que se puede usar en plataformas como AWS, Vercel, y así sucesivamente. Así es como funciona el Middleware de Astro. Tienes tu solicitud, pasa a través del Middleware. Tenemos estos Locals de Astro que básicamente son información data que puedes pasar a tu componente de Astro. Puede ser cualquier cosa, es un objeto, y también puedes pasar funciones. Y los usas para renderizar tu componente, o tal vez no. Y finalmente, obtienes una respuesta. En Edge, esto es un poco diferente, pero logramos usar el mismo Middleware y hacer que funcione. Entonces, todo comienza desde la solicitud. Generamos esta función de Edge. Por lo general, el Middleware de Edge es una función de Edge, que está muy cerca del usuario, por eso se llama Edge. Y esta función de Edge llama al Middleware de Astro real. Pero luego, necesitamos renderizar el componente de Astro. Entonces, ¿cómo lo hacemos? Esto depende de la plataforma. En Vercel, en realidad tienes una función Next, pero también en Netify, por ejemplo, puedes llamar a Next. O en realidad, en Vercel, puedes hacer una llamada fetch al origen. Entonces, el origen es el archivo real que renderiza tu página, tu componente, cualquier cosa que devuelva algo de HTML. Y como dije antes, en Vercel, dentro de la función de Edge, creamos una función Next. ¿Qué hace esta función? En realidad, hace una llamada fetch al origen, y cuando hacemos la llamada fetch, pasamos estos locals. Entonces, estos locals, como dije antes, en este caso, se serializan y se pasan a través de encabezados al componente de Astro, y luego eventualmente se pueden usar. Y todo se hace usando Rollup y Vite. Hay un error tipográfico. Disculpa por eso. Muchas gracias. Espero que hayas disfrutado mi viaje. Y adiós. Adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Summit 2023React Summit 2023
27 min
The New Next.js App Router
Next.js 13.4 recently released the stable version of the "App Router" – a transformative shift for the core of the framework. In this talk, I'll share why we made this change, the key concepts to know, and why I'm excited about the future of React.
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.
React Advanced Conference 2023React Advanced Conference 2023
23 min
Opt in Design – The New Era of React Frameworks
Picking up a new technology, developers stick with defaults. It's a fact that every tool from JQuery to NextJS has needed to face. At their worst, defaults ship hundreds of wasted JS kilobytes for routing, state, and other baggage developers may never use. But at their best, defaults give us a simple baseline to start from, with a clear path to add the exact set of features our project demands. This is the magic of opt-in design.
Let's see how smart defaults guide modern frontend tools from Astro to React Server Components, and why this new era reshapes your workflow, and performance metrics, for the better.
React Day Berlin 2023React Day Berlin 2023
28 min
All Things Astro
Astro 3 was released a while ago and brought some amazing new features with it. In this talk, we’ll take a look at some of the newly released features in Astro 3, do some live coding and have some fun. We can take a look at what’s coming next in Astro 4 and there also might be a 'one more thing

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit 2023React Summit 2023
139 min
Create a Visually Editable Next.js Website Using React Bricks, With Blog and E-commerce
WorkshopFree
- React Bricks: why we built it, what it is and how it works- Create a free account- Create a new project with Next.js and Tailwind- Explore the directory structure- Anatomy of a Brick- Create a new Brick (Text-Image)- Add a title and description with RichText visual editing- Add an Image with visual editing- Add Sidebar controls to edit props (padding and image side)- Nesting Bricks using the Repeater component- Create an Image gallery brick- Publish on Netlify or Vercel- Page Types and Custom fields- Access Page meta values- Internationalization- How to reuse content across pages: Stories and Embeds- How to create an E-commerce with Products’ data from an external database and landing pages created visually in React Bricks- Advanced enterprise features: flexible permissions, locked structure, custom visual components
React Summit 2023React Summit 2023
71 min
Building Blazing-Fast Websites with Next.js and Sanity.io
WorkshopFree
Join us for a hands-on workshop where we'll show you how to level up your React skills to build a high-performance headless website using Next.js, Sanity, and the JAMstack architecture. No prior knowledge of Next.js or Sanity is required, making this workshop ideal for anyone familiar with React who wants to learn more about building dynamic, responsive websites.
In this workshop, we'll explore how Next.js, a React-based framework, can be used to build a static website with server-side rendering and dynamic routing. You'll learn how to use Sanity as a headless CMS to manage your website’s content, create custom page templates with Next.js, use APIs to integrate with the CMS, and deploy your website to production with Vercel.
By the end of this workshop, you will have a solid understanding of how Next.js and Sanity.io can be used together to create a high-performance, scalable, and flexible website.
React Day Berlin 2023React Day Berlin 2023
119 min
Crash course into Astro and Storyblok
WorkshopFree
Headless architecture has gained immense popularity in recent years for its ability to decouple the frontend and backend, empowering developers to create engaging, interactive, and scalable web applications. 
In this workshop, we will quickly take a dive into the Headless World and Architecture. 
Additionally, we will build a blog website super quickly using Storyblok, a headless CMS that offers a real-time preview feature with nestable component approach, and Astro (3.0) which is already creating a buzz with the new app directory. 
- Master headless CMS fundamentals- Master an Astro & headless CMS approach- Use Atomic design in your Astro & Storyblok application- Creating pages, adding content and understanding how the dynamic routing works with headless