Forem: Emanuel Peire

✨ Los 7 Principios de las Aplicaciones Web Enriquecidas

Emanuel Peire — Sat, 11 Nov 2023 21:29:49 +0000

Introducción:

En el dinámico mundo del desarrollo web, los principios que guían nuestras prácticas evolucionan para mantenerse al ritmo de las nuevas tecnologías y expectativas de los usuarios. Guillermo Rauch, en 2014, delineó siete principios esenciales para las aplicaciones web enriquecidas. A medida que nos adentramos en la era digital de 2024, revisamos estos principios fundamentales, explorando cómo han evolucionado y cómo continúan formando la columna vertebral de las estrategias de desarrollo web modernas, asegurando una experiencia de usuario excepcional y una operatividad eficiente en el vasto ecosistema digital.

1. Páginas Pre-renderizadas: Evolución hacia un Renderizado Óptimo

En 2014, Guillermo Rauch subrayaba la importancia de las páginas pre-renderizadas para las aplicaciones web enriquecidas. Estas páginas, generadas antes de que el usuario acceda a ellas, aseguraban una carga rápida y una experiencia de usuario (UX) fluida. Sin embargo, con el paso del tiempo, el ecosistema web ha evolucionado, y ahora contamos con tecnologías más avanzadas que van más allá del pre-renderizado tradicional.

Evolución del Renderizado Web:

Renderizado del Lado del Servidor (SSR): El SSR ha ganado prominencia, permitiendo que las páginas se rendericen en el servidor antes de ser enviadas al navegador. Esto no solo mejora la velocidad de carga, sino que también beneficia el SEO, ya que los motores de búsqueda pueden indexar el contenido más fácilmente.
Renderizado Estático del Sitio (SSG): El SSG va un paso más allá, generando todas las páginas en tiempo de construcción, lo que resulta en tiempos de carga extremadamente rápidos y una mejor UX.

Frameworks Modernos:

Next.js: Este framework ha liderado la adopción de SSR y SSG, proporcionando herramientas fáciles de usar para implementar estas técnicas.
Otros ejemplos de frameworks web son: Gatsby, Nuxt, Remix, Svelt kit, etc.

Importancia Renovada del Pre-renderizado:
El pre-renderizado sigue siendo relevante, pero ahora en conjunción con SSR y SSG, ofreciendo una experiencia de usuario mejorada y una optimización del rendimiento superior. Estas técnicas modernas de renderizado permiten a las aplicaciones web enriquecidas mantenerse ágiles y eficientes, ajustándose a las expectativas de los usuarios de la era digital actual.

Esta evolución destaca cómo los principios esenciales pueden adaptarse y evolucionar en respuesta a las innovaciones tecnológicas, manteniendo su relevancia y guiando a los desarrolladores hacia mejores prácticas en el desarrollo web.

2. Actuar Inmediatamente ante la Entrada del Usuario: La Esencia de las Microinteracciones

La interactividad es una característica distintiva de las aplicaciones web enriquecidas. La capacidad de una aplicación para responder de manera instantánea a la entrada del usuario no solo mejora la UX, sino que también forma la base para interacciones dinámicas. Guillermo Rauch, en su articulación original del principio, subrayaba la importancia de actuar inmediatamente ante la entrada del usuario.

Microinteracciones: Un Paso Adelante
Las microinteracciones han emergido como una evolución natural de este principio. Son pequeñas, a menudo sutiles, respuestas o animaciones que ocurren en respuesta a la entrada del usuario. Ejemplos comunes incluyen un botón que cambia de color cuando se pasa el ratón sobre él, o una animación suave que indica que se ha enviado un formulario.

Frameworks y Bibliotecas:

React y Vue.js: Estos frameworks modernos facilitan la creación de UIs reactivas que pueden responder instantáneamente a la entrada del usuario.
Bibliotecas de Animación: Bibliotecas como GreenSock Animation Platform (GSAP) y Anime.js permiten a los desarrolladores crear microinteracciones ricas y atractivas.

Hacia una UX Intuitiva y Engaging:
Las microinteracciones contribuyen a una UX más engaging e intuitiva. Proporcionan retroalimentación visual inmediata, lo que ayuda a los usuarios a entender las acciones que han realizado y el estado actual del sistema.

La evolución de este principio refleja un cambio hacia una UX más rica y una interactividad más profunda, subrayando la importancia de las respuestas inmediatas y las microinteracciones en la creación de aplicaciones web modernas y enriquecidas.

3. Reaccionar a los Cambios de Datos: La Dinámica del Flujo de Datos

El tercer principio articulado por Guillermo Rauch, “Reaccionar a los Cambios de Datos”, subraya la importancia de una actualización eficiente y reactiva de la interfaz de usuario (UI) en respuesta a los cambios en los datos. Esta reactividad no solo mejora la UX, sino que también optimiza la gestión de datos en aplicaciones web enriquecidas.

Frameworks Reactivos:

React: Como su nombre indica, React permite una reactividad eficiente, ayudando a los desarrolladores a construir interfaces de usuario dinámicas que responden a los cambios en los datos en tiempo real.
Vue.js: Similar a React, Vue también facilita la construcción de UIs reactivas, proporcionando una arquitectura flexible y potente para manejar el flujo de datos.

Gestión del Estado:
La gestión del estado es crucial para mantener sincronizadas las UIs con los datos. Bibliotecas como Redux y Vuex proporcionan soluciones robustas para manejar el estado de la aplicación, permitiendo una reactividad eficaz.

Comunicación en Tiempo Real:
Las tecnologías como WebSocket y las APIs GraphQL permiten una comunicación en tiempo real entre el cliente y el servidor, facilitando la actualización inmediata de la UI ante cambios en los datos.

Este principio ha ganado más relevancia con el tiempo, ya que la reactividad se ha convertido en una expectativa estándar en el desarrollo web moderno, esencial para proporcionar una UX dinámica y atractiva.

4. Controlar el Intercambio de Datos con el Servidor: Un Pilar para la Performance y la UX

El cuarto principio resalta la importancia de gestionar eficazmente la comunicación entre el cliente y el servidor. Esta gestión optimizada no solo mejora la performance, sino que también asegura una entrega de datos precisa y oportuna, que es crítica para una buena UX.

Avances Tecnológicos:

GraphQL: Esta tecnología permite consultas más eficientes, donde el cliente puede especificar exactamente qué datos necesita del servidor.
APIs RESTful: Aunque no son nuevas, las APIs RESTful bien diseñadas son fundamentales para un intercambio de datos eficaz.

Técnicas de Optimización:

Caching: El almacenamiento en cache de datos reduce la carga en el servidor y mejora la velocidad de respuesta.
Optimización de la Carga de Datos: Técnicas como la paginación y la carga diferida ayudan a gestionar la cantidad de datos transmitidos, mejorando la performance y la UX.

La evolución de este principio refleja la continua innovación en la gestión del intercambio de datos, subrayando la importancia de las tecnologías y técnicas modernas para mantener aplicaciones web enriquecidas eficientes y user-friendly.

5. No Romper la Historia, Mejorarla: Navegación Intuitiva y Cohesiva

El quinto principio aborda la importancia de mantener una gestión coherente del historial de navegación mientras se enriquece la experiencia del usuario.

