DEV Community: Nimbel

Como montar un blog estático con Next.js y dev.to como CMS

dastasoft — Tue, 03 Nov 2020 14:30:11 +0000

Vamos a montar un blog estático utilizando Next.js y dev.to como headless CMS.

Si quieres ir directamente al resultado final en este repo tienes el proyecto final que también sirve como boilerplate para futuros blogs estáticos.

Motivación

Cuando estaba haciendo el blog para Nimbel necesitaba hacer un blog de forma rápida y que se adaptase a la naturaleza estática del resto de la página. Desde Nimbel queriamos poder publicar articulos en Dev.to y al mismo tiempo mantener actualizado el blog personal.

La estrategia que seguiremos en este tutorial será:

Aprovechar las capacidades estáticas de NextJS y la API de Dev.to para hacer un fetch de los post del usuario en tiempo de build.
Crear las rutas estáticas a todos los post que hemos hecho fetch.
Utilizar los webhooks de Dev.to para que cada vez que el usuario cree y/o actualice un post, se genere un nuevo build de nuestro sitio estático.
Crear una plantilla base (boileplate) que nos servirá para crear cualquier otro blog siguiendo esta misma estrategia.

Paso a paso

Pre requisitos

Cuenta de dev.to
Cuenta de Vercel
NodeJS 10.13+ instalado
npm o yarn

Creación del proyecto

En mi caso utilicé mi propio boilerplate de NextJS con TailwindCSS que podéis descargar desde aquí o simplemente utilizando uno de los siguientes comandos:

yarn create next-app my-app-name --example "https://github.com/dastasoft/nextjs-boilerplate"

npx create-next-app my-app-name --use-npm --example "https://github.com/dastasoft/nextjs-boilerplate"

Esto os creará un nuevo proyecto NextJS con TailwindCSS ya configurado.

Estructura

En NextJS no necesitamos definir rutas, cada JS que esté dentro de la carpeta pages será considerado una ruta accesible (menos _app y otros _ archivos que se consideran privados).

Organizaremos el proyecto con las siguientes rutas:

- pages
|- blog
|-- posts
|--- [slug].js
|- _app.js
|- blog.js
|- index.js

_app.js contendrá el layout general de la aplicación que aplicaremos a todas las rutas de nuestra aplicación.
blog.js contendrá la estructura general de la página dedicada al blog así como el fetch a los posts para poder mostrarlos en forma de tarjetas.
index.js será nuestra pagina de inicio.
blog/posts/[slug].js este punto necesita algo mas de explicación:
- Al crear una estructura le estamos diciendo al router que en la ruta nuestro-dominio/blog/posts/slug encontrará un elemento slug que será dinámico y estará accesible mediante era ruta exacta.
- Dentro de ese JS deberemos definir que valor toma el parametro dinámico slug, que en nuestro caso sera el propio slug (url) del post, por lo que deberemos hacer un fetch de ese post en concreto y consultar sus datos en tiempo de build.
- Deberemos definir todos los paths posibles (uno por cada post) de cara a que cuando el usuario navegue o escriba directamente en la url nuestro-dominio/blog/post/este-post-existe ese slug ya este creado en tiempo de build, ya que la página es totalmente estática y no irá a consultar nuevos datos fuera del build*.

SSG vs SSR vs ISR

SSG (Static Site Generation), es el modo por defecto en el que trabaja NextJS, se puede utilizar en combinación con las funciones getStaticProps y getStaticPaths que provee el propio framework, las diferentes páginas se generan de forma estática en tiempo de build.
SSR (Server Side Rendering), se generán las páginas bajo demanda por cada petición desde el servidor, se utiliza en combinación con la función getServerSideProps.
ISR (Incremental Static Regeneration), disponible a partir de la version 9.5 de NextJS. Te perimite actualizar páginas que se crearon como estáticas y al entrar una nueva petición se detecta que está en un estado obsoleto y debe re-renderizarse. Para activar ISR se añade una propiedad revalidate en la función gettaticProps.

En esta guía vamos a tratar solo SSG, para información mas detallada de los otros metódos consultar la documentación oficial, NextJS no necesita ninguna configuración especial para cambiar (o incluso combinar!) entre los diferentes modos, todo recae en la utilización de las funciones especiales ligadas a cada tipo.

Este es un apartado complejo y muy amplio y es precisamente donde NextJS brilla por la posibilidad de elegir fácilmente entre ellos o incluso combinarlos. Lo dejo para una futura guía :) la cual deberia explicar cuando utilizar unos metódos u otros segun la naturaleza de cada página.

En nuestro caso, debido a que todos los datos los tenemos disponibles en tiempo de build, dado que los vamos a buscar a la API de dev.to y no tenemos que cambiar nada de nuestra web a menos que cambie algo en nuestro CMS (dev.to) no tiene sentido estar repitiendo las mismas consultas por cada usuario que entra.

Variables de entorno

A lo largo de las siguientes secciones utilizaremos una variable de entorno para poder acceder al usuario de dev.to y poder descargarnos los articulos publicados. De cara al desarrollo en local utilizaremos el fichero .env.development en el que añadiremos la siguiente variable de entorno:

DEV_USERNAME=dastasoft

Si utilizáis directamente el boilerplate solo tenéis que cambiar el valor de esta variable para que consulte vuestro usuario en vez del mio.

Esta variable de entorno la necesitaremos configurar también en el momento del despliegue, en este tutorial desplegaremos la aplicación utilizando Vercel por lo que podéis consultar la seccion de Despliegue.

Creando el Blog

Empezaremos creando el blog.js en nuestra carpeta pages.

La parte mas importante es como hacemos fetch de todos los posts de un usuario en tiempo de build para poder pintar los posts como tarjetas, para ello utilizaremos una de las funciones SSG que nos proporciona NextJS, getStaticProps:

export const getStaticProps = async () => {
  const devDotToPosts = await fetch(
    `https://dev.to/api/articles?username=${process.env.DEV_USERNAME}`
  );

  const res = await devDotToPosts.json();

  return {
    props: {
      devDotToPosts: res
    }
  };
};

