Primero, vamos a entender qué es una base de conocimientos y por qué elegimos una base de conocimientos en lugar de un blog normal o un sitio web de noticias o algo así. Una base de conocimientos es una biblioteca en línea de autoservicio. Es un lugar donde se almacenan todos los datos y el conocimiento, todo lo que tienes, ya sea para ayudar a los miembros del equipo o a los clientes.
Por ejemplo, si eres una empresa y quieres tener un lugar donde los nuevos empleados puedan ingresar cuando se unan y entender cómo funciona el proceso de incorporación, cómo funciona la comunicación, o algo así, puedes tener una base de conocimientos en su lugar. Si eres una empresa que brinda servicios a clientes y quieres documentar todo lo que deseas en un solo lugar, en lugar de que todos tengan preguntas y pidan servicio al cliente, simplemente puedes crear una base de conocimientos o un centro de ayuda o un lugar donde puedas hacer doble clic en una página y puedes poner todas las preguntas frecuentes y artículos y puedes ponerlos en categorías y cosas así o guías de solución de problemas. Y sí, el cliente o los miembros del equipo simplemente se unirían, ingresarían y encontrarían la respuesta correcta a la pregunta en lugar de molestarte con múltiples preguntas.
Hoy vamos a construir una página de inicio, una página de categorías y una página para cada categoría, y para cada categoría tendremos una serie de artículos que también tendrán una página de contenido enriquecido.
Primero, hablemos de cómo se renderizan los sitios web, porque el concepto de los generadores de sitios estáticos es muy nuevo, o no nuevo, pero mucha gente no sabe cómo funcionan los generadores de sitios estáticos. Así que vamos a empezar desde el principio. ¿Cómo se renderizan los sitios web? Al principio, cuando salió Internet, solo había una forma de renderizar los sitios web, así que se llamaba renderización en el lado del servidor. Bueno, no había un nombre porque era la única forma de hacerlo, donde tienes un servidor y el cliente o el usuario escribe la URL en el navegador y luego envía una solicitud HTTP a un servidor, que hace la magia, genera una página HTML completa con todo lo que necesitarías, y luego lo envía de vuelta al navegador donde el navegador pegaría el HTML y lo renderizaría en el navegador.
Y luego, cada vez que quieres cambiar a otra página, como si estás en la página de inicio y quieres ir a la ayuda o algo así, harías clic en un enlace, en una etiqueta a, que enviaría otra solicitud HTTP, obtendría todo el HTML del servidor y luego reemplazaría todo con este nuevo HTML. El servidor utiliza plantillas para generar dinámicamente páginas HTML completas. Por ejemplo, si tienes un sitio web PHP y envías una solicitud GET a esta página, se manejará y luego se colocarán todas las variables o los datos reales en una plantilla HTML y luego se enviará de vuelta al navegador.
Y después de un tiempo, surgió un nuevo concepto llamado renderización en el lado del cliente. Surgió generalmente con aplicaciones de una sola página o con la generación de envío de solicitudes de API. Aún tienes un cliente y un servidor y luego envías la primera llamada de API al servidor y luego obtienes una página HTML vacía con un montón de scripts de JavaScript adjuntos a ella y luego el cliente o el navegador lo tomaría y daría el control de JavaScript para obtener todo lo que necesitas del servidor con solicitudes de API y luego manipular directamente el DOM o el HTML en la página. Así que en lugar de tener todo enviado de vuelta como antes, ahora obtienes una página HTML de marcador de posición muy vacía que no tiene nada significativo, solo un montón de scripts y luego estos scripts se hacen cargo y generan el HTML real.
Como puedes ver aquí, el cliente renderiza la página vacía y JavaScript renderiza el contenido más tarde. Y si lo miras desde algunos aspectos como el tiempo de renderización, el tiempo de renderización aquí es inconsistente porque el cliente es en realidad el que hace el trabajo real, mientras que con múltiples clientes hay múltiples rendimientos, como si tienes una PC de alta gama es diferente a tener un teléfono móvil de gama muy baja. Y para el SEO, la optimización de motores de búsqueda, fue muy mala cuando salió porque los rastreadores antes de esto, como el rastreador de motores de búsqueda y los rastreadores son como un montón de scripts que los motores de búsqueda utilizan para rastrear la web y archivar sus datos para que cuando busques algo lo tengas todo allí. Entonces, el rastreador iría a un enlace y obtendría una página HTML vacía y no encontraría contenido significativo en ella y de esta manera obtendrías una página vacía que no se archivaría o sería muy mala para el ranking de SEO. Después de un tiempo, muchos rastreadores o muchos motores de búsqueda se adaptaron, pero no fue tan rápido y no funcionaba al 100% hasta hace poco, supongo. El tiempo de compilación fue muy rápido y el almacenamiento en caché solo ocurría en el lado del cliente porque sí, como solo obtienes la misma página cada vez, no hay almacenamiento en caché que pueda ocurrir, pero el cliente estaba almacenando en caché las solicitudes de API en el cliente, depende de cómo lo configures, por supuesto, pero normalmente lo almacenaría en caché pero no lo haría. Y para solucionar este problema, principalmente con el SEO, surgió un nuevo concepto que es una mezcla de la primera cosa, que es la renderización en el lado del servidor y la segunda cosa, la renderización en el lado del cliente. Entonces, para aplicaciones de una sola página, cada vez que envías la primera llamada de API, lo siento, la primera solicitud HTTP en lugar de tener una página HTML muy vacía enviada a ti, tendrías como que el servidor haría la primera renderización como si estuviera sucediendo en el cliente y luego te enviaría la página HTML completa donde el cliente la renderizaría y luego sucedería algo llamado rehidratación donde rehidratarías el estado y funcionarías como una aplicación de una sola página normal. Entonces, JavaScript aún se haría cargo, pero de esta manera, si un rastreador de motores de búsqueda entra en una página como esta, obtendrías todo lo que necesita desde el primer momento, algo diferente. Algunos aspectos de esto son que el tiempo de renderización era lento, por supuesto, más lento porque el servidor aún generaría el HTML o como renderizaría la primera renderización en el tiempo de ejecución, pero esto solucionó el problema porque el rastreador obtendría la página HTML completa. El tiempo de compilación fue rápido porque sí, sigue siendo igual que el de la renderización en el lado del cliente y el almacenamiento en caché se podía hacer en esta etapa utilizando un tercero como Cloudflare y algunos frameworks lo agregaron más tarde, pero no está ahí de serie. Y esto estuvo bien hasta que los sitios web impulsados por contenido se hicieron muy famosos.
Entonces, ¿qué es un sitio web impulsado por contenido? Un sitio web impulsado por contenido es cualquier sitio web en el que principalmente el objetivo principal sea proporcionar contenido en lugar de tener muchas tareas en él. No es un panel de control o una aplicación de redes sociales, no es una aplicación web, sino un sitio web que tiene mucho contenido que principalmente es texto enriquecido, como imágenes y cosas así, como un blog, un sitio web de noticias, un sitio web de una empresa, sitios web de marketing o una base de conocimientos.
Cuando los sitios web impulsados por contenido tuvieron los generadores de sitios estáticos, surgieron.
Entonces, ¿qué es un generador de sitios estáticos? Aún tenemos un cliente y un servidor. Pero algo sucede en el servidor, incluso antes de que solicites la llamada. Solicitas la solicitud HTTP. Entonces, lo que sucede es que haces todo como una aplicación de una sola página normal, pero en lugar de obtener los datos y renderizarlos en el tiempo de ejecución, lo haces en el tiempo de compilación. Entonces, el generador del lado del servidor, el generador de sitios estáticos, tomaría todas las consultas que tienes y las obtendría de antemano, generando páginas HTML reales y construyéndolas en el servidor. Entonces, cada vez que quieras hacer una llamada de API, lo siento, una solicitud HTTP, enviarías la solicitud HTTP al servidor y el servidor te daría esa página HTML prerrenderizada lista para usar. Y luego la operación continúa como de costumbre, la renderización en el lado del servidor. Entonces, la aplicación aún se rehidrataría y la aplicación de una sola página se haría cargo. No solo genera esto, sino que también se encarga del enrutamiento, por lo que generarías un montón de archivos JSON que tienen los datos para otras páginas. Entonces, en lugar de enviar múltiples llamadas de API para obtener también el contenido de las otras páginas, simplemente buscarías este JSON, lo colocarías en la plantilla y listo. Tienes la otra página lista, incluso después de que la aplicación de una sola página comienza a funcionar.
En cuanto a los aspectos aquí, el tiempo de renderización es más rápido porque hay más renderización. La mayor parte del trabajo ya se ha realizado en el tiempo de compilación. El SEO es muy bueno porque los rastreadores ahora pueden obtener los datos más rápido que nunca. El tiempo de compilación es menor, por supuesto, porque estás haciendo muchas cosas y también ocupas más espacio. Pero si hablamos de un montón de páginas HTML, realmente no parece mucho espacio. Y el almacenamiento en caché, por supuesto, es compatible porque las páginas HTML están ahí y la mayoría de los frameworks admiten el almacenamiento en caché de serie. Entonces, para resumir esto, la renderización en el lado del cliente, el tiempo de renderización es inconsistente, el SEO es malo, el tiempo de compilación es rápido y el almacenamiento en caché solo ocurre en el lado del cliente, la renderización en el lado del servidor, el tiempo de renderización es lento, el SEO es bueno, el tiempo de compilación es rápido y el almacenamiento en caché se puede hacer a través de un tercero, como parcialmente compatible. El generador de sitios estáticos tendría un tiempo de renderización más rápido, un buen SEO, un tiempo de compilación lento y el almacenamiento en caché compatible de serie.
Pero la limitación aquí para el generador de sitios estáticos sería que tienes que tener un sitio estático para usar un generador de sitios estáticos, ¿sabes? Está literalmente en el nombre. No puedes hacer esto para un panel de control, no puedes hacer esto para una aplicación que tiene muchas cosas que son muy diferentes, por ejemplo, un nombre de usuario o datos de usuario. No puedes usar esto para una página de perfil para todos los usuarios porque no puedes generar páginas para información confidencial, ¿sabes? Pero puedes hacerlo para un sitio de noticias, para un sitio de blogs o, sí, en nuestro caso aquí, una base de conocimientos.
Y eso nos lleva a Gatsby. Gatsby se autodenomina un generador de sitios moderno, no solo un generador de sitios estáticos porque se ha adaptado a la mayoría de los requisitos modernos y puede ofrecerte casi todo lo que necesitas cuando se trata de sitios web normales. Y lo bueno es que admite la mayoría de las cosas, bueno, sí, casi todo de serie. Está construido sobre React. Entonces, si tienes conocimientos de React, incluso si estás familiarizado con React, la curva de aprendizaje es muy baja para ti y puedes, fácilmente, en un par de días, tener algo funcionando con Gatsby. Es muy fácil. No me llevó mucho tiempo trabajar con ello. Así que debería ser súper fácil.
Y permíteme dejar algo claro aquí, lo que estoy tratando de lograr hoy no es solo mostrar Gatsby o este tipo de escalas, sino que quiero mostrarte lo fácil que es construir algo. Y más tarde, cuando usemos Contentful, también quiero mostrar lo fácil y rápido que es migrar de algo estático a algo súper dinámico. Y también con la implementación, debería ser fácil y directo para ti.
Entonces, eso nos lleva al final de la parte teórica. Y ahora deberíamos pasar al código. Antes de eso, tenemos un panel de preguntas y respuestas que puedes encontrar en Zoom, donde puedes hacer preguntas que solo los panelistas verán y luego podemos responderlas más tarde, o simplemente puedes dejar tu pregunta en el chat. También tenemos con nosotros a Matt Van Voorst, estamos muy contentos de tenerlo aquí, es un ingeniero de software de Contentful y estará encantado de compartir con nosotros o responder cualquier pregunta relacionada con Contentful. Así que, sí, eso es todo, vamos directo al grano.
Comments