Navegación en SPA (Single Page Applications):
Las SPA modernas han mejorado la gestión del historial, permitiendo navegaciones intuitivas sin recargar la página.

Técnicas Modernas:

Routing del Lado del Cliente: Herramientas como React Router o Vue Router permiten una gestión eficaz del historial y la navegación.
Historial Mejorado: Las APIs modernas del historial del navegador permiten una gestión más rica y personalizada del historial.

Este principio resalta la necesidad de una navegación intuitiva y una gestión coherente del historial para proporcionar una UX superior, alineada con las expectativas modernas de interactividad y respuesta.

6. Actualizar el Código en Tiempo Real: Evolución Continua y Mejora de la Aplicación

El sexto principio aborda la importancia de actualizar el código en tiempo real para mantener las aplicaciones web enriquecidas optimizadas y al día con las últimas mejoras.

Tecnologías Clave:

Hot Module Replacement (HMR): Facilita la actualización en tiempo real de módulos en aplicaciones en ejecución sin necesidad de una recarga completa.
Service Workers: Permiten actualizaciones de fondo, mejorando la experiencia del usuario al mantener la aplicación actualizada.

Este principio enfatiza una entrega continua y una mejora constante, asegurando que las aplicaciones web enriquecidas sigan siendo relevantes, eficientes y agradable para los usuarios.

7. Predecir el Comportamiento: Inteligencia en la Experiencia del Usuario

El séptimo principio, “Predecir el Comportamiento”, se centra en anticipar las acciones y necesidades del usuario para proporcionar una experiencia de usuario más fluida y satisfactoria.

Tecnologías Emergentes:
Inteligencia Artificial (IA) y Aprendizaje Automático (ML): Permiten analizar patrones de comportamiento de los usuarios y hacer predicciones precisas.

Aplicaciones Prácticas:
Precarga de Datos: Basándose en las predicciones, las aplicaciones pueden precargar datos relevantes, mejorando la rapidez y la UX.
Esta evolución del principio refleja el avance de las tecnologías de IA y ML, y cómo pueden ser utilizadas para enriquecer la experiencia del usuario en las aplicaciones web modernas.

Conclusión:

Navegando la Evolución Tecnológica con Principios Sólidos
Los 7 principios delineados por Guillermo Rauch en 2014 continúan siendo relevantes, pero han evolucionado para alinearse con las innovaciones tecnológicas de la actualidad. Desde el renderizado optimizado hasta la predicción del comportamiento del usuario mediante IA, estos principios adaptados subrayan la dinámica de la tecnología web y la necesidad de mantenerse al tanto de las tendencias emergentes. La reflexión sobre estos principios no solo proporciona una hoja de ruta para el desarrollo de aplicaciones web enriquecidas, sino que también destaca cómo la industria ha avanzado, siempre con el objetivo de mejorar la experiencia del usuario y optimizar la performance.

✨ Next.js 14

Emanuel Peire — Sat, 11 Nov 2023 21:21:05 +0000

Como se anunció en la Next.js Conf, Next.js 14 es una versión más enfocada en:

Turbopack: 5,000 pruebas pasadas para App & Pages Router. Inicio de servidor local un 53% más rápido. Actualizaciones de código un 94% más rápidas con Fast Refresh.
Acciones en el Servidor (Server Actions): Mutaciones mejoradas de forma progresiva. Integrado con caché y revalidación. Llamadas de funciones simples o funciona nativamente con formularios.
Prerenderización Parcial (Experimental): Respuesta estática inicial rápida + contenido dinámico en streaming.
Next.js Learn (Nuevo curso): Curso gratuito que enseña el App Router, autenticación, bases de datos y más.

Actualiza hoy o comienza con:

npx create-next-app@latest

Compilador de Next.js: Turbopack

Desde Next.js 13, se ha estado trabajando arduamente para mejorar el rendimiento del desarrollo local tanto en Next.js en sus páginas como en el App Router.

Anteriormente, se estaba rescribiendo next dev y otras partes de Next.js para respaldar este esfuerzo. Desde entonces, se ha cambiado la aproximación para ser más incremental. Esto significa que el compilador basado en Rust alcanzará la estabilidad pronto, ya que se han centrado en respaldar todas las características de Next.js primero.

5,000 pruebas de integración para next dev están pasando ahora con Turbopack, el motor subyacente en Rust. Estas pruebas incluyen 7 años de correcciones de errores y reproducciones.

Mientras se realizaban pruebas en vercel.com, una gran aplicación de Next.js, se han observado:

53.3% más rápido en cuanto al inicio del servidor local.
94.7% más rápida en cuanto a la actualización de código con Fast Refresh.

Este benchmark es un resultado práctico de las mejoras de rendimiento que deberías esperar con una aplicación grande (y un gráfico de módulos grande). Con un 90% de pruebas para next dev pasando ahora, deberías experimentar un rendimiento más rápido y confiable de manera constante al usar next dev --turbo.

Una vez que alcancen el 100% de pruebas pasando, se movera Turbopack a la versión estable en una próxima versión menor. También se continuarán respaldando el uso de webpack para configuraciones personalizadas y complementos del ecosistema.

Puedes seguir el porcentaje de pruebas pasando en areweturboyet.com.

Forms y Mutations

Next.js 9 introdujo las Rutas de API, una forma de construir rápidamente endpoints de backend junto con tu código frontend.

Por ejemplo, podrías crear un nuevo archivo en el directorio api/:

// pages/api/submit.ts

import type { NextApiRequest, NextApiResponse } from 'next';

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse,
) {
  const data = req.body;
  const id = await createItem(data);
  res.status(200).json({ id });
}

Luego, en el lado del cliente, podrías usar React y un manejador de eventos como onSubmit para hacer una solicitud a tu Ruta de API.

// pages/index.tsx

import { FormEvent } from 'react';

