Blog

Production Site (frontend)

• blog-nandotess.vercel.app

Production CMS (backend)

• admin-nandotess.vercel.app

Database Project

• Repository: https://github.com/nandotess/Blog-Database
• Sanity.io (headless database)
• Node.js (content modelling)

Backend Project (CMS)

• Repository: https://github.com/nandotess/Blog-Backend
• Vercel (cloud hosting)
• Node.js (communication with the database and SSR)
• React
• Next.js (React Framework)
  • GROQ (communication with the database - GET)
  • REST API (communication with the database - POST, PUT and DELETE)
  • SSR (Server Side Rendering)
• Material-UI (React UI framework)

Frontend Project (Blog)

• Repository: https://github.com/nandotess/Blog-Frontend
• Vercel (cloud hosting)
• React
• Next.js (React Framework)
  • GROQ (communication with the database - GET)
  • SSG (Incremental Static Generation)

Notes

• The main benefit to having the 3 applications running in different servers with different URLs is the possibility to restrict access (improving security). On the backend application (CMS), we could restrict access to it using a VPN, for example. For now, we are using SSO (Google). On the frontend application (Site/Blog), the database is currently only accessible on the server, so the URL and any other sensitive data are already hidden from the final user.

• Sanity.io is used as the database source for a few reasons:

  • It's a cloud solution with a generous free tier.
  • Easy to create new datasets and models with no UI, only using JavaScript and terminal.
  • They offer a query language (GROQ) similar to GraphQL but with more resources. The main benefit from GROQ (as well as GraphQL) is the possibility to get data with relationships in one single query (different from the REST API specification).
  • All the images stored in their servers have CDN ready to go.
  • It's possible to have custom tokens for each application. Currently, there is a token for the site/blog (READ) and a token for the CSM (READ + WRITE).

• Next.js + Vercel was the combination chosen for the frontend application (Site/Blog), among other things, because it delivers a powerful combination of Server Side Rendering and Static Generation. With the Incremental Static Generation, it's possible to have the static pages generated with a revalidation of the content pretty generous (the current configuration is set to one minute, that means all the content updated on the CMS will be live to the user, not more than 1 minute later). On top of that, all this static content is stored in Vercel's CDN.

• Next.js + Vercel + Material-UI was the combination chosen for the backend application (CMS), among other things, because it delivers a powerful set of components ready to go. Authentication, Grids, Forms, ... there are many resources that make the creation of a CRUD system easy, so we can focus only on the business rules and not standards already defined by the industry.