Creando el Artículo

El siguiente paso a realizar para que la generación estática sea posible es definir todas las posibles rutas que el usuario pueda visitar al entrar en esta página, para que sean accesibles las tenemos que pre-renderizar en tiempo de build y NextJS necesita saber la lista completa, esto lo conseguiremos con otra de las funciones que provee NextJS getStaticPaths.

export async function getStaticPaths() {
  const devDotToPosts = await fetch(
    `https://dev.to/api/articles?username=${process.env.DEV_USERNAME}`
  );
  const posts = await devDotToPosts.json();

  return {
    paths: posts.map(post => {
      return {
        params: {
          slug: post.slug
        }
      };
    }),
    fallback: false
  };
}

Creamos una ruta por cada post publicado, utilizando su slug como en el caso anterior. Definimos fallback como false ya que no planeamos soportar URLs que esten fuera de las que estamos generando estáticamente, tener esta propiedad a false devolverá un 404 si se intenta consultar cualquier URL que este fuera del array que proporcionamos en paths.

Habilitar la propiedad fallback tiene numerosas aplicaciones y puede ser utilizada en combinación con Incremental Static Generation el cual es una opción muy potente dentro de NextJS, para más información sobre este tema consultar la documentación oficial

Datos del artículo

Dentro del artículo en concreto, necesitamos recuperar los datos, para ello consultaremos la API de dev.to usando el mismo slug con el que hemos construido la URL.

export const getStaticProps = async ({ params }) => {
  const devDotToPost = await fetch(
    `https://dev.to/api/articles/${process.env.DEV_USERNAME}/${params.slug}`
  );
  const res = await devDotToPost.json();

  return {
    props: {
      devDotToPost: res
    }
  };
};

Todos los datos que nos llegan desde la API de dev.to los pasamos en tiempo de build a la página del artículo en concreto, estos datos serán accesibles a través de la prop devDotToPost.

export default function Post({ devDotToPost }) {
    ...
}

Imprimir el markdown

Una vez ya tenemos los datos del artículo, entre los múltiples campos que nos llegan de la API, el contenido en markdown está en body_html, para utilizarlo:

<div className="markdown" dangerouslySetInnerHTML={{ __html: body_html }} />

En la clase markdown deberás definir como quieres que se vean los elementos contenidos en el markdown ya que la API devuelve una versión raw del markdown. En el proyecto de ejemplo tienes disponible una propuesta simple.

[slug].js al completo

Así es como queda nuestra template para cualquier artículo, podéis verlo directamente en el repo:

import Head from 'next/head';
import Link from 'next/link';

import TopButton from '../../../components/TopButton';

export default function Post({ devDotToPost }) {
  const {
    title,
    published_at,
    social_image,
    body_html,
    user,
    type_of,
    description,
    canonical_url
  } = devDotToPost;
  const date = new Date(published_at);
  const formatedDate = `${date.getDate()}/${
    parseInt(date.getMonth(), 10) + 1
  }/${date.getFullYear()}`;

  return (
    <div>
      <Head>
        <meta property="og:type" content={type_of} />
        <meta property="og:title" content={title} />
        <meta property="og:description" content={description} />
        <meta property="og:image" content={social_image} />
        <meta property="og:url" content={canonical_url} />
      </Head>
      <div className="flex justify-center">
        <TopButton />
        <article className="text-xs w-full md:w-3/4 ">
          <div className="border-2 text-black bg-white md:rounded-lg overflow-hidden">
            <img className="w-full" src={social_image} alt={title} />
            <div className="p-4 md:p-32">
              <h1>{title}</h1>
              <div className="flex items-center text-gray-600">
                <img
                  className="rounded-full w-12"
                  src={user.profile_image_90}
                  alt={user.name}
                />
                <span className="mx-4">{user.name}</span>
                <span className="text-sm">{formatedDate}</span>
              </div>
              <div
                className="markdown"
                dangerouslySetInnerHTML={{ __html: body_html }}
              />
            </div>
          </div>
          <Link href="/blog">
            <a className="text-blue-500 inline-flex items-center md:mb-2 lg:mb-0 cursor-pointer text-base pb-8">
              <svg
                className="w-4 h-4 mr-2"
                stroke="currentColor"
                strokeWidth="2"
                fill="none"
                strokeLinecap="round"
                strokeLinejoin="round"
                viewBox="0 0 24 24"
              >
                <path d="M19 12H5M12 19l-7-7 7-7" />
              </svg>
              Back
            </a>
          </Link>
        </article>
      </div>
    </div>
  );
}

export const getStaticProps = async ({ params }) => {
  const devDotToPost = await fetch(
    `https://dev.to/api/articles/${process.env.DEV_USERNAME}/${params.slug}`
  );
  const res = await devDotToPost.json();

  return {
    props: {
      devDotToPost: res
    }
  };
};

export async function getStaticPaths() {
  const devDotToPosts = await fetch(
    `https://dev.to/api/articles?username=${process.env.DEV_USERNAME}`
  );
  const posts = await devDotToPosts.json();

  return {
    paths: posts.map(post => {
      return {
        params: {
          slug: post.slug
        }
      };
    }),
    fallback: false
  };
}

Layout

Para crear el layout y que aplique a todas las pantallas, lo crearemos en el fichero _app.js e internamente NextJS lo añadirá a todas las paginas:

import Link from 'next/link';

import '../styles/index.css';

export default function App({ Component, pageProps }) {
  return (
    <div>
      <nav className="p-4 flex justify-center items-center mb-4" id="nav">
        <Link href="/">
          <span className="text-xl font-bold cursor-pointer mr-4">Home</span>
        </Link>
        <Link href="/blog">
          <span className="text-xl font-bold cursor-pointer">Blog</span>
        </Link>
      </nav>
      <main className="container px-5 mx-auto">
        <Component {...pageProps} />
      </main>
    </div>
  );
}

Lo importante en este punto es:

Utilizar el componente Link de NextJS para que la navegación sea correcta
Es el sitio ideal para importar el archivo de css y que aplique de forma global.
Asegurarse de tener <Component {...pageProps} /> ya que sin esto no veremos los componentes hijos, (similar a la utilizacion de children en React)

Home

Definir la pagina principal en NextJS es tan sencillo como crear el fichero index.js dentro de la carpeta pages y NextJS creará automáticamente una ruta, en este caso a /, la cual mezclará lo que hayamos definido en el fichero _app.js mas el propio index.js.

Esta es la propuesta de home page para el proyecto:

import DevDotToLogo from '../public/devdotto.svg';
import NextLogo from '../public/nextjs.svg';

export default function Home() {
  return (
    <div>
      <div className="flex justify-center items-center">
        <a
          href="https://nextjs.org/"
          target="_blank"
          rel="noopener noreferrer"
          aria-label="NextJS"
        >
          <NextLogo className="mr-4" width="100px" height="100px" />
        </a>
        <span className="text-2xl">Blog Boilerplate</span>
      </div>

      <div className="flex justify-center items-center">
        <span className="text-2xl">with</span>
        <a
          href="https://dev.to/"
          target="_blank"
          rel="noopener noreferrer"
          aria-label="Dev.to"
        >
          <DevDotToLogo className="mx-4" width="100px" height="100px" />
        </a>
        <span className="text-2xl">as a CMS</span>
      </div>
    </div>
  );
}

En este caso se utilizan anchor normales ya que son enlaces al exterior y NextJS no tiene que acceder a ningua ruta interna.

CSS

NextJS mostrará errores si intentáis introducir CSS que puedan afectar de forma global fuera del archivo _app.js, por ello en los demas sitios como páginas y/o componentes es recomendable utilizar soluciones como emotionjs, styled-components, css-modules o tailwindcss como en esta guía, que tienen su rango de efecto limitado al propio componente.

NextJS provee su propia solución CSS-in-JS llamada styled-jsx pero últimamente de los propios proyectos quick-start de NextJS se ha optado por implementar css-modules.

Si quereis conocer mejor que opciones tenéis para temas de estilo podéis consultar mi guia de estilos en React la cual aplica en su mayoria para NextJS, la diferencia principal es que no podemos aplicar estilos globales como hemos comentado anteriormente.

Despliegue

Desplegaremos este proyecto en la plataforma de los mismos creadores de NextJS que es Vercel. Para desplegar un proyecto en Vercel debéis seguir los siguientes pasos:

Crear una cuenta en Vercel
Pulsar en Import Project
Importaremos el proyecto directamente de nuestro repositorio Git
Proporcionar la URL del repositorio GIT.
En caso de que el paso anterior os de el error: Couldn’t find the Git repository. If it exists, verify that the GitHub Integration is permitted to access it in the GitHub App Settings. pulsar en GitHub App Settings y añadir el repositorio que intentáis desplegar a la lista de accesos de Vercel, si es el primer despliegue que realizais os pedirá acceso como parte del proceso.
Una vez Vercel tenga visibilidad sobre el repositorio Git podremos darle un nombre, que puede ser cualquiera no tiene porque coincidir con git, un Framework preset que dejaremos tal y como esta marcado en Next.js, Build and Output Settings que por el momento no necesitaremos cambiar nada y por último Environment Variables aqui tendremos que crear la variable de entorno que definimos anteriormente en .env.development
Dentro de Environment Variables definimos la variable DEV_USERNAME con el valor del usuario sobre el que queráis hacer las consultas, en mi caso dastasoft y pulsamos Add
Pulsamos Deploy

Es posible que la primera vez el despliegue falle dando errores de recibir respuestas JSON erroneas, en mi caso intentando el despliegue una segunda vez me funcionó sin problemas.