export default function Page() {
  async function onSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();

    const formData = new FormData(event.currentTarget);
    const response = await fetch('/api/submit', {
      method: 'POST',
      body: formData,
    });

    // Handle response if necessary
    const data = await response.json();
    // ...
  }

  return (
    <form onSubmit={onSubmit}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

Ahora, con Next.js 14, se quiere simplificar la experiencia del desarrollador al crear mutaciones de datos. Además, se quiere mejorar la experiencia del usuario cuando este tiene una conexión de red lenta o cuando envía un formulario desde un dispositivo de menor potencia.

Server Actions

¿Y si no necesitaras crear manualmente una Ruta de API? En su lugar, podrías definir una función que se ejecute de manera segura en el servidor, llamada directamente desde tus componentes React.

// app/page.tsx

export default function Page() {
  async function create(formData: FormData) {
    'use server';
    const id = await createItem(formData);
  }

  return (
    <form action={create}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

Las Server Actions deberían resultar familiares para cualquier desarrollador que haya utilizado frameworks centrados en el servidor en el pasado. Está basado en fundamentos web como formularios y la API web FormData.

Si bien usar Server Actions a través de un formulario es útil para la mejora progresiva, no es un requisito. También puedes llamarlas directamente como una función, sin un formulario. Al utilizar TypeScript, esto te proporciona una seguridad de tipos de extremo a extremo entre el cliente y el servidor.

La mutación de datos, la actualización de la página o la redirección pueden ocurrir en una sola solicitud de red, asegurando que se muestren los datos correctos en el cliente, incluso si el proveedor upstream es lento. Además, puedes componer y reutilizar diferentes acciones, incluyendo muchas acciones diferentes en la misma ruta.

Caché, Revalidación, Redirección y Más

Las Server Actions están profundamente integradas en todo el modelo del App Routers. Puedes:

Revalidar datos en caché con revalidatePath() o revalidateTag().
Redireccionar a rutas diferentes a través de redirect().
Establecer y leer cookies a través de cookies().
Manejar actualizaciones optimistas de la interfaz de usuario con useOptimistic().
Capturar y mostrar errores del servidor con useFormState().
Mostrar estados de carga en el cliente con useFormStatus().

Obtén más información sobre Forms y Mutations con Server Actions o sobre el modelo de seguridad y las mejores prácticas para Componentes en el Servidor y Acciones en el Servidor.

Prerenderización Parcial (Partial Pre-rendering)

Se compartió una vista previa del Prerenderización Parcial, una optimización del compilador para contenido dinámico con una respuesta estática inicial rápida, en la que se está trabajando para Next.js.

// app/page.tsx

export default function Page() {
  return (
    <main>
      <header>
        <h1>My Store</h1>
        <Suspense fallback={<CartSkeleton />}>
          <ShoppingCart />
        </Suspense>
      </header>
      <Banner />
      <Suspense fallback={<ProductListSkeleton />}>
        <Recommendations />
      </Suspense>
      <NewProducts />
    </main>
  );
}

Con la Prerenderización Parcial habilitada, esta página genera una estructura estática basada en tus límites de . El fallback de React Suspense se prerrenderiza.

Los fallbacks de Suspense en la estructura estática se reemplazan luego con componentes dinámicos, como la lectura de cookies para determinar el carrito o mostrar un banner basado en el usuario.

Cuando se realiza una solicitud, la estructura HTML estática se sirve de inmediato:

<main>
  <header>
    <h1>My Store</h1>
    <div class="cart-skeleton">
      <!-- Hole -->
    </div>
  </header>
  <div class="banner" />
  <div class="product-list-skeleton">
    <!-- Hole -->
  </div>
  <section class="new-products" />
</main>

Dado que lee cookies para examinar la sesión del usuario, este componente se transmite como parte de la misma solicitud HTTP que la estructura estática. No se necesitan rondas de red adicionales.

// app/cart.tsx

import { cookies } from 'next/headers'

export default function ShoppingCart() {
  const cookieStore = cookies()
  const session = cookieStore.get('session')
  return ...
}

Para tener la estructura estática más granular posible, esto puede requerir agregar límites de Suspense adicionales. Sin embargo, si ya estás utilizando loading.js hoy, este es un límite de Suspense implícito, por lo que no se requerirían cambios para generar la estructura estática.

Próximamente

La prerrenderización parcial está en desarrollo activo. Compartiremos más actualizaciones en una próxima versión menor.

Mejoras en Metadatos
Antes de que el contenido de tu página pueda transmitirse desde el servidor, es importante enviar metadatos sobre la ventana gráfica, el esquema de colores y el tema al navegador primero.

En Next.js 14, hemos separado los metadatos bloqueantes y no bloqueantes. Solo un pequeño subconjunto de opciones de metadatos son bloqueantes, y queremos asegurarnos de que los metadatos no bloqueantes no impidan que una página parcialmente prerrenderizada sirva la estructura estática.

Las siguientes opciones de metadatos ahora están en desuso y se eliminarán de los metadatos en una futura versión principal:

viewport: Establece el zoom inicial y otras propiedades de la ventana gráfica.
colorScheme: Establece los modos admitidos (claro/oscuro) para la ventana gráfica.
themeColor: Establece el color que debería mostrar el cromo alrededor de la ventana gráfica.

A partir de Next.js 14, existen nuevas opciones viewport y generateViewport para reemplazar estas opciones. Todas las demás opciones de metadatos permanecen iguales.

Puedes comenzar a adoptar estas nuevas API hoy. Las opciones de metadatos existentes seguirán funcionando.

✨ Cómo funciona Next.js

Emanuel Peire — Sat, 11 Nov 2023 21:15:15 +0000

Next.js proporciona un marco de trabajo para estructurar tu aplicación y optimizaciones que ayudan tanto en el proceso de desarrollo como en la velocidad de la aplicación final.

En las próximas secciones, veremos lo que sucede con tu código de aplicación en las siguientes etapas:

El entorno en el que se ejecuta tu código: Desarrollo vs. Producción.
Cuándo se ejecuta tu código: Tiempo de compilación vs. Tiempo de ejecución.
Dónde ocurre la representación: Cliente vs. Servidor.

Ahora, profundicemos en estos conceptos y discutamos algunos de los procesos que Next.js realiza en segundo plano.

Entornos de desarrollo y producción

Puedes pensar en los entornos como el contexto en el que se ejecuta tu código.

Durante el desarrollo, estás construyendo y ejecutando la aplicación en tu máquina local. Pasar a producción es el proceso de preparar tu aplicación para ser implementada y consumida por los usuarios.

Cómo se aplica esto a Next.js

Next.js proporciona características tanto para las etapas de desarrollo como para las de producción de una aplicación. Por ejemplo:

En la etapa de desarrollo, Next.js se optimiza para el desarrollador y su experiencia al construir la aplicación. Viene con características que buscan mejorar la Experiencia del Desarrollador, como la integración incorporada de TypeScript y ESLint, Fast Refresh y más.
En la etapa de producción, Next.js se optimiza para los usuarios finales y su experiencia al utilizar la aplicación. Su objetivo es transformar el código para que sea eficiente y accesible.

Dado que cada entorno tiene consideraciones y objetivos diferentes, hay mucho que debe hacerse para llevar una aplicación desde el desarrollo hasta la producción. Por ejemplo, el código de la aplicación debe ser compilado, empaquetado, minimizado y dividido en fragmentos.

El Compilador de Next.js

Next.js se encarga en gran medida de estas transformaciones de código y de la infraestructura subyacente para facilitar que tu aplicación pase a producción.

Esto es posible porque Next.js tiene un compilador escrito en Rust, un lenguaje de programación de bajo nivel, y SWC, una plataforma que se puede utilizar para la compilación, minimización, empaquetado y más.

¿Qué es la Compilación?

Los desarrolladores escriben código en lenguajes más amigables para los desarrolladores, como JSX, TypeScript y versiones modernas de JavaScript. Si bien estos lenguajes mejoran la eficiencia y la confianza de los desarrolladores, deben compilarse a JavaScript antes de que los navegadores puedan entenderlos.

La compilación se refiere al proceso de tomar código en un lenguaje y convertirlo en otro lenguaje o en otra versión de ese lenguaje.

En Next.js, la compilación ocurre durante la etapa de desarrollo a medida que editas tu código y como parte del paso de compilación para preparar tu aplicación para la producción.

¿Qué es la Minificación (Minifying)?

Los desarrolladores escriben código optimizado para que sea legible por los humanos. Este código puede contener información adicional que no es necesaria para que el código se ejecute, como comentarios, espacios, sangrías y múltiples líneas.

La minificación es el proceso de eliminar el formato y los comentarios innecesarios del código sin cambiar la funcionalidad del mismo. El objetivo es mejorar el rendimiento de la aplicación al reducir el tamaño de los archivos.

En Next.js, los archivos de JavaScript y CSS se minifican automáticamente para la producción.

¿Qué es la Agrupación (Bundling)?

Los desarrolladores dividen su aplicación en módulos, componentes y funciones que se pueden utilizar para construir piezas más grandes de su aplicación. Exportar e importar estos módulos internos, así como paquetes externos de terceros, crea una compleja red de dependencias de archivos.

La agrupación (bundling) es el proceso de resolver esta red de dependencias y fusionar (o ‘empaquetar’) los archivos (o módulos) en paquetes optimizados para el navegador, con el objetivo de reducir la cantidad de solicitudes de archivos cuando un usuario visita una página web.

¿Qué es la División de Código (Code Splitting)?

Por lo general, los desarrolladores dividen sus aplicaciones en varias páginas a las que se puede acceder desde diferentes URL. Cada una de estas páginas se convierte en un punto de entrada (entry point) único en la aplicación.

La división de código es el proceso de dividir el paquete de la aplicación en fragmentos más pequeños requeridos por cada punto de entrada. El objetivo es mejorar el tiempo de carga inicial de la aplicación cargando solo el código necesario para ejecutar esa página.

Next.js tiene soporte incorporado para la división de código. Cada archivo dentro de su directorio de páginas (pages/) se dividirá automáticamente en su propio paquete JavaScript durante el paso de compilación.

Además:

Cualquier código compartido entre las páginas también se divide en otro paquete para evitar la descarga repetida del mismo código al navegar a otras páginas.
Después de la carga inicial de la página, Next.js puede comenzar a precargar el código de otras páginas a las que es probable que los usuarios naveguen.
Las importaciones dinámicas son otra forma de dividir manualmente qué código se carga inicialmente.

Tiempo de Compilación (Build Time) y Tiempo de Ejecución (Run Time)

El tiempo de compilación (o paso de compilación) es el nombre dado a una serie de pasos que preparan el código de su aplicación para la producción.

Cuando construye su aplicación, Next.js transformará su código en archivos optimizados para la producción listos para ser implementados en servidores y consumidos por usuarios. Estos archivos incluyen:

Archivos HTML para páginas generadas estáticamente.
Código JavaScript para renderizar páginas en el servidor.
Código JavaScript para hacer que las páginas sean interactivas en el cliente.
Archivos CSS.

El tiempo de ejecución (o tiempo de solicitud) se refiere al período de tiempo en el que su aplicación se ejecuta en respuesta a la solicitud de un usuario, después de que su aplicación haya sido construida e implementada.

Cliente y Servidor

En el contexto de las aplicaciones web, el cliente se refiere al navegador en el dispositivo de un usuario que envía una solicitud a un servidor para obtener el código de su aplicación. Luego, convierte la respuesta que recibe del servidor en una interfaz con la que el usuario puede interactuar.

El servidor se refiere a la computadora en un centro de datos que almacena el código de su aplicación, recibe solicitudes de un cliente, realiza algunos cálculos y envía una respuesta adecuada.

¿Qué es el Renderizado?

Hay una unidad inevitable de trabajo para convertir el código que escribes en React en la representación HTML de tu interfaz de usuario. Este proceso se llama renderizado.

El renderizado puede tener lugar en el servidor o en el cliente. Puede ocurrir de antemano en el momento de la construcción (build time) o en cada solicitud en tiempo de ejecución.

Con Next.js, están disponibles tres tipos de métodos de renderizado: Server-Side Rendering, Static Site Generation y Client-Side Rendering.

Pre-Renderizado

El Server-Side Rendering y la Static Site Generation también se conocen como Pre-Renderizado porque la obtención de datos externos y la transformación de los componentes de React en HTML ocurren antes de que el resultado se envíe al cliente.

Client-Side Rendering vs. Pre-Rendering

En una aplicación React estándar, el navegador recibe una carcasa HTML vacía del servidor junto con las instrucciones de JavaScript para construir la interfaz de usuario. Esto se llama renderizado en el lado del cliente porque el trabajo de renderizado inicial ocurre en el dispositivo del usuario.

Nota: Puedes optar por utilizar el renderizado en el lado del cliente para componentes específicos en tu aplicación Next.js eligiendo recuperar datos con useEffect() de React o un gancho de obtención de datos como useSWR.

En cambio, Next.js pre-renderiza automáticamente cada página. El pre-renderizado significa que el HTML se genera de antemano, en un servidor, en lugar de hacerlo todo con JavaScript en el dispositivo del usuario.

En la práctica, esto significa que para una aplicación completamente renderizada en el lado del cliente, el usuario verá una página en blanco mientras se realiza el trabajo de renderizado. En comparación con una aplicación pre-renderizada, donde el usuario verá el HTML construido:

Discutamos los dos tipos de pre-renderizado:

Server-Side Rendering

Con el renderizado en el lado del servidor, el HTML de la página se genera en un servidor para cada solicitud. El HTML generado, los datos JSON y las instrucciones de JavaScript para hacer que la página sea interactiva se envían al cliente.

En el cliente, se utiliza el HTML para mostrar una página rápida pero no interactiva, mientras que React utiliza los datos JSON e instrucciones de JavaScript para hacer que los componentes sean interactivos (por ejemplo, adjuntar controladores de eventos a un botón). A este proceso se le llama hidratación.

En Next.js, puedes optar por renderizar en el lado del servidor utilizando getServerSideProps.

Nota: React 18 y Next 12 introducen una versión alfa de React server components. Los componentes del servidor se renderizan completamente en el servidor y no requieren JavaScript en el lado del cliente para renderizar. Además, los componentes del servidor permiten a los desarrolladores mantener parte de la lógica en el servidor y solo enviar el resultado de esa lógica al cliente. Esto reduce el tamaño del paquete enviado al cliente y mejora el rendimiento del renderizado en el lado del cliente. Obtén más información sobre los componentes del servidor de React aquí.

Static Site Generation

Con la generación de sitios estáticos, el HTML se genera en el servidor, pero a diferencia del renderizado en el lado del servidor, no hay servidor en tiempo de ejecución. En su lugar, el contenido se genera una sola vez, en el momento de la construcción (build time), cuando se despliega la aplicación, y el HTML se almacena en una CDN y se reutiliza para cada solicitud.

En Next.js, puedes optar por generar páginas de forma estática utilizando getStaticProps.

Nota: Puedes utilizar la “Regeneración Estática Incremental” para crear o actualizar páginas estáticas después de haber construido tu sitio. Esto significa que no tienes que reconstruir todo tu sitio si tus datos cambian.

La belleza de Next.js es que puedes elegir el método de renderizado más apropiado para tu caso de uso en particular, ya sea Generación de Sitio Estático, Renderizado en el Lado del Servidor o Renderizado en el Lado del Cliente. Para obtener más información sobre qué método de renderizado es adecuado para tu caso de uso específico, consulta la documentación sobre la obtención de datos (data fetching).

¿Qué es la Red?

Es útil saber dónde se almacena y se ejecuta el código de tu aplicación una vez que se despliega en la red. Puedes pensar en la red como una serie de computadoras interconectadas (o servidores) capaces de compartir recursos. En el caso de una aplicación Next.js, tu código de aplicación puede distribuirse en servidores de origen, redes de distribución de contenido (CDN) y el borde (Edge). Veamos qué significa cada uno de estos términos:

Servidores de Origen

Como discutimos anteriormente, el término “servidor” se refiere al ordenador principal que almacena y ejecuta la versión original de tu código de aplicación.

Usamos el término “origen” para distinguir este servidor de los otros lugares donde se puede distribuir el código de la aplicación, como los servidores de CDN y los servidores de borde.

Cuando un servidor de origen recibe una solicitud, realiza algunos cálculos antes de enviar una respuesta. El resultado de este trabajo de cálculo se puede mover a un CDN (Red de Distribución de Contenido).

Red de Distribución de Contenido (CDN)

Las CDNs almacenan contenido estático (como archivos HTML e imágenes) en múltiples ubicaciones de todo el mundo y se colocan entre el cliente y el servidor de origen. Cuando llega una nueva solicitud, la ubicación del CDN más cercana al usuario puede responder con el resultado en caché.

Esto reduce la carga en el origen porque el cálculo no tiene que realizarse en cada solicitud. También hace que sea más rápido para el usuario porque la respuesta proviene de una ubicación geográficamente más cercana a ellos.

En Next.js, dado que el pre-renderizado se puede realizar de antemano, las CDNs son adecuadas para almacenar el resultado estático del trabajo, lo que hace que la entrega de contenido sea más rápida.

El Borde (Edge)

El borde es un concepto generalizado para el límite (o borde) de la red, más cercano al usuario. Las CDNs podrían considerarse parte de “el borde” porque almacenan contenido estático en el borde de la red.

Similar a las CDNs, los servidores de borde se distribuyen en múltiples ubicaciones de todo el mundo. Pero a diferencia de las CDNs, que almacenan contenido estático, algunos servidores de borde pueden ejecutar pequeños fragmentos de código.

Esto significa que tanto el almacenamiento en caché como la ejecución de código se pueden realizar en el borde más cercano al usuario.

Al trasladar parte del trabajo que tradicionalmente se realizaba en el lado del cliente o del servidor al borde, puedes hacer que tu aplicación sea más eficiente, ya que reduce la cantidad de código enviado al cliente y parte de la solicitud del usuario no tiene que ir todo el camino de regreso al servidor de origen, lo que reduce la latencia. Consulta ejemplos de uso del borde con Next.js aquí.

En Next.js, puedes ejecutar código en el borde con Middleware y pronto con React Server Components.

✨ Por qué todas las migraciones de aplicaciones deberían ser incrementales

Emanuel Peire — Sat, 11 Nov 2023 21:00:48 +0000

Las migraciones grandes son inevitables, pero no tienen por qué ser dolorosas ni arriesgadas. Descubre por qué migrar de manera incremental es la solución.

En el año 2023, son pocos los proyectos de software que son verdaderamente nuevos desde cero. En su lugar, las migraciones de sistemas existentes son la nueva norma. Las migraciones mal ejecutadas pueden introducir riesgos sustanciales para el negocio y los plazos en cualquier proyecto de software. Una estrategia de migración incremental puede minimizar esos riesgos al tiempo que adelanta la validación del impacto empresarial.

El producto de Vercel está diseñado para admitir la migración incremental desde el principio. En este artículo, obtendrás una visión general de alto nivel de las estrategias y consideraciones de migración incremental.

¿Por qué migrar de manera incremental?

Casi todos los proyectos de software que requieren migraciones deberían apuntar a migraciones incrementales con el fin de:

Minimizar el riesgo al reducir el alcance de los pasos individuales de la migración.
Minimizar el riesgo al tener un camino más natural para retroceder en caso de problemas inesperados.
Permitir la validación de la implementación técnica y el valor empresarial de manera sustancialmente más temprana en el proceso.
Lograr una migración sin tiempo de inactividad y sin ventanas de mantenimiento.

Comprender las migraciones ‘big bang’
Las migraciones ‘big bang’ son migraciones en las que se reemplaza un sistema de una sola vez en un cambio completo. Puede haber pasos intermedios, pero se realizan todos en un período muy corto. Básicamente, eliges una fecha y en esa fecha, todo el uso se traslada del sistema antiguo al nuevo sistema.

Problemas con las migraciones ‘big bang’ pueden incluir:

Puedes pasar por todo el proceso solo para descubrir que hay problemas de producto que son muy costosos de solucionar tan tarde en el programa.
Los ensayos son inherentemente difíciles de ejecutar, lo que dificulta evaluar de antemano si una migración tendrá éxito.
Puedes llegar a un punto de no retorno en el que una migración debe completarse incluso si se notan problemas importantes mientras está en curso.
Puede ser necesario poner fuera de línea el sistema antiguo mientras se realiza la migración, lo que lleva a la pérdida de negocio. Estas ventanas de mantenimiento a menudo se prolongan en duración a medida que se descubren problemas solo durante la ejecución de la migración.

¿Qué es una migración incremental?

Una estrategia de migración incremental implica la transición gradual a un sistema de software nuevo o significativamente actualizado. Durante este proceso, tanto los sistemas antiguos como los nuevos se ejecutan simultáneamente, y las características o usuarios se trasladan en fases en lugar de hacerlo todo de una vez.

Existen dos tipos principales de migraciones incrementales:

1. Vertical: Incrementos por características

En esta estrategia, se cambian subconjuntos de la funcionalidad del sistema al nuevo sistema. Piensa en esto como migrar una característica a la vez, donde ambos sistemas operan en paralelo y la funcionalidad se dirige al sistema nuevo o antiguo según si la característica respectiva ha sido migrada o no.

2. Horizontal: Incrementos por usuario

En las migraciones horizontales, aunque “los usuarios” son comúnmente la unidad principal que se traslada, se pueden usar otras entidades en su lugar. La elección ideal sería una entidad que se pueda dividir o “fragmentar” fácilmente dentro de un sistema, garantizando una interacción mínima entre estos fragmentos separados.

No sería raro ver estrategias de migración incremental verticales y horizontales combinadas en migraciones complejas. En ese caso, verías una migración por usuario en una base por característica.

Compromisos de las migraciones incrementales

El principal compromiso de las migraciones incrementales es la introducción de un esfuerzo adicional para implementar la interoperabilidad entre el sistema nuevo y el antiguo. Esto debe sopesarse frente a la reducción del riesgo y la mayor rapidez en la validación del valor empresarial.

Esto es particularmente desafiante si los sistemas deben acceder a los datos de cada uno. En el caso de una migración incremental horizontal, la elección correcta de la unidad de incremento es la decisión más crucial para minimizar las dependencias de datos. Las entidades comunes donde esto es cierto son un “usuario” o una “organización”.

Migraciones de frontend

Las migraciones de frontend son un caso especial de migración en el que se migra una capa de frontend mientras el backend permanece estable. Las migraciones de frontend suelen ser más fáciles de ejecutar porque los datos con estado siguen siendo gestionados por el mismo “sistema de registro”, y solo se actualiza la representación y el procesamiento de los datos del backend.

Si bien el término “frontend” a veces evoca expectativas de interfaces de usuario y modalidades similares, el principio de la migración en capas se puede extender profundamente en sistemas más grandes: por ejemplo, incluso si se intercambian sistemas enteros, incluyendo sus bases de datos principales, puede ser útil mantener la capa de almacén de datos estable y alimentar datos desde sistemas antiguos y nuevos de manera concurrente.

No cambiar las capas de análisis al mismo tiempo que las aplicaciones tiene el beneficio adicional de mantener un sistema confiable para juzgar el rendimiento del nuevo sistema.

Migración de monolítica a arquitectura componible

Un caso especial de migración de frontend es aquel en el que el sistema antiguo no se descompuso adecuadamente en backend y frontend. Si el objetivo es cambiar a un nuevo frontend, puede ser posible introducir una API en el sistema antiguo de manera que un nuevo frontend se pueda introducir mientras se mantiene el sistema existente como backend.

Lo anterior es común cuando las empresas optan por sistemas monolíticos que acoplan el frontend y el backend en un solo sistema. A medida que estas empresas desean tener más control sobre la interfaz de usuario que presentan a sus usuarios, a menudo introducen frontends separados que tratan al monolito anterior como un servicio de API.

Migración de un frontend web
El elemento clave para la migración incremental de frontends web es el proxy inverso. Los proxies inversos permiten a un servidor web servir contenido desde múltiples servidores web diferentes bajo su dominio principal.

Paso 1: Introducir un proxy inverso sin cambios en la funcionalidad
El primer paso de cualquier migración a una nueva infraestructura de servicio es introducir un proxy inverso que redirige todas las solicitudes a la infraestructura heredada. El proxy inverso puede:

Estar ubicado junto al nuevo frontend (recomendado).
Estar en el frontend antiguo.
Estar en un sistema dedicado introducido específicamente para la migración.

Se recomienda colocar el proxy inverso junto al nuevo frontend porque permite exponer la nueva infraestructura al tráfico de producción sin cambios esperados en el comportamiento.

Las aplicaciones de Vercel vienen con funcionalidad de proxy inverso incorporada para ayudar a implementar estas migraciones. Es importante destacar que el proxy inverso se puede programar a través de Edge Middleware, lo que facilita la implementación de los incrementos de migración y los adaptadores de solicitudes entre sistemas nuevos y heredados.

Cuando se completa esta etapa, la nueva infraestructura está formalmente en producción, pero toda la lógica real la proporciona el sistema heredado. Esperamos que no haya cambios en el comportamiento después del paso 1, por lo que es fácil verificar que esta etapa de la migración fue exitosa.

Paso 2: Comienza a migrar partes del tráfico
Al comienzo del paso 2, el nuevo sistema atiende todo el tráfico, pero no ejecuta la lógica de la aplicación real. Ahora es posible configurar el nuevo sistema para tomar parte del tráfico mientras sigue enrutando todo el otro tráfico al sistema heredado.

Por ejemplo, en una tienda en línea, uno podría comenzar a servir un subconjunto de las páginas de detalles de productos desde el nuevo sistema, mientras que todo lo demás se enruta. Estos incrementos en la funcionalidad se pueden validar paso a paso.

Con el tiempo, un porcentaje cada vez mayor de las páginas son servidas por el nuevo sistema, hasta que eventualmente el 100% del tráfico sea gestionado directamente por el nuevo sistema. En esta etapa, el proxy inverso al sistema heredado puede ser apagado y la migración en términos de efectos visibles para el usuario está completa.

Migraciones de tráfico
Las migraciones de tráfico son un caso especial de migración incremental horizontal.

Actualmente, Vercel se encuentra en medio de una importante migración incremental de su sistema principal de servicio. El equipo ha elegido una estrategia de migración incremental en combinación con lanzamientos oscuros (dark launches). Su objetivo para el nuevo sistema es tener compatibilidad bug-for-bug con el sistema heredado mientras mejora sustancialmente la latencia y el uso de la CPU.

Un lanzamiento oscuro es la introducción de un sistema secundario mientras que un sistema existente continúa sirviendo el tráfico orientado al usuario. En nuestra fase de lanzamiento oscuro, enviamos tráfico tanto al sistema antiguo como al nuevo y comparamos los resultados para validar que se comporten exactamente de la misma manera.

Naturalmente, un lanzamiento oscuro utiliza recursos adicionales (ya que tanto los sistemas antiguos como los nuevos están involucrados en el mismo tráfico, efectivamente duplicando las necesidades de procesamiento). Por lo tanto, es recomendable ejecutar solo un subconjunto del tráfico a través del camino del lanzamiento oscuro.

En Vercel, nuestro plan de implementación incremental se ve así:

Lanzamiento oscuro para X% del tráfico.
Observar diferencias en las respuestas entre el sistema antiguo y el nuevo.
Si es necesario, corregir el comportamiento del nuevo sistema.
Validar que el nuevo sistema, de hecho, mejora la latencia y el uso de la CPU.
Una vez que el lanzamiento oscuro se comporta de manera suficientemente similar al nuevo sistema y se alcanzan los objetivos del nuevo sistema, cambiar el mismo X% del tráfico al nuevo sistema.
Repetir hasta que el 100% del tráfico esté migrado. Hasta la fecha, hemos completado con éxito esta migración y ahora estamos sirviendo el 100% del tráfico en el nuevo sistema.

Resumen

Las migraciones incrementales pueden parecer como un alcance adicional que uno podría desear evitar, pero las organizaciones maduras se dan cuenta de que generalmente valen el esfuerzo. Las migraciones incrementales minimizan el riesgo, mejoran el tiempo para validar el valor empresarial de un cambio y eliminan el tiempo de inactividad planificado.

Las migraciones de frontend son un caso especial de migraciones en las que los sistemas de registro se mantienen iguales mientras se reemplaza el frontend. Las migraciones a Vercel a menudo son de este tipo. Nuestra plataforma proporciona herramientas especializadas para respaldar estas migraciones a través de enrutamiento inverso y una gestión detallada de solicitudes en Edge Middleware.

🚀 Cómo utilizar la Función de Llamada de Open AI con Next.js y el IA SDK de Vercel

Emanuel Peire — Sat, 11 Nov 2023 20:49:53 +0000

¿Qué es la función de llamada de OpenAI?

Para contextualizar, GPT-4 y GPT-3.5 Turbo son Modelos Grandes de Lenguaje (LLM) que han sido entrenados por OpenAI en un vasto corpus de datos de texto. Sobresalen en una amplia gama de tareas de lenguaje, incluyendo la completación de texto, la sumarización e incluso la escritura creativa.

Con la función de llamada, los LLMs ahora pueden recibir definiciones de funciones y generar un objeto JSON con los argumentos necesarios para invocar esas funciones. Esto facilita la integración de las características de GPT con herramientas y APIs externas, permitiendo a los desarrolladores construir experiencias intuitivas impulsadas por la IA aprovechando el poder de los LLMs.

Tipos de flujos de experiencia de usuario para la función de llamada

Hemos identificado tres flujos principales de experiencia de usuario que son esenciales para la nueva API de Llamada de Función de OpenAI:

1- Ejecución Automática de Funciones
Este es el flujo típico de ejecución de llamada de función:

El cliente/usuario envía un mensaje en lenguaje natural.
En el servidor, el IA SDK envía la lista de funciones predefinidas junto con la entrada del usuario a OpenAI, que devuelve el JSON requerido para la llamada de función.
El servidor ejecuta la llamada de función.
El IA SDK envía la salida de la llamada de función a OpenAI y obtiene una salida resumida.
El IA SDK envía la salida al cliente a través del borde.

2- Ejecución Automática de Funciones con Intención y Progreso
Si bien la función todavía se ejecuta automáticamente, este flujo proporciona contexto al usuario sobre la progresión de la función:

El cliente/usuario envía un mensaje en lenguaje natural.
En el servidor, el IA SDK envía la lista de funciones predefinidas junto con la entrada del usuario a OpenAI, que devuelve el JSON requerido para la llamada de función.
El servidor envía una intención al cliente de que habrá una ejecución de llamada de función a través del IA SDK, y procede a ejecutar la llamada de función.
Mientras la llamada de función se está ejecutando, el IA SDK envía el progreso al cliente.
Una vez completada, el IA SDK envía la salida de la llamada de función a OpenAI y obtiene una salida resumida.
El IA SDK envía la salida al cliente a través del edge.

3- Ejecución de Función con Aprobación del Usuario
La función solo se ejecuta con la confirmación del usuario:

El cliente/usuario envía un mensaje en lenguaje natural.
En el servidor, el IA SDK envía la lista de funciones predefinidas junto con la entrada del usuario a OpenAI, que devuelve el JSON requerido para la llamada de función.
El servidor envía una intención al cliente. Si el cliente confirma, el servidor ejecuta la llamada de función.
El SDK de IA envía la salida de la llamada de función a OpenAI y obtiene una salida resumida.
El IA SDK envía la salida al cliente a través del borde.

Casos de uso para la función de llamada de OpenAI

La función de llamada de OpenAI es una herramienta poderosa para construir experiencias de usuario mejoradas con IA.

Aquí hay algunos ejemplos:

1. Análisis y procesamiento de datos en formato libre: En lugar de codificar manualmente complejas expresiones regulares para analizar y procesar datos en formato libre, ahora puedes aprovechar la función de llamada de OpenAI para convertir datos en formato libre en entradas de funciones completamente formateadas y seguras que se pueden usar para realizar operaciones POST/PUT en tu base de datos.

2. Chatbots que interactúan con APIs externas: Con la llamada de función, puedes crear rápidamente chatbots que pueden interactuar con APIs de terceros utilizando lenguaje natural. Esto es similar a cómo funcionan los complementos de ChatGPT; toma el Plugin WeatherGPT, por ejemplo, que convierte una pregunta del usuario sobre el clima en una salida JSON estructurada que se puede enviar a una API de clima de tu elección.

Cómo usar la Función de Llamada de OpenAI

Para aprender más sobre la Función de Llamada de OpenAI, construiremos un chatbot de IA que interactúe con la API de Hacker News en tiempo real utilizando la Función de Llamada de OpenAI y el IA SDK de Vercel.

Si prefieres no empezar desde cero, hemos preparado una plantilla que puedes clonar localmente y utilizar como punto de partida en su lugar.

git clone https://github.com/steven-tey/chathn

Paso 1: Crear una ruta de API para el chat
Primero, crea una ruta de API utilizando el tiempo de ejecución Edge. Podemos usar el ejemplo predeterminado en la documentación del AI SDK por ahora:

// app/api/chat/route.ts

import OpenAI from 'openai';
import { OpenAIStream, StreamingTextResponse } from 'ai';

// Optional, but recommended: run on the edge runtime.
// See https://vercel.com/docs/concepts/functions/edge-functions
export const runtime = 'edge';

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY!,
});

export async function POST(req: Request) {
  // Extract the `messages` from the body of the request
  const { messages } = await req.json();

  // Request the OpenAI API for the response based on the prompt
  const response = await openai.chat.completions.create({
    model: 'gpt-3.5-turbo',
    stream: true,
    messages: messages,
  });

  // Convert the response into a friendly text-stream
  const stream = OpenAIStream(response);

  // Respond with the stream
  return new StreamingTextResponse(stream);
}

Paso 2: Definir tus funciones
Piensa en las funciones como una serie de arrays posibles que se pueden utilizar para interactuar con tu API, similar a las opciones definidas en una especificación de OpenAPI.

A continuación, se muestra un ejemplo de una función que obtiene y devuelve las mejores historias en Hacker News. Puedes consultar la lista completa de funciones en la plantilla ChatHN aquí.

// app/api/chat/functions.ts

import { CompletionCreateParams } from "openai/resources/chat/index";

export const functions: CompletionCreateParams.Function[] = [
  {
    name: "get_top_stories",
    description:
      "Get the top stories from Hacker News. Also returns the Hacker News URL to each story.",
    parameters: {
      type: "object",
      properties: {
        limit: {
          type: "number",
          description: "The number of stories to return. Defaults to 10.",
        },
      },
      required: [],
    },
  },
  ... // more functions
];

async function get_top_stories(limit: number = 10) {
  const response = await fetch(
    "https://hacker-news.firebaseio.com/v0/topstories.json",
  );
  const ids = await response.json();
  const stories = await Promise.all(
    ids.slice(0, limit).map((id: number) => get_story(id)),
  );
  return stories;
}

export async function runFunction(name: string, args: any) {
  switch (name) {
    case "get_top_stories":
      return await get_top_stories();
     ... // more functions
  }
}

Si lo prefieres, puedes colocar el archivo de funciones en el mismo directorio que tu ruta de API, ya que solo el contenido devuelto por page.js o route.js se envía al cliente.

Paso 3: Agregar el mecanismo de llamada de funciones a la ruta de API
Una vez que hayas definido tus funciones, puedes comenzar a agregar la llamada de funciones a la ruta de API que creaste en el Paso 1.

// app/api/chat/route.ts

import OpenAI from 'openai';
import { OpenAIStream, StreamingTextResponse } from 'ai';

// Optional, but recommended: run on the edge runtime.
// See https://vercel.com/docs/concepts/functions/edge-functions
export const runtime = 'edge';

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY!,
});

export async function POST(req: Request) {
  // Extract the `messages` from the body of the request
  const { messages } = await req.json();

  // ---------- NEW CODE STARTS HERE! ----------
  // check if the conversation requires a function call to be made
  const initialResponse = await openai.chat.completions.create({
    model: "gpt-3.5-turbo-0613",
    messages,
    stream: true,
    functions,
    function_call: "auto",
  });

  const stream = OpenAIStream(initialResponse, {
    experimental_onFunctionCall: async (
      { name, arguments: args },
      createFunctionCallMessages,
    ) => {
      const result = await runFunction(name, args);
      const newMessages = createFunctionCallMessages(result);
      return openai.chat.completions.create({
        model: "gpt-3.5-turbo-0613",
        stream: true,
        messages: [...messages, ...newMessages],
      });
    },
  });
  // ---------- NEW CODE ENDS HERE! ----------

  // Respond with the stream
  return new StreamingTextResponse(stream);
}

Paso 4: Conectar la interfaz de chat con el AI SDK
El último paso es conectar la interfaz de chat con el IA SDK de Vercel.

Hemos creado un diseño simple similar a ChatGPT en el repositorio ChatHN que puedes copiar y pegar en tu aplicación.

Una vez que todo esté listo, puedes ejecutar el siguiente comando para iniciar la aplicación:

npm i
npm run dev

Construye una experiencia de usuario con IA con llamada de función y el AI SDK

En resumen, la función de llamada de OpenAI proporciona una forma poderosa de integrar chatbots de IA con APIs de terceros. Al definir funciones y utilizar el SDK de OpenAI, puedes interactuar fácilmente con APIs en tiempo real.

Con el ejemplo proporcionado, puedes crear un chatbot que obtenga las mejores historias de Hacker News y más. Siguiendo los pasos descritos, puedes incorporar la llamada de función en tu ruta de API y conectarla con la interfaz de chat utilizando el SDK de IA de Vercel. A través de este enfoque, tendrás un chatbot que puede interactuar sin problemas con APIs de terceros, mejorando sus capacidades y proporcionando más valor a los usuarios.

🤖 ¿Qué es un Modelo Grande de Lenguaje (LLM)?

Emanuel Peire — Sat, 11 Nov 2023 20:36:02 +0000

Un Modelo Grande de Lenguaje (LLM) es un tipo de inteligencia artificial que puede comprender y generar texto similar al humano basado en los patrones y la información que ha aprendido a partir de vastas cantidades de datos de texto.

Comprendiendo los Modelos Grandes de Lenguaje

Los LLMs están diseñados para tomar una cadena de palabras como entrada y esforzarse por anticipar la secuencia subsiguiente con la mayor probabilidad. Esto se logra asignando valores de probabilidad a posibles secuencias sucesivas y luego optando por una.

