Ayuda

Github, Next.js and Cloudflare Pages

The main purpose of this project is to have all Ayuda being generated throught the combination of:

• Github as both code repository and cms repository.
• Next.js as React framework to dinamically build static pages.
• Cloudflare Pages as static page deployer and server.

Github

At Github we wil have one or serveral private repos. On one hand, Frontend developers will create and maintain the code for a Next.js site. On the other hand, Content curators will create and maintain a collection of markdonwn files, each of one being the content of a single page in the Next.js site.

Next.js

On top of Next.js React framework, we will develop a common template to dinamically generate all the Ayuda. We will take into consideration to main stragegies:

• STG (Static Site Generation), throught getStaticProps. When exporting a function called getStaticProps from a page, Next.js pre-render this page at build time using the props returned by getStaticProps. Once the site is built, we take advantage of next export to output a complete static site that will be served from Cloudflare Pages.
• ISR (Incremantal Static Regeneration). Next.js allows us to create or update static pages after we’ve built our site. Incremental Static Regeneration (ISR) enables us to use static-generation on a per-page basis, without needing to rebuild the entire site. With ISR, we can retain the benefits of static while scaling to millions of pages. This strategy isn't available at the moment in CloudFlare.

Cloudflare Pages

At Cloudflare Pages we will create a project to deploy our front-end Next.js application and serve our static pages.

Cloudflare Pages will be responsible of "paying attention" about any change at our Github repos made by commits and automatically deploy a new version of our site.

One repo, two branches (at least). Two repos, two branches (at least).

Ayuda project could be approched as a single repo for both code and content or a two repos: one for code, one for content.

The most simple approach is everything being at one repo with two branches: main (the production site) and dev (the development site). In this approach both Frontend developers and content curators share a single code base. We all deploy to dev branch and once everything is ok, we merge to main. Each commit well be use to generate several versions of our development site, where we can test changes on both our template and on each single page.

On the other hand, we can have a separation of concerns: one repo responsible for the code and one repo responsible for the content.

In the code repo, we will have to branches: main (the production site) and dev (the development site). The main branch we'll have the production version of the template and the production version of the content coming from the content repo. The dev version we'll have the development version of the template and the preview version of each single page content, coming from the content repo. in order to get the contents of a file we'll use the Github API. For instance:

curl \ -H "Accept: application/vnd.github.v3+json" \ https://api.github.com/repos/octocat/hello-world/contents/PATH

The content repo we'll behave similarly. The main branch we'll have the production version of every single page content and the dev branch we'll have the preview version of every single page content.

Custom domains and redirects

At Cloudflare Pages we'll set 6 custom domains:

• static.deporvillage.com
• static.deporvillage.fr
• static.deporvillage.it
• static.deporvillage.pt
• static.deporvillage.de
• static.deporvillage.net

At Next.js we'll create dynamic routes with the following structure:

static-dpv.pages.dev/[:slug]

When a user request, for instance, https://static.deporvillage.pt/[:slug] will be serve from Next.js at static-dpv.pages.dev/[:slug], passing lang as a prop to layout, in order to achieve a structure like this one:

Header (Custom components' i18n DPV) + Content (parsed markdown file) + Footer (Custom components' i18n DPV)