Podéis ver el resultado final desplegando el boilerplate que hemos construido en este tutorial en [https://dev-cms-static-blog.vercel.app/(https://dev-cms-static-blog.vercel.app/)

Actualización automática

Ya casi estamos, pero nos falta el paso más importante, ahora mismo tenemos un blog que se genera en tiempo de build de forma estática, eso quiere decir que cuando el proyecto se despliega en Vercel, se lanzan todas las consultas necesarias a dev.to para obtener la información necesaria y con eso se construye una web totalmente estática en la que por muchas visitas que tengamos, no se vuelve a consultar a dev.to para recuperar artículos.

Pero y si publicamos/editamos un artículo? Necesitamos una forma de decirle a Vercel que debe volver a pasar esa fase de build y recuperar la información más actualizada, para ello utilizaremos webhooks.

Crear una URL de acceso al despliegue

Dentro del proyecto en Vercel, debemos ir a Settings a la sección referente a Git y buscar el cuadro Deploy Hooks, aquí crearemos un nuevo hook al cual le podemos dar el nombre que queramos y que este en nuestra rama principal de git, en mi caso:

Nombre: dev.to
Git Branch Name: master

Esto nos generará una URL del tipo https://api.vercel.com/v1/integrations/deploy/xxxxxxxxxxxxxxxxxxx

Crear webhooks en dev.to

En el README.md del boilerplate teneis los comandos disponibles para consultar, crear y eliminar webhooks en vuestra cuenta de dev.to.

Necesitaréis acceso a una Terminal y el paquete curl, además en vuestra cuenta de dev.to necesitaréis crear una DEV API Key, esto lo podéis hacer accediendo a dev.to con vuestra cuenta en el apartado Settings, Account y en la sección DEV API Keys.

Para crear la DEV API Key hay que proporcionar un nombre y pulsar en Generate API Key, esto nos generará un hash que necesitaremos en los siguientes comandos.

Con una terminal abierta utilizamos el siguiente comando para crear el webhook en nuestra cuenta de dev.to

curl -X POST -H "Content-Type: application/json" \
  -H "api-key: API_KEY" \
  -d '{"webhook_endpoint":{"target_url":"TARGET_URL","source":"DEV","events":["article_created", "article_updated"]}}' \
  https://dev.to/api/webhooks

Donde API_KEY es la DEV API Key que hemos creado en dev.to y TARGET_URL (importante mantener las ") es la URL de acceso al despliegue que hemos creado en Deploy Hooks de Vercel. En este ejemplo estamos poniendo a la escucha el webhook para los eventos de creación de artículos y también para la edición, podéis dejar los eventos que os interesen.

Comprobar webhook

En una terminal con curl disponible ejecutar el siguiente comando:

curl -H "api-key: API_KEY" https://dev.to/api/webhooks

Donde API_KEY es la DEV API Key que hemos creado en dev.to.

Debe respondernos con un array el cual no debe estar vacío ya que en el paso anterior creamos un webhook. Si os sale como respuesta un array vacío, comprobad el paso anterior.

Conclusión

Si se ha creado satisfactoriamente el webhook, lo que habremos conseguido es que cada vez que un artículo se cree o se edite (segun los eventos que hayais utilizado) llamará a la URL que le hemos porporcionado, esta URL desencadenará un nuevo build en Vercel que volverá a consultar la API de dev.to y encontrará el nuevo artículo generando de nuevo una versión totalmente estática de nuestro blog.

Con esto ya tendríamos completados los requisitos que nos habiamos fijado al principio de este tutorial! Os animo a indagar más en el proyecto boilerplate sobre el que esta basado este tutorial para que lo podáis utilizar como base para futuros proyectos.

Ahora es vuestro turno, cual es vuestra experiencia creando blogs? Crees que es más sencillo de la forma que lo haces actualmente o con esta forma? Ya utilizabas esta forma o una parecida, cuentame tu caso de éxito o tus preguntas :D

Con un poco de suerte, este post creará una nueva entrada en el Blog de Nimbel

Disfrutad!

Simple Static Blog with Next.js and dev.to as CMS

dastasoft — Mon, 26 Oct 2020 23:37:17 +0000

UPDATE: Added Next v10 with new Image component

We are going to set up a static blog using Next.js and dev.to as a headless CMS.

If you want to go directly to the final result in this repo you have the final project that also serves as a boilerplate for future static blogs.

Motivation

When I was blogging for Nimbel I needed to make a blog quickly that would fit the static nature of the rest of the page. Nimbel wanted to be able to publish articles in Dev.to and at the same time keep the personal blog updated.

The strategy we will follow in this tutorial will be:

Take advantage of the static capabilities of NextJS and the Dev.to API to fetch the user's posts at build time.
Create the static paths to all the posts we have fetched.
Use Dev.to's webhooks so that every time the user creates and/or updates a post, a new build of our static site is generated.
Create a base template (boileplate) that will be used to create any other blog following this same strategy.

Step by step

Pre-requisites

dev.to account
Vercel account
NodeJS 10.13+ installed
npm or yarn

Creation of the project

In my case I used my own NextJS boilerplate with TailwindCSS that you can download from here or simply using one of the following commands:

yarn create next-app my-app-name --example "https://github.com/dastasoft/nextjs-boilerplate"

npx create-next-app my-app-name --use-npm --example "https://github.com/dastasoft/nextjs-boilerplate"

This will create a new NextJS project with TailwindCSS already configured.

Structure

In NextJS we don't need to define paths, each JS that is inside the pages folder will be considered an accessible path (minus _app and other _ files that are considered private).

We will organize the project with the following paths:

- pages
|- blog
|-- posts
|--- [slug].js
|- _app.js
|- blog.js
|- index.js

_app.js will contain the general layout of the application that we will apply to all the paths of our application.
blog.js will contain the general structure of the blog page as well as the fetch for the posts to be able to display them in the form of cards.
index.js will be our home page.
blog/posts/[slug].js this point needs some additional explanation:
- By creating a structure we're telling the router that in the path our-domain/blog/posts/slug it will find a slug element that will be dynamic and accessible via the exact path.
- Within this JS we must define what value the dynamic parameter slug takes, which in our case will be the slug (url) of the post itself, so we must fetch that particular post and check its data at build time.
- We must define all the possible paths (one for each post) so that when the user navigates or writes directly in the url our-domain/blog/post/this-post that slug is already created at build time, since the page is completely static and will not go to consult new data outside the build.

SSG vs SSR vs ISR

SSG (Static Site Generation), is the default mode in which NextJS works, it can be used in combination with the getStaticProps and getStaticPaths functions provided by the framework, the different pages are generated statically at build time.
SSR (Server Side Rendering), pages are generated on demand for each request from the server, is used in combination with the getServerSideProps function.
ISR (Incremental Static Regeneration), available from version 9.5 of NextJS. It allows you to update pages that were created as static and when a new request is entered it is detected to be in an obsolete state and must be re-rendered. To activate ISR a 're-validate' property is added to the 'object' function.

In this guide we are going to treat only SSG, for more detailed information of the other methods see the official documentation, NextJS does not need any special configuration to change (or even combine!) between the different modes, it all lies in the use of the special functions linked to each type.

This is a complex and very extensive section and it is precisely where NextJS shines by the possibility of easily choosing between them or even combining them. I leave it for a future guide :) which should explain when to use some methods or others according to the nature of each page.

In our case, because we have all the data available at build time, since we are going to look for it in the dev.to API and we don't have to change anything on our website unless something changes in our CMS (dev.to) it doesn't make sense to be repeating the same queries for each user that enters.

Environment Variables

Throughout the following sections we will use an environment variable to access the dev.to user and download the published articles. For local development we will use the .env.development file in which we will add the following environment variable:

DEV_USERNAME=dastasoft

If you use the boilerplate directly, you only have to change the value of this variable.

This environment variable will also need to be configured at the time of deployment, in this tutorial we will deploy the application using Vercel so you can check the section of Deployment.

Creating the Blog

We will start by creating the blog.js in our pages folder.

The most important part is how we fetch all the posts of a user at build time to be able to display the posts as cards, for this we will use one of the SSG functions provided by NextJS, getStaticProps:

export const getStaticProps = async () => {
  const devDotToPosts = await fetch(
    `https://dev.to/api/articles?username=${process.env.DEV_USERNAME}`
  );

  const res = await devDotToPosts.json();

  return {
    props: {
      devDotToPosts: res,
    },
  };
};

Creating the Article

The next step to make the static generation possible is to define all the possible paths that the user can visit when entering this page, to be accessible we have to pre-render them at build time and NextJS needs to know the complete list, this will be achieved with another of the functions provided by NextJS getStaticPaths.

export async function getStaticPaths() {
  const devDotToPosts = await fetch(
    `https://dev.to/api/articles?username=${process.env.DEV_USERNAME}`
  );
  const posts = await devDotToPosts.json();

  return {
    paths: posts.map(post => {
      return {
        params: {
          slug: post.slug,
        },
      };
    }),
    fallback: false,
  };
}

We create a route for each published post, using its slug as in the previous case. We define fallback as false since we do not plan to support URLs that are outside of the ones we are statically generating, having this property set to false will return a 404 if you try to query any URL that is outside of the array we provide in paths.

Enabling the fallback property has numerous applications and can be used in combination with Incremental Static Generation which is a very powerful option within NextJS, for more information on this topic see official documentation

Article data

Within the specific article, we need to retrieve the data, for this we will consult the dev.to API using the same slug with which we have built the URL.

export const getStaticProps = async ({ params }) => {
  const devDotToPost = await fetch(
    `https://dev.to/api/articles/${process.env.DEV_USERNAME}/${params.slug}`
  );
  const res = await devDotToPost.json();

  return {
    props: {
      devDotToPost: res,
    },
  };
};

All the data that comes from the dev.to API is passed in build time to the page of the specific article, this data will be accessible through the prop devDotToPost.

export default function Post({ devDotToPost }) {
    ...
}

Style the markdown

Once we have the data of the article, among the multiple fields that come to us from the API, the content in markdown is in body_html, to use it:

<div className="markdown" dangerouslySetInnerHTML={{ __html: body_html }} />

In the markdown class you must define how you want the elements look, since the API returns a raw version of the markdown. In the example project you have available a simple proposal.

Complete [slug].js

This is how our template looks like for any article, you can see it directly in the repo:

import Head from "next/head";
import Link from "next/link";

import TopButton from "../../../components/TopButton";

export default function Post({ devDotToPost }) {
  const {
    title,
    published_at,
    social_image,
    body_html,
    user,
    type_of,
    description,
    canonical_url,
  } = devDotToPost;
  const date = new Date(published_at);
  const formatedDate = `${date.getDate()}/${
    parseInt(date.getMonth(), 10) + 1
  }/${date.getFullYear()}`;

  return (
    <div>
      <Head>
        <meta property="og:type" content={type_of} />
        <meta property="og:title" content={title} />
        <meta property="og:description" content={description} />
        <meta property="og:image" content={social_image} />
        <meta property="og:url" content={canonical_url} />
      </Head>
      <div className="flex justify-center">
        <TopButton />
        <article className="text-xs w-full md:w-3/4 ">
          <div className="border-2 text-black bg-white md:rounded-lg overflow-hidden">
            <img className="w-full" src={social_image} alt={title} />
            <div className="p-4 md:p-32">
              <h1>{title}</h1>
              <div className="flex items-center text-gray-600">
                <img
                  className="rounded-full w-12"
                  src={user.profile_image_90}
                  alt={user.name}
                />
                <span className="mx-4">{user.name}</span>
                <span className="text-sm">{formatedDate}</span>
              </div>
              <div
                className="markdown"
                dangerouslySetInnerHTML={{ __html: body_html }}
              />
            </div>
          </div>
          <Link href="/blog">
            <a className="text-blue-500 inline-flex items-center md:mb-2 lg:mb-0 cursor-pointer text-base pb-8">
              <svg
                className="w-4 h-4 mr-2"
                stroke="currentColor"
                strokeWidth="2"
                fill="none"
                strokeLinecap="round"
                strokeLinejoin="round"
                viewBox="0 0 24 24"
              >
                <path d="M19 12H5M12 19l-7-7 7-7" />
              </svg>
              Back
            </a>
          </Link>
        </article>
      </div>
    </div>
  );
}

export const getStaticProps = async ({ params }) => {
  const devDotToPost = await fetch(
    `https://dev.to/api/articles/${process.env.DEV_USERNAME}/${params.slug}`
  );
  const res = await devDotToPost.json();

  return {
    props: {
      devDotToPost: res,
    },
  };
};

export async function getStaticPaths() {
  const devDotToPosts = await fetch(
    `https://dev.to/api/articles?username=${process.env.DEV_USERNAME}`
  );
  const posts = await devDotToPosts.json();

  return {
    paths: posts.map(post => {
      return {
        params: {
          slug: post.slug,
        },
      };
    }),
    fallback: false,
  };
}

Layout

To create the layout and apply it to all the screens, we will create it in the _app.js file and internally NextJS will add it to all the pages:

import Link from "next/link";

import "../styles/index.css";

export default function App({ Component, pageProps }) {
  return (
    <div>
      <nav className="p-4 flex justify-center items-center mb-4" id="nav">
        <Link href="/">
          <span className="text-xl font-bold cursor-pointer mr-4">Home</span>
        </Link>
        <Link href="/blog">
          <span className="text-xl font-bold cursor-pointer">Blog</span>
        </Link>
      </nav>
      <main className="container px-5 mx-auto">
        <Component {...pageProps} />
      </main>
    </div>
  );
}

The important thing at this point is:

Use the NextJS Link component to make the navigation correct
It is the ideal place to import the css file and apply it globally.
Be sure to have <Component {...pageProps} /> since without this we will not see the children components, (similar to the use of children in React)

Home

Defining the main page in NextJS is as simple as creating the file index.js inside the pages folder and NextJS will automatically create a path, in this case to /, which will mix what we have defined in the _app.js file plus the index.js itself.

This is the proposed home page for the project:

import DevDotToLogo from "../public/devdotto.svg";
import NextLogo from "../public/nextjs.svg";

export default function Home() {
  return (
    <div>
      <div className="flex justify-center items-center">
        <a
          href="https://nextjs.org/"
          target="_blank"
          rel="noopener noreferrer"
          aria-label="NextJS"
        >
          <NextLogo className="mr-4" width="100px" height="100px" />
        </a>
        <span className="text-2xl">Blog Boilerplate</span>
      </div>

      <div className="flex justify-center items-center">
        <span className="text-2xl">with</span>
        <a
          href="https://dev.to/"
          target="_blank"
          rel="noopener noreferrer"
          aria-label="Dev.to"
        >
          <DevDotToLogo className="mx-4" width="100px" height="100px" />
        </a>
        <span className="text-2xl">as a CMS</span>
      </div>
    </div>
  );
}

In this case normal anchor is used as they are links to the outside and NextJS does not have to access any internal route.

CSS

NextJS will display errors if you try to introduce CSS that can affect globally outside the _app.js file, in the other sites as pages and / or components is advisable to use solutions such as emotionjs, styled-components, css-modules or tailwindcss as in this guide, which have their scope limited to the component itself.

NextJS provides its own CSS-in-JS solution called styled-jsx but lately from NextJS own quick-start projects it has been decided to implement css-modules.

If you want to know better what options you have for style issues you can check my style guide in React which applies mostly to NextJS, the main difference is that we can not apply global styles as we discussed above.

Deployment

We will deploy this project on the platform of the same creators of NextJS which is Vercel. To deploy a project in Vercel you must follow the next steps:

Create a Vercel account
Click on Import Project
We'll import the project directly from our Git repository
Provide the URL of the GIT repository
In case the previous step gives you the error: Couldn't find the Git repository. If it exists, verify that the GitHub Integration is permitted to access it in the GitHub App Settings. click on GitHub App Settings and add the repository you're trying to deploy to Vercel's access list, if it's the first deployment you do it, Vercel will ask you for access as part of the process.
Once Vercel has visibility into the Git repository, you can give it a name, a framework preset that you leave as it is in Next.js, Build and Output Settings that you don't need to change for now, and finally Environment Variables that you create in .env.development
Inside Environment Variables we define the variable DEV_USERNAME with the value of the user about whom you want to make the queries, in my case dastasoft and press Add.
Press Deploy.

It is possible that the first time the deployment failed giving errors of receiving wrong JSON answers, in my case trying the deployment a second time worked without problems.

You can see the final result by deploying the boilerplate we have built in this tutorial at https://dev-cms-static-blog.vercel.app/

Automatic update

We're almost done, but the most important step is missing, right now we have a blog that is generated in a static way at build time, that means that when the project is deployed in Vercel, all the necessary queries are launched to dev.to to obtain the necessary information and with that a totally static website is built in which no matter how many visits we have, dev.to is not consulted again to retrieve articles.

But what if we publish/edit an article? We need a way to tell Vercel that it must go back to that build phase and recover the most updated information, for that we will use webhooks.

Create a URL to access the display

Within the project in Vercel, we must go to Settings to the section referring to Git and look for the box Deploy Hooks, here we will create a new hook to which we can give the name that we want and that this in our main branch of git, in my case:

Name: dev.to
Git Branch Name: master

This will generate a URL of the type https://api.vercel.com/v1/integrations/deploy/xxxxxxxxxxxxxxxxxxx

Create webhooks on dev.to

In the README.md of the boilerplate you have the commands available to view, create and delete webhooks in your dev.to account.

You will need access to a Terminal and curl package, in your dev.to account you will need to create a dev.to API Key, this can be done by logging into dev.to with your account in the Settings, Account and Dev API Keys section.

To create the DEV API Key you have to provide a name and click on Generate API Key, this will generate a hash that we will need in the following commands.

With a terminal open we use the following command to create the webhook in our dev.to account

curl -X POST -H "Content-Type: application/json" \
  -H "api-key: API_KEY" \
  -d '{"webhook_endpoint":{"target_url":"TARGET_URL","source":"DEV","events":["article_created", "article_updated"]}}' \
  https://dev.to/api/webhooks

Where API_KEY is the DEV API Key that we have created in dev.to and TARGET_URL (important to keep the ") is the display access URL that we have created in Deploy Hooks from Vercel. In this example we are using the webhook for the events of creation of articles and also for the edition, you can leave the events that you need.

Check webhook

In a terminal with curl available, execute the following command:

curl -H "api-key: API_KEY" https://dev.to/api/webhooks

Where API_KEY is the DEV API Key we have created on dev.to.

The service must answer us with an array which must not be empty, because in the previous step we created a webhook. If you get an empty array in response, check the previous step.

Conclusion

If the webhook has been successfully created, what we will have achieved is that every time an article is created or edited (depending on the events you have used) it will call the URL we have provided it with, this URL will trigger a new build in Vercel that will again check the dev.to API and find the new article generating again a totally static version of our blog.

With this we would have already completed the requirements that we had set at the beginning of this tutorial! I encourage you to investigate further in the project boilerplate on which this tutorial is based so that you can use it as a basis for future projects.

Now it's your turn, what is your experience creating blogs? Do you think it's easier the way you're currently doing it or with this form? You already used this form or a similar one, tell me your success story or your questions :D

Hopefully, this post will create a new entry in Nimbel's Blog

Enjoy!

How much money do you lose for every second it takes to load your web application?

rubenofen — Wed, 07 Oct 2020 13:46:23 +0000

Did you know that most people who have a profitable business idea, fail miserably just because they not make a reasonable investment in their sales tool?

This is absolutely true and we have done an experiment in which it is confirmed that an incorrect decision can make you lose thousands of euros.

Many times when we create a business, we realize that one of the most important sales channels is the internet and at that moment we decide to create our own web application.

Usually we have to take many decisions and make important investments in different areas so that our product or service goes ahead.

The first problem we face when creating the web application is:
**How many technologies do we have available and what are their costs?

One of the technologies that entrepreneurs usually use is a CMS such as Wordpress, Joomla or Drupal, this is a very flexible solution and *quite good.

It allows the entrepreneur to manage their own content, maintain it and modify it, in addition many companies offer to provide hosting or hosting for Wordpress with everything pre-configured.

There are also many developers of these CMS's that offer their services at a very competitive price...but...

This hides a deeper problem that can turn the business into a ruin. **You have to take into account the user's behavior.

According to a report from Deloitte, if your web application takes between 1 and 3 seconds to load the probability of bouncing increases by 32%, but if the loading time is in the range of 1 to 5 seconds, the probability of bouncing increases by up to 90% 😱.

And what is the probability of rebound?

It is considered a rebound when a user enters a website and without interacting with it closes it because he is not interested in what is on it.
This is quite normal, because it's impossible to attract only users who are interested in your product or service to your website.
And what effect does it have on the business to increase the likelihood of a bounce because it takes a few seconds to load?

The experiment

Let's make the following assumption:
An entrepreneur has a business where he sells a service or an article for 100 ?, of this article 50 ? are costs and the other 50 ? are benefits.

Sales price	Costs	Profit
100€	50€	50€

Let's imagine that you manage to attract 4,500 users per month and if your application loaded instantly that's how users would behave:

Visits	% bounce	users bounce	Conversion ratio	Profit per month
4.500	29%	1.305	2%	3.195€

In other words, of the total of 4,500 visits, 1,305 enter but instantly realize that they are not interested and leave without interacting and reading practically nothing.

For both scenarios we propose a web application that will be working for 3 years.

Scenario A

The entrepreneur hires the development of a wordpress because he is convinced by the budget and the solution is already quite good, "I don't need that much ".

Budget:

Development	Plugins	Hosting/month(VPS)
1.200€	300€	70€

Therefore: 1,200 + 300 + (70*3*12) = 4,020 in the 3 years

Scenario A

The entrepreneur hires the development of a wordpress because he is convinced by the budget and the solution is already quite good, "I don't need that much ".

Budget:

Development	Plugins	Hosting/month(VPS)
1.200€	300€	70€

Therefore: 1,200 + 300 + (70*3*12) = 4,020 in the 3 years

Result

We have obtained this result from one of our clients, who has his product developed in wordpress and has the page hosted in a quality VPS, obviously we hide his brand so as not to damage his image.
We will look at the First Contenful Paint, which is the time that passes from the request of the page until the first piece of content that appears on your screen, either an image, an icon or some text.

7 seconds 😱😨😰😥😓. If we look at Deloitte's graph, taking between 1 and 7 seconds to load means a 123% higher probability of rebound. And how do your business results look?

The original bounce was 1,305 users out of 4,500, by increasing the bounce probability by 123% we will have 2,910 users that will bounce without buying anything. With this you only have 1,519 possible buyers left. **At this point, we could evaluate the cost of having attracted traffic to your website, but we'll leave that for another article.

Numbers:

Visits	Bounces	Interested parties	Conversion ratio	Sales	Monthly profit
4.500	2.910	1.590	2%	3.179,70€	1.589,85€

Scenario B

The entrepreneur hires the JAMSTACK development a little more expensive but that has convinced him more, because he has been assured that his page will go at the speed of light and that will have a positive impact on his business. In addition, with the traffic that the hosting has, it is free.

Quotation:

Professional Designer	Development	Hosting/month(VPS)
1.200€	4.000€	0€

Therefore: 1,200 + 300 + (0*3*12) = 5,200 in the 3 years (if clearly 30% more expensive in the 3 years)

Let's see stage B

Here we expose our website directly, hosted in vercel.

If we look at the image, 0.9s 🧐🤓😎🥳😏, a priori, has no bounce percentage penalty so the numbers setting up a business with a page with the JamStack stack would look like this.

Visits	Bounces	Interested users	Conversion ratio	Sales	Profit month
4.500	1.305	3.195	2%	6.390,00€	3.195,00€

We believe that the difference is more than noticeable, between 1,589 and 3,195 there are 1,606
Have you thought what you can do with that extra money a month? The car of your dreams? The little house in the mountain? or even leave your job for good, if you are a part-time entrepreneur? **Those 1600 euros change everything.

What happened after 3 years?

Scenario A

Total benefits	Web development	Final result
57.234,60€	4.020€	53.214,60€

Scenario B

Total benefits	Web development	Final result
115.020,00€	5.200€	109.820,00€

Image from StartupStockPhotos in Pixabay

That's more than 50,000 euros. Have you thought about what it costs you to win 50,000 euros to lose it because of a wrong decision?

In this experiment we have not taken into account the effect that having a professional designer who creates your own image and cares about the user experience, instead of using a template, can have. It's a summation and it goes on.

Remember: **Good enough makes you poor

Lucky you, at Nimbel we are experts in websites, high performance applications, mobile applications and everything that software technology has to offer.
Contact us and tell us what you want to do and we will offer you the solution that best fits your project. Your success is our mission.

¿Cuanto dinero pierdes por cada segundo que tarda en cargar tu aplicación web?

rubenofen — Fri, 25 Sep 2020 08:41:47 +0000

¿Sabias que la mayoría de la gente que tiene una idea rentable de negocio, fracasa estrepitosamente solo por no hacer una inversión razonable en su herramienta de ventas?

Esto es totalmente cierto y hemos hecho un experimento en el que se confirma que una decision incorrecta puede hacerte perder miles de euros.

Muchas veces cuando creamos un negocio, nos damos cuenta que uno de los canales más importantes de ventas es internet y en ese momento nos decidimos a crear nuestra propia aplicación web.

Habitualmente tenemos que tomar muchas decisiones y hacer importantes inversiones en diferentes ámbitos para que nuestro producto o servicio salga adelante.

El primer problema que se nos plantea a la hora de crear la aplicación web es:
¿Cuantas tecnologías tenemos disponibles y que coste tienen?.

Una de las tecnologías que los emprendedores suelen usar es un CMS como Wordpress, Joomla o Drupal, esta es una solución muy flexible y bastante buena.

Permite al emprendedor gestionar su propio contenido, mantenerlo y modificarlo, además muchas empresas se ofrecen a facilitar el alojamiento o hosting para Wordpress con todo preconfigurado.

También hay muchos desarrolladores de estos CMS que ofrecen sus servicios a un precio muy competitivo...pero...

Esto esconde un problema más profundo que puede convertir el negocio en una ruina. Hay que tener en cuenta el comportamiento del usuario.

Según un informe de Deloitte, Si tu aplicación web tarda entre 1 y 3 segundos en cargar la probabilidad de rebote aumenta en un 32%, pero si el tiempo de carga se encuentra en el rango de entre 1 y 5 segundos, la probabilidad de rebote aumenta hasta en un 90% 😱.

¿Y que es la probabilidad de rebote?

Se considera un rebote cuando un usuario entra en una web y sin interacturar con ella la cierra porque no le interesa lo que en cuentra.
Esto es bastante normal, porque es imposible atraer a tu web sólo a usuarios que les interesa tu producto o servicio.
¿Y que efecto tiene en el negocio aumentar la probalibilidad de rebote a causa un tardar unos segundos en cargar?

El experimento

Vamos a plantear el siguiente supuesto:
Un emprendedor tiene un negocio donde vende un servicio o un articulo por 100€, de este articulo 50€ son costes y los otros 50€ son beneficios.

Precio venta	Costes	Beneficio
100€	50€	50€

Imaginemos que consigue atraer 4.500 usuarios al mes y si su aplicación cargara al instante así se comportarían los usuarios:

Visitas	% de rebote	usuarios rebote	Ratio conversión	Beneficio al mes
4.500	29%	1.305	2%	3.195€

O sea, del total de 4.500 visitas, 1.305 entran pero al instante se dan cuenta que no les interesa y salen sin interactuar y sin leer prácticamente nada.

Para los dos escenarios planteamos una aplicación web que estará funcionando durante 3 años.

Escenario A

El emprendedor contrata el desarrollo de un wordpress porque le convence el presupuesto y la solución ya es bastante buena, "No necesito tanto".

Presupuesto:

Desarrollo	Plugings	Hosting/mes(VPS)
1.200€	300€	70€

Por tanto: 1.200 + 300 + (70*3*12) = 4.020€ en los 3 años

Resultado

Este resultado lo hemos obtenido de uno de nuestros clientes, que tiene su producto desarrollado en wordpress y tiene la página alojada en un VPS de calidad, evidentemente ocultamos su marca para no dañar su imagen.
Nos fijaremos en el First Contenful Paint, que es el tiempo que transcurre desde la solicitud de la página hasta que el primer fragmento de contenido que aparece en tu pantalla, ya sea una imagen, un icono o algún texto.

7 segundos 😱😨😰😥😓. Si miramos el gráfico de Deloitte tardar entre 1 y 7 segundos en cargar implica un 123% más de probabilidad de rebote. ¿Y cómo le quedan los resultados de su negocio?

El rebote original eran 1.305 usuarios de 4.500, al aumentar un 123% la probabilidad de rebote tendremos 2.910 usuarios que rebotarán sin comprar nada. Con esto sólo te quedan 1.519 posibles compradores. En este punto podríamos valorar el coste de haber atraido el tráfico a tu web, pero eso lo dejamos para otro artículo.

Números:

Visitas	Rebotes	Interesados	Ratio conversión	Ventas	Beneficio mes
4.500	2.910	1.590	2%	3.179,70€	1.589,85€

Escenario B

El emprendedor contrata el desarrollo JAMSTACK un poco más caro pero que le ha convencido más, porque le han asegurado que su página irá a la velocidad de la luz y eso repercutirá positivamente en su negocio. Además, con el tráfico que tiene el alojamiento le sale gratis.

Presupuesto:

Diseñador profesional	Desarrollo	Hosting/mes(VPS)
1.200€	4.000€	0€

Por tanto: 1.200 + 300 + (0*3*12) = 5.200€ en los 3 años (si claramente es un 30% más caro en los 3 años)

Veamos el escenario B

Aquí exponemos nuestra web directamente, alojada en vercel.

Si miramos la imagen, 0.9s 🧐🤓😎🥳😏, a priori, no tiene penalización en el porcentaje de rebote así que los números montando un negocio con una página con el stack JamStack quedarían así.

Visitas	Rebotes	Usuarios interesados	Ratio conversión	Ventas	Beneficio mes
4.500	1.305	3.195	2%	6.390,00€	3.195,00€

Creemos que la diferencia es más que notable, entre 1.589 y 3.195 hay 1.606€.
¿Has pensado que puedes hacer con ese dinero extra al mes? ¿El coche de tus sueños? ¿La casita en la montaña? o incluso ¿Dejar el trabajo por cuenta ajena definitivamente?, si eres emprendedor part-time. Esos 1.600€ lo cambian todo.

¿Que ha pasado al cabo de 3 años?

Escenario A

Beneficios totales	Desarrollo web	Resultado final
57.234,60€	4.020€	53.214,60€

Escenario B

Beneficios totales	Desarrollo web	Resultado final
115.020,00€	5.200€	109.820,00€

Imagen de StartupStockPhotos en Pixabay

Son más de 50.000€. ¿Has pensado lo que te cuesta ganar 50.000€ como para perderlos por una decisión equivocada?

En este experimento no hemos tenido en cuenta el efecto que puede tener el hecho de contar con un diseñador profesional que cree tu propia imagen y se preocupe por la experiencia de usuario, en vez de usar una plantilla. Es un suma y sigue.

Recuerda: Good enough makes you poor

Por suerte para ti, en Nimbel somos expertos en webs, aplicaciones de alto rendimiento, aplicaciones móviles y en todo lo que la tecnología del software puede ofrecerte.
Contacta con nosotros y cuéntanos que quieres hacer y nosotros nos encargaremos de ofrecerte la solución que mejor encaje con tu proyecto. Tú éxito es nuestra misión.