Imagina que tienes un amigo robot súper inteligente que ha leído muchos libros y sitios web. Este robot ahora puede hablar y escribir como un humano porque aprendió de toda esa lectura. Puede ayudar a responder preguntas y mantener conversaciones con las personas, entre otras tareas.

Estas tareas incluyen participar en conversaciones con chatbots, traducir idiomas, generar contenido e incluso recuperación y síntesis de conocimiento.

Cómo funcionan los LLMs

Para entender cómo funcionan los LLMs, es esencial comprender su proceso de entrenamiento. El entrenamiento de un LLM implica alimentarlo con datos extensos, como libros, artículos o páginas web. Esto permite que el modelo identifique patrones y conexiones entre palabras y frases.

Una vez entrenado, un LLM puede generar contenido basado en parámetros establecidos por el usuario. Por ejemplo, si alguien desea producir un artículo en el estilo de Shakespeare, proporcionarían una indicación al modelo, y el LLM generaría el resto del artículo basado en su comprensión de las obras de Shakespeare.

Casos de uso para Modelos de Lenguaje Grandes

Aquí hay algunos tipos de aplicaciones que puedes construir con LLMs, junto con algunos ejemplos de plantillas:

1. Chatbots
Al analizar patrones de lenguaje natural, los LLMs pueden generar respuestas similares a las reacciones humanas. Esto es perfecto para empresas que buscan ofrecer servicio al cliente a través de chatbots o agentes virtuales.

