![a](//images.ctfassets.net/lybfa03y94yw/5aipgcfbeKO4axygu3H3lj/746c2b1c14a92ebd075d24d10986ec24/github_and_maven__1_.jpg)
    <span>Photo by <a href="https://unsplash.com/@flowforfrank?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Ferenc Almasi</a> on <a href="https://unsplash.com/s/photos/programming-publish?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></span>

I recently published a post on how to record response time with wiremock. Later, I created a java library out of it and published it on Github. 

I wanted to go a step further and publish the build artifacts to maven central. Fellow developers can then use them without building from source code. Some changes were needed for the project to be accepted to maven central. This post summarizes these changes and the process of automation using Github Actions.

### Overall Process
The artifacts cannot be pushed to maven central directly. They first need to be deployed to the Sonatype OSSRH (OSS Repository Hosting) staging repository. Releasing from OSSRH to the maven central can then be initiated manually or via a maven plugin (more on that later). Before release, various checks are done against the project and artifacts to ensure they meet the standards of maven central. The artifacts are synced to maven central only if all the checks pass.

The detailed steps for meeting the standard and publishing are as follows. 

### 1. Create a project and request access to maven central.

Most importantly, you need an account, a project, and permission to publish to OSJRH. You will need to create an account on Sonatype JIRA and then request to create your project via a new JIRA ticket. You can also clone, edit and submit the Jira ticket I created - [OSSRH-64328][1].

The group-id should follow Maven naming conventions and be the reverse of a domain you own. For projects hosted on GitHub, it can start with `com.github` or `io.github`.

The folks at sonatype were very quick in their responses and asked to create a repository on GitHub with the Jira ID as the name to verify ownership of the GitHub account. Once ownership was verified, they quickly prepared the group for publishing and deployment to the staging repository. 

### 2. Signing Artifacts / GPG setup

One of the requirements is that the artifacts are signed with GPG. To do this, you first need to create a GPG key using the command 'gpg --gen-key' or tools like GnuPG. You will need to enter a few details and a passphrase to remember.

Once the keys are created, you need to sync the public keys with popular gpg key servers. You can synchronize the keys by retrieving the public key and then sending it to the keyservers.

Example:
<a href="https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=gpg.sh" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=gpg.sh</a>

Once the public key is sent to one of the keyservers, it is automatically, but not immediately, synchronized with the other keyservers. You can also send it manually to the most common servers instead of waiting for synchronization. The most common servers are:

hkp://pool.sks-keyservers.net  
https://pgp.key-server.io/  
https://keyserver.ubuntu.com/  
https://pgp.mit.edu/  
http://keys.gnupg.net/  

You can read more detailed instructions on the [sonatype page on pgp signatures][2].

Once the GPG key is created, you need to add the following plugin to your pom to sign the artifacts. 

<a href="https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=gpg-plugin-pom.xml" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=gpg-plugin-pom.xml</a>

The pinentry-mode=loopback specification is necessary for automated builds. It tells GPG not to ask for the passphrase to be entered manually. We'll see how to provide the passphrase when we set up GitHub actions.

### 3. Adding metadata to the POM

Artifacts must have a minimal set of metadata before they are eligible for release to Maven Central. The metadata includes fields such as developer name, SCM URLs, licenses, etc. You can find the full list and details on the [sonatype requirements page][3]. You can also reference the [pom of my project][4].

### 4. Generate JavaDoc and sources jar.

Maven central also requires us to generate the JavaDoc and sources jar for consumer use. This is mandatory for projects with a packaging type other than `pom`. You can generate this by adding and configuring their respective Maven plugins to your pom. 

<a href="https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=javadoc-source-plugin-pom.xml" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=javadoc-source-plugin-pom.xml</a>

You can also see the plugins section in my [project][4].

### 5. Prepare POM for deployment
You need to add the URL of the distribution repository to the pom of the project. In this case, we add the staging repository as the distribution repository.

<a href="https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=distribution-management-pom.xml" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=distribution-management-pom.xml</a>

By default, the staged artifacts must be manually from the sonatype next staging website. However, this can be automated by adding the `nexus-staging-maven-plugin` to the project pom. 

<a href="https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=nexus-staging-maven-plugin-pom.xml" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=nexus-staging-maven-plugin-pom.xml</a>

After the artifact is deployed to the staging repository, the plugin attempts to release the artifact. If any of the checks/requirements for release are not met, the build also fails. The plugin also outputs the list of unmet requirements.

### 6. Automate deployment to staging and release using GitHub Actions

I use GitHub Actions as a CI CD tool. The workflow code is as follows.

<a href="https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=release-action.yml" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/fab99a3db9e0cae020ce01b6ab749bb9?file=release-action.yml</a>

This workflow is triggered when I push a new tag. The workflow then builds the artifact, creates a GitHub release, and then deploys it to the staging repository. The 'nexus-staging-maven-plugin' added in the pom automatically releases the staged artifact when all checks pass.

The workflow requires a few secrets to be provided via the repository settings. More details can be found on the [GitHub action pages][5]. The following secrets need to be added.

__OSSRH_USERNAME__ : the username for the sonatype Jira login

__OSSRH_PASSWORD__: the password for the sonatype Jira login

__OSSRH\_GPG\_SECRET\_KEY__:  gpg private key ( `gpg --armor --export-secret-keys YOUR_KEY_ID` )

__OSSRH\_GPG\_SECRET\_KEY\_PASSWORD__ : gpg passphrase

### 7. Enable synchronization after first release.
This step is only needed on the first release. You need to inform the sonatype team via a comment on the project creation JIRA ticket when you release your first artifact. The sonatype team then enabled sync to maven central for the project. Once that is done, the artifact appears in maven central in about 10 mins and on the search page in a couple of hours.

---

The entire process for publishing on Maven Central seems long and complex, but most of these steps are one-time. Automating the rest with a CI CD tool makes publishing subsequent versions trivial.

You can reference my project [wiremock-extension-record-delay][6] for the complete setup.

[1]: https://issues.sonatype.org/browse/OSSRH-64328 "Sample JIRA ticket"
[2]: https://central.sonatype.org/pages/working-with-pgp-signatures.html "sonatype page on pgp signatures"
[3]: https://central.sonatype.org/pages/requirements.html#sufficient-metadata "sonatype requirements page"
[4]: https://github.com/anuragashok/wiremock-extension-record-delay/commit/11b6188041867dfaf936998e866cc08d7372e02d#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8 "example pom from my project"
[5]: https://docs.github.com/en/actions/reference/encrypted-secrets "GitHub action pages"
[6]: https://github.com/anuragashok/wiremock-extension-record-delay

I wanted to publish the build artifacts of my wiremock extension to maven central. Some changes were needed for the project to be accepted to maven central. This post summarizes these changes and the process of automation using Github Actions.

Publishing my first artifact to maven central using GitHub actions

![a](//images.ctfassets.net/lybfa03y94yw/67cLyOldHSrZ3p11WX9ydJ/e223e57b570f4ec54f62f1fec66002b9/Technology___Theory__1_.jpg)
    


[Wiremock][1] is a wonderful tool for mocking external dependencies for testing. I often swap out the external dependencies/services of an application with wiremock during the application load test. 

Wiremock provides a nice [recording/snapshotting][2] feature to capture live flows and create stubs from them. It simplifies the effort to create stubs for load tests. I run all my test cases once, record the interactions with dependencies as stubs. These stubs can then be used to perform the load test without invoking dependencies. 

I like Wiremock's answers to imitate the actual dependency, including the response time of the dependency. It will influence the statistics (e.g. thread waiting times) of the app under test. Wiremock, however, does not record the response time. I did not find any solution on the web, so I read through [wiremock documentation for extensions][3] and came with a solution. It may not be the best or the simplest, but so far it has worked out for me. 

The solution has three steps. 

1. Capture timestamp when the request has been received by wiremock. 
2. Capture timestamp when the response has been received by wiremock, from the backend system. 
3. Register the difference as delay in wiremock stubs. 

---

### 1. Capture timestamp when the request has been received by wiremock. 

Wiremock provides a RequestFilter to intercept incoming requests. The CustomRequestFilter below intercepts the request and records the timestamp as a request header. This header will be used in further steps.
<a href="https://gist.github.com/anuragashok/640e88d42b7ab7b69a40806f0002f337?file=CustomRequestTransformer.java" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/640e88d42b7ab7b69a40806f0002f337?file=CustomRequestTransformer.java</a>

### 2. Capture timestamp when the response has been received by wiremock from the backend system. 

After the response is received, wiremock runs ResponseTransformers on it. This CustomResponseTransformer below determines when the response was received. It then retrieves the start timestamp from the header added in Step 1. Then the transformer calculates the response time or delay and adds it as a header in the response. 
<a href="https://gist.github.com/anuragashok/640e88d42b7ab7b69a40806f0002f337?file=CustomResponseTransformer.java" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/640e88d42b7ab7b69a40806f0002f337?file=CustomResponseTransformer.java</a>

### 3. Record the difference as delay in wiremock stubs. 

Wiremock invokes StubMappingTransformer extensions, to modify StubMappings before they are saved. The CustomStubMappingTransformer below retrieves the delay from the response header added in Step 2. It then modifies the StubMapping to add the delay. The new StubMapping now has our desired request, response and also response time as a delay. 

<a href="https://gist.github.com/anuragashok/640e88d42b7ab7b69a40806f0002f337?file=CustomStubMappingTransformer.java" class="embedly-card" data-card-width="100%" data-card-controls="0">Embedded content: https://gist.github.com/anuragashok/640e88d42b7ab7b69a40806f0002f337?file=CustomStubMappingTransformer.java</a>

The 3 extensions previously created need to be registered with wiremock. Registration can be global or per-stub base. We have to register the delay only when proxying the request to a real backend. I was using the snapshotting method, therefore, extensions were registered only with the proxy stubs. If you use the new record feature, you could enable the extensions globally and add conditional logic inside the transformers.

Do [contact me][4], if there is a simpler solution or if you would like to discuss.

[1]: http://wiremock.org/ "Wiremock"
[2]: http://wiremock.org/docs/record-playback/ "recording and snapshotting"
[3]: http://wiremock.org/docs/extending-wiremock/ "Extending Wiremock"
[4]: https://www.linkedin.com/in/anurag-ashok/ "Contact me @ LinkedIn"

Wiremock provides a great recording feature to capture live flows and create stubs from them. These stubs can then be used to perform the tests without invoking dependencies. I like Wiremock's answers to imitate the actual dependency, including the response time of the dependency. Find out how wiremock can do that.

Capture response time in wiremock recordings

![a](//images.ctfassets.net/lybfa03y94yw/31kEfTG8wIqkq8mixJ9skZ/6d86d7f4d0c700179d8eae5b31e01766/Untitled_design.jpg)
    Photo by [Pixabay](https://www.pexels.com/@pixabay?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) from [Pexels](https://www.pexels.com/photo/business-coffee-composition-computer-265667/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)

Docker/Containers have become the de facto standard for building and deploying applications. The isolation, portability and easy scaling capabilities of containers make them the popular choice for app deployments.

However, containers are not only for application deployments but can also be for local development. They can solve many developer issues. The use of Docker containers during development can have the following advantages.
- runs on my machine = runs anywhere
- there are no cumbersome configuration/version incompatibilities
- The development environment is closer to production
- easy onboarding of new developers

Let's see how I use Docker for the development of this blog. 

## Base Image
TheOverEngineeredBlog is built on next.js which needs node. Also, the package manager of choice is yarn. The official node image on docker hub is [here][1]. It includes yarn too. This blog uses `node:lts` image to get the latest lts version of node.

## Docker Compose
I created a docker-compose.yml file at the root of the project to define the entire container configuration and add more containers if necessary later.

###### docker-compose.yml [View on GitHub][2]
```yaml
version: '3.7'

services:
  runner: 
    image: node:lts
    ports: 
      - "$PORT:3000"
      - "$DEBUGPORT:9229"
    volumes:
    - .:/app:cached
    - yarn-cache-volume:/usr/local/share/.cache/yarn/v6:cached
    working_dir: /app
    command: "$COMMAND"

volumes:
  yarn-cache-volume:
```

The compose file defines a service named `runner` using the base image "node:lts".

The `ports` section instructs Docker to expose ports 3000 and 9229 at $PORT and $DEBUGPORT on the host. PORT and DEBUGPORT are environment variables to configure the desired ports on the host.

The `volumes` section defines mounts and named volume. The root directory of the project is mounted to `/app` inside the container. Also, it defines a named persistent volume for yarn cache. Docker manages this volume and persists it through the container stop/start. This cache reduces yarn execution time next time the container starts.

`working_dir` set the current directory to `./app` to avoid changing the directory each time the container starts.

`command` is set to an environment variable $COMMAND. It can be supplied when invoking docker-compose.

## RUN script

I like to have a `run` script to spawn the container using docker-compose to avoid writing the same commands each time. 

###### run [View on GitHub][3]
```bash
#!/bin/sh
export PORT=${PORT:-3000}
export DEBUGPORT=${DEBUGPORT:-9229}
export COMMAND=${@:-"yarn dev"}
EXISTING_CONTAINER_ID=""
if [ -n `docker-compose ps -q runner` ]; then
    EXISTING_CONTAINER_ID=`docker-compose ps -q runner`;
elif [ -n `docker ps -q --no-trunc | grep $(docker-compose ps -q runner)` ]; then
    EXISTING_CONTAINER_ID=`docker ps -q --no-trunc | grep $(docker-compose ps -q runner)`;
fi

if [ -z $EXISTING_CONTAINER_ID ]; then
  COMMAND=${@:-"yarn dev"} docker-compose run --service-ports --rm runner
else
  echo "Existing container ${EXISTING_CONTAINER_ID}"
  docker exec -it ${EXISTING_CONTAINER_ID} ${COMMAND}
fi
```

The script is executed like this.

```bash
[PORT=<desired port on host> DEBUGPORT=<desired debug port on host>] ./run [<command>]

DEFAULTS PORT=3000 DEBUGPORT=9229 COMMAND="yarn dev"
```

Sections in `[]` are optional and have defaults set.

To start the application, I need to write `./run` on the shell. It starts the container, exposing the ports 3000 and 9229 on the host and then runs `yarn dev` inside the container.

![Sample Output][4]

Any command can be executed inside the container by prefixing it with `./run`
E.g. To add a package, run `./run yarn add some-package-name`

You could also do `./run bash` to get a bash shell attached to the container. This bash shell can be used to execute commands inside the container without the prefix './run'

The script also checks if a container is already running for the application and reuses the container to execute the command. Credits to [this answer on ServerFault][5] 

We can also write a similar script for windows machines using cmd/PowerShell.

This setup has helped me enormously. I don't have to worry about installing different versions of node/java/python etc. Besides, now the only dependency for local development is, Docker!

[1]: https://hub.docker.com/_/node "Official Node DockerHub Image"
[2]: https://github.com/anuragashok/theoverengineered.blog/blob/d784e3e072e19ae753cbe3fd39c64de86388e851/docker-compose.yml "View on Github"
[3]: https://github.com/anuragashok/theoverengineered.blog/blob/d784e3e072e19ae753cbe3fd39c64de86388e851/run "View on GitHub"
[4]: https://theoverengineered.blog/docker-local.jpg
[5]: https://serverfault.com/a/935674/130937 "Check if container running"

Containers are not only for application deployments. They offer many advantages for local development too. Find out how theOverEngineeredBlog uses Docker for local development.

Use Docker for local development

![a](//images.ctfassets.net/lybfa03y94yw/3IejIjMkhHCU5xGOwXuW5o/6e1c1a898cbcde31682db277183fba0b/GENERATE_RSS_AND_SITEMAP.png)
    Image by <a href="https://pixabay.com/users/mohamed_hassan-5229782/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=4059862">mohamed Hassan</a> from <a href="https://pixabay.com/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=4059862">Pixabay</a>

RSS and sitemap are essential for blogs today. RSS Feeds let users subscribe to your content and improves user engagement. On the other hand, a sitemap is for search engines to find and index your content. 

When using a CMS like wordpress etc.., the RSS and sitemap XML files are generated at runtime. However, for JAMStack websites, we would like to create them at the build stage. I was not able to find an OOTB solution for next.js to create these files. The XML files for RSS and sitemap are not too complex to generate. Hence, I decided not to introduce any third-party dependencies to generate these files.

There are mainly three questions to answer when generating these files. Where, When and How?

## 1. Where to place 

The convention followed by many is to place rss.xml and sitemap.xml at the root of the website. Sitemaps can be split into files and referenced from the main sitemap.xml. This is needed when sitemaps grow very huge. We will stick to single sitemap.xml for now.

Next.js routing does not support files that are not content. So, what we can do is, to place these files in the `public` directory. Next's static file serving feature serves the files under this directory at the root of the website.

## 2. When to generate 

We have to generate the files inside the public directory during the build. During the build, the `getStaticProps` function gets invoked for each page. We can leverage this function to create our XML files.

We can use `getStaticProps` function of any page component to create the files. However, this will add unnecessary code to the pages. So, I created a dummy.tsx page. The `getStaticProps` of this page component will contain the additional build time processing logic.

If anyone visits /dummy we should probably return 404 and ignore the page from any search engine indexing. 

###### dummy.tsx [View on GitHub][1]
```jsx
const Dummy: React.FC = () => (
  <>
    <Head>
      <meta name="robots" content="noindex" />
    </Head>
    <DefaultErrorPage statusCode={404} />
  </>
);
```

## 3. How to generate 

The creation of XML files is a matter of iterating over the content and generating the XML tags. This can be implemented in the `getStaticProps` function of `pages/dummy.tsx`. You can find the snippets of the code below. You can refer to GitHub repo for this blog for the full code sample. 

###### dummy.tsx - getStaticProps() [View on GitHub][2]
```javascript
export const getStaticProps: GetStaticProps = async () => {
  const posts = await getPosts();
  generateRss(posts);

  const pages = await getAllContent();
  generateSitemap(pages);

  return {
    props: {},
  };
};
```

###### generateRss() [View on GitHub][3]
```javascript
const generateRssItem = (post: Post): string => `
  <item>
    <guid>${getFullUrl(`blog/${post.slug}`)}</guid>
    <title>${post.title}</title>
    <link>${getFullUrl(`blog/${post.slug}`)}</link>
    <description>${post.description}</description>
    <pubDate>${new Date(post.publishDate).toUTCString()}</pubDate>
  </item>
`;

export default (posts: Post[]): void => {
  const rss = `<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>${SITE_TITLE}</title>
      <link>${getFullUrl('')}</link>
      <description>${SITE_TITLE}</description>
      <language>en</language>
      <lastBuildDate>${new Date(posts[0].publishDate).toUTCString()}</lastBuildDate>
      <atom:link href="${getFullUrl('rss.xml')}" rel="self" type="application/rss+xml"/>
      ${posts.map(generateRssItem).join('')}
    </channel>
  </rss>`;
  fs.writeFileSync('./public/rss.xml', rss);
};
```

###### generateSitemap() [View on GitHub][4]
```javascript
export default (pages: Content[]): void => {
  const links = compose(map(mapToSitemapEntry))(pages);

  if (fs.existsSync(SITEMAP_PATH)) {
    fs.unlinkSync(SITEMAP_PATH);
  }
  const stream = fs.createWriteStream(SITEMAP_PATH, { flags: 'a' });
  stream.write(`<?xml version="1.0" encoding="UTF-8"?>
  <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">`);
  links.forEach((item) => {
    stream.write(`
      <url>
        <loc>${item.url}</loc>
        <changefreq>${item.changefreq}</changefreq>
        <priority>${item.priority}</priority>
      </url>`);
  });
  stream.write('\n');
  stream.write('</urlset>');
  stream.end();
};
```

You can later validate these xml files against the specs at [W3C Feed Validator](https://validator.w3.org/feed/ "W3C Feed Validator") and [XML Sitemap Validator](https://www.xml-sitemaps.com/validate-xml-sitemap.html "XML Sitemap Validator")

[1]: https://github.com/anuragashok/theoverengineered.blog/blob/1b1f462a7cb697ecdcd222313d913101de176dfa/src/pages/dummy.tsx#L15-L22 "View on GitHub"
[2]: https://github.com/anuragashok/theoverengineered.blog/blob/1b1f462a7cb697ecdcd222313d913101de176dfa/src/pages/dummy.tsx#L24-L34 "View on GitHub"
[3]: https://github.com/anuragashok/theoverengineered.blog/blob/1b1f462a7cb697ecdcd222313d913101de176dfa/src/lib/rss.ts "View on GitHub"
[4]: https://github.com/anuragashok/theoverengineered.blog/blob/1b1f462a7cb697ecdcd222313d913101de176dfa/src/lib/sitemap.ts "View on GitHub"

RSS and sitemap are essential for blogs today. RSS Feeds let users subscribe to your content and improves user engagement. On the other hand, a sitemap is for search engines to find and index your content. Let's see how to generate these in a Next.js JAMStack site.

Generate RSS and Sitemap for Next.js JAMstack site

![a](//images.ctfassets.net/lybfa03y94yw/6I30Ej62DPAl0qK3HVt38B/8e0334362cb4a2c30ffc1bb1471606d9/intial-post.jpg)
    Photo by [Pixabay](https://www.pexels.com/@samuel-wolfl-628277?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels) from [Pexels](https://www.pexels.com/photo/intermodal-container-stacked-on-port-1427541/?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels)

Taking a cue from [Initial Commit][1], I decided to name this first post as Initial Post.

I created this blog from scratch as I wanted it to also be a learning experience. This has become my hobby project where I experiment with new tools and technologies.

[Jamstack][2] is very popular these days. So decided to build this site using Jamstack practices. This post summarizes the various parts of the Jamstack eco-system used on the site. 

*   **Presentation Layer:** ReactJS has been on my learning list. The most popular starting points for ReactJS are create-react-app and Next.js. I eventually decided to use Next.js as it provides server-side rendering, static-site generation and serverless functions out of the box. The features can help to get the site up quickly.

*   **API:** The site does not need an API at the moment. However, Next.js provides a [straightforward solution][3] to create APIs too.

*   **VCS:** Github.

*   **Hosting / CDN:** The site runs on Github pages. It's free and fast. It provides all the features needed for now. However, I would also like to try out services like Netlify.

*   **Backend:** At the moment, the site can compile to static HTML. So I am deferring this decision until the time I need a backend.

The overall architecture of the site looks like this.

![Intial Architecture][4]

### References:

*   https://medium.com/@gianfranconuschese/the-jamstack-return-of-the-server-side-rendering-5a1313dafc92
*   https://nextjs.org/docs/api-routes/introduction
*   https://dev.to/eroberts/why-you-should-use-netlify-instead-of-github-pages-3on1

[1]: https://initialcommit.com/blog/What-Is-An-Initial-Commit-In-Git "What is initial commit?"
[2]: https://medium.com/@gianfranconuschese/the-jamstack-return-of-the-server-side-rendering-5a1313dafc92 "Jamstack"
[3]: https://nextjs.org/docs/api-routes/introduction "NextJS solution for API routes"
[4]: /diagrams/initial-post.svg

Jamstack is very popular these days. I decided to build this site using Jamstack practices. This post summarizes the various layers of the Jamstack eco-system used on this site.