2. Recuperación y Síntesis de Conocimiento
Los LLMs también son increíblemente competentes en la síntesis de conocimiento. Por ejemplo, puedes conectar OpenAI a una API de terceros y crear una experiencia de chat impulsada por IA intuitiva que tenga acceso a conjuntos de datos poderosos. Métodos como la Generación con Recuperación Aumentada te permiten agregar un componente de recuperación de información al modelo de generación de texto en el que los LLMs ya son buenos.

3. Generación de Contenido
Los LLMs pueden producir ensayos, artículos u otras formas de contenido que reflejen el estilo de autores o géneros específicos.

4. Ejecución de Tareas
Utilizando las Funciones de OpenAI, puedes agregar fácilmente experiencias de usuario impulsadas por IA a tu aplicación con solo unas pocas líneas de código.

5. Traducción
Modelos como GPT-4 pueden traducir con precisión idiomas, tanto idiomas humanos (inglés, francés, chino) como incluso lenguajes de programación (JavaScript, Python, Rust).

LLMs Populares

Varios LLMs han ganado prominencia en la comunidad de IA:

1- OpenAI GPT
GPT, específicamente GPT-3.5 y GPT-4, son modelos de lenguaje grandes desarrollados por OpenAI.

GPT-3.5: El modelo más rápido y rentable de OpenAI, optimizado para fines de chat, pero también funciona bien para tareas de completado tradicionales.
GPT-4: El modelo más poderoso de OpenAI que posee un amplio conocimiento general y experiencia en dominios, lo que le permite seguir instrucciones complejas en lenguaje natural y resolver problemas difíciles con precisión.

2- Anthropic Claude
Claude, específicamente claude-instant-1 y claude-2, son modelos de lenguaje grandes desarrollados por Anthropic.

claude-instant-1: Una versión más rápida y económica pero aún muy capaz de Claude, que puede manejar una variedad de tareas, incluyendo diálogos informales, análisis de texto, resumen y comprensión de documentos.
claude-2: El modelo más poderoso de Anthropic que sobresale en una amplia gama de tareas, desde diálogos sofisticados y generación de contenido creativo hasta instrucciones detalladas. Es bueno para el razonamiento complejo, la creatividad, el diálogo reflexivo, la programación y la creación de contenido detallado.

3- Cohere Command Nightly
Command Nightly, específicamente command-nightly y command-light-nightly, son modelos de lenguaje grandes desarrollados por Cohere.

command-nightly: Un modelo de conversación que sigue instrucciones de alta calidad y confiabilidad de Cohere, proporcionando un contexto más largo en comparación con modelos generativos.
command-light-nightly: Una versión más pequeña y rápida del modelo de conversación de Cohere con casi la misma capacidad pero una velocidad mejorada.

4- Modelos LLaMA 2 de Meta
LLaMA 2, específicamente llama-2–70b-chat y llama-2–70b, son modelos de lenguaje grandes desarrollados por Meta y alojados en Replicate.

llama-2–70b-chat: Un modelo de 70 mil millones de parámetros ajustado para completar diálogos. Perfecto para construir un chatbot con la mejor precisión.
llama-2–70b: Modelo base de 70 mil millones de parámetros. Perfecto para otros tipos de completados de lenguaje, como completar la escritura de un usuario.

El Futuro de los LLMs

Si bien los LLMs han revolucionado el panorama de la IA, enfrentan desafíos propios. Garantizar la precisión y confiabilidad del contenido que generan es fundamental, especialmente en aplicaciones como la generación de noticias, donde la precisión es crucial. Una forma de mejorar la confiabilidad de los LLMs es conectarlos a fuentes de datos confiables, asegurando que el contenido se alinee con la identidad de marca de una empresa. También existe el Aprendizaje por Reforzamiento a partir de Comentarios Humanos (RLHF), que es un tipo de IA que aprende a tomar mejores decisiones al recibir orientación y correcciones de los humanos.

En conclusión, los Modelos Grandes de Lenguaje están transformando la forma en que interactuamos con las máquinas, ofreciendo interacciones más naturales y parecidas a las humanas. A medida que la tecnología continúa evolucionando, las capacidades y aplicaciones de los LLMs están destinadas a expandirse, abriendo el camino para sistemas de IA más avanzados e intuitivos.