The landscape of Web dev tech has been oscillating between the "all server" and "all client" models, with each phase presenting its unique set of advantages and challenges. Now, this swinging pendulum is losing momentum and reaching a point of equilibrium (_how did I manage to write three Latin words in 1 sentence?_). Where's this equilibrium happening? At the center, obviously. Where is the center, though? **At the edge**

The latest innovations introduced by React-based frameworks such as Next.js and Remix and cloud platforms such as Vercel and Netlify are giving birth to a groundbreaking architectural hybrid model. This architecture is The Frontend Cloud, and it leverages the advancements in Edge Cloud computing and Content Delivery Networks (CDNs) to enhance Web development capabilities significantly. Concretely speaking, The Frontend Cloud leans on the CDN's new computing and storage capabilities, something unimaginable until very recently.

In this post, I will delve into the intricacies of thi model and analyze its potential in reshaping the web development domain.

## The Foundation: Edge Runtimes and CDN

Edge Computing and CDNs are at the core of the Frontend Cloud model, which represents a significant departure from traditional cloud infrastructure running in data center regions. Edge computing enables the execution of server-side logic closer to the end-users in **geographical edge regions**, substantially improving response times and reducing latency. 

However, edge _the location_ is less important than edge _the runtime_ when it comes to this idea of the Frontend Cloud. Therefore, most Cloud Computing providers allow developers to run workloads on *edge runtimes*. These are basically Javascript runtimes, such as V8, Node.js, or [Deno](https://deno.com/deploy). Why is that? Well, there are many reasons, but performance and security are chief among them:

1. For example, the V8 JavaScript engine supports the concept of "isolates," which are separate instances of the V8 runtime that share no memory or resources with each other. This isolation significantly reduces the risk of cross-script vulnerabilities, data leaks, or unauthorized access to sensitive information.
2. Running JavaScript in isolated sandboxes allows granular control over resources and permissions. Developers can explicitly define the resources, data, and I/O API access available to each sandbox, limiting the potential impact of security vulnerabilities or breaches
3. JavaScript is inherently suited for handling event-driven and non-blocking I/O operations, thanks to its asynchronous nature and single-threaded execution model. These characteristics make JavaScript an excellent fit for edge computing scenarios, where efficiently handling multiple concurrent requests is critical to achieving low latency and high performance.
4. WASM 😇

This ability to perform computations at the edge of the network, coupled with the dynamic content delivery capabilities of CDNs, has contributed to the genesis of the Frontend Cloud model.

Notable platforms like Cloudflare Workers and Vercel Edge Functions have already demonstrated the potential of the Frontend Cloud model with cool features such as [HTTP Streaming, which, in combination with React's Supense API and Server Components](https://beta.nextjs.org/docs/data-fetching/streaming-and-suspense), are paving the way for the development of lightning-fast, resource-efficient web applications. Moreover, the Edge now supports ephemeral storage through Key-Value (KV) objects, further extending the server-side logic capabilities to run even more complex business logic!

## The Limitations of Current Edge Technologies

Despite the numerous advantages of the Frontend Cloud model, we need to be aware of a good number of limitations. One key issue I see is the absence of global replication for KV objects. At present, KV objects are localized to the edge location, restricting their utility for global use cases. However, the introduction of solutions such as Cloudflare's Durable Objects seeks to address this challenge by offering global replication, although the technology is still in its infancy. Overcoming these limitations will be crucial for the widespread adoption of the Frontend Cloud model.

The rapid evolution of Edge Cloud computing and the introduction of the Frontend Cloud architecture suggests that web development will continue to experience remarkable transformations in the coming years. I am very excited about solutions like [Redis on the Edge Runtime](https://upstash.com/blog/redis-cloudflare-workers) or even [Neon Database](https://neon.tech/), which opens the possibility of performing PostgreSQL read/write operations on the Edge, something that could happen within the next few years. Such advancements would pave the way for the development of web applications with greater flexibility, reliability, and performance.

As the Frontend Cloud model evolves, we can anticipate the creation of new web development tools and technologies that streamline the development process. Real-time data synchronization and adaptive server-side rendering are just a few examples of the innovations that will emerge from this new paradigm. Consequently, web applications will become increasingly versatile, allowing seamless operation across multiple devices and platforms.

## Conclusion 
Despite the promise of the Frontend Cloud model, several challenges must be addressed before it can achieve its full potential. Latency, data consistency, and security concerns are among the most pressing issues that need to be resolved to ensure the successful adoption of the Frontend Cloud model. As innovators in this emerging field, it is imperative that we collaborate and share our collective knowledge to tackle these challenges and unlock the true potential of the Frontend Cloud.

The Frontend Cloud model, with its unique fusion of server and client-side capabilities, has the potential to revolutionize the web development landscape. By harnessing the power of Edge Cloud and CDNs, web developers can create high-performance, adaptive, and immersive experiences for users across the globe. As the limitations of the current Edge technologies are addressed and overcome, the Frontend Cloud model will continue to mature and reshape the boundaries of web development.

Look at the following piece of code using Next.js and Planetscale:

![Ftsg2ipWIBs3Nbd](https://user-images.githubusercontent.com/3844521/232325892-0467caf7-afaa-48ef-8dcf-ac6733897814.jpeg)

Looking closely at the code, you may think we are reinventing PHP. However, I like to see this differently. Indeed the server-side code looks like PHP, and the client-side code looks like a SPA. But isn't that the magic? I love how I can combine server efficiency and client reactivity in one app.


The Frontend Cloud

This is a short post.

The theory of [Wardley mapping](https://learnwardleymapping.com/) talks about how things get a new meaning as they evolve.

- DevOps does not mean the same in 2023 as in 2013
- Cloud does not mean the same in 2023 as in 2010
- Platform does not mean the same in 2023 as in 2000
- Serverless does not mean the same in 2023 as in 2016

So let me go back to some basics.

## What is the cloud?
The concept of the cloud started as industrialized, interoperable, and commoditized infrastructure services built on standards and distributed over the wire to users. Today, [the definition of modern cloud ](https://theserverlessedge.com/introduction-to-the-modern-cloud/) expands to include the idea of a system made of services, features, and principles that work in harmony to allow users to _build the thing right_. With this definition, the value proposition of cloud platforms is about meeting business leading goals such as speed of development, reliability, security, agility, and efficiency. 

In 2023, we have three different levels of services offered by cloud platforms:

- **Infrastructure services**: this collection of services and features are basically VMs offered as a service. Example: Amazon EC2

- **Runtime services**: this collection of services and features are runtimes offered as a service. Example: AWS Lambda.

- **Application services**: this collection of services and features are applications offered as a service. Example: Salesforce CRM.

The thing is that, in 2023, you don't need to own a data center and distribute infrastructure as pay-per-use services to be a cloud provider:

- [Fly.io](https://fly.io/) is a cloud provider of infrastructure services
- [Vercel](https://vercel.com) and [Supabase](https://supabase.com/) are cloud providers for runtime services
- [Atlassian](https://www.atlassian.com/) is a cloud provider of application services

## What is content?
Content is the collection of things that platform users own and put in the platform to _build the right thing_. Content's value proposition is about meetings meeting business lagging goals such as growth, revenue, and customer satisfaction. In other words, content is defined by what the user owns on the platform.

We have different types of content depending on the services:

- **For infrastructure services**: the user owns the runtimes, code, and data.

- **For runtime services**: the user owns the code and data. 

- **For application services**: the user only owns the data.

## What is serverless, then?
The concept of serverless started as _on-demand functions_ thanks to services to Google AppEngine and AWS Lambda. Today, we can find complex definitions that include a combination of _Functions as a Service_ and _Backend as a Service_, especially since the introduction of serverless containers. To me, the concept of serverless in 2023 evolved to **runtimes as a service** that scale to zero where users own the code and the data. It is that simple.

So, the moment I see a new service out there, I ask myself two questions:
- What do I own? This will define my focus
- How does it scale? This will define my operational burden

Depending on the answer to these two questions, I mentally categorize the type of platform I am working with. The moment I own code and data and the service scales to zero, I know I am using **Runtime as a Service**, and I am conscious of my duties, including what I am responsible for upgrading and maintaining! Some people call this serverless 🫠

It's time to rename serverless

## Different rendering options

It appears to me that making architectural decisions for Web development is more complicated than ever due to the emergence of frameworks that bake in client/server tradeoffs. Yes, I am thinking of [Next.js](https://nextjs.org/) or [Remix](https://remix.run/), which offer different rendering options for different use cases. In any case, there is a lot of information out there to help Web developers make informed decisions.

Typically, Web developers solve these tradeoffs and pick one rendering method or another driven by a combination of data and user experience requirements:

- **Static Site Generation (SSG)**: Pages of your Web App / Site are generated at build time. It helps build sites, such as information portals or news sites, when data is not changed or updated frequently. Frameworks like Next.js support features such as [Incremental Static Regeneration](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration), which means that the static site is regenerated **on the server** automatically based on a schedule configured by developers.

- **Server-Side Rendering (SSR)**: Content of your Web App / Web Site is generated dynamically on a request basis. This rendering solution is most appropriate for data-intensive scenarios where content is updated frequently, it is very large, access latency is critical, or complex processing and transformation are needed before returning the response to the client.

- **Client-Side Rendering (CSR)**: The data displayed on your Web App / Web Site is served through an HTTP API and rendered by the client on the browser. To improve the performance time at the client device, this data must be lightweight and ready to be consumed without further processing. This approach can help in those cases where user interactions and state management of the user interface need to happen as close to the user as possible to offer a very interactive and reactive user experience.

However, modern deployment options have additional non-functional requirements (NFRs). I am talking about NFRs, such as an extra twist in performance, cost implications, and environmental impact. These are things that nowadays Web Developers need to consider when making these architectural decisions.

## The battle on the server-side

I believe the discussion and debate around what rendering mechanism is better are conceptually wrong. It may lead you to pick up the wrong framework after all!

The actual tradeoffs and the honest discussion should be around architectural patterns such as JAMstack (i.e., no server-side logic) vs. Fullstack (i.e., server-side logic). When you focus on the architectural style and not the rendering mechanism, you'll see it more clearly as you look at the problem from a more accurate prism. At the end of the day, you can do SSR with JAMstack, but it just happens at build time! Also, you can do SSG with Fullstack if you play with the `stale-while-revalidate` cache header as Remix does.

Why are Web development teams shifting to the server side again? The answer is because of the commoditization of infrastructure and **serverless**. It is now easier than ever to have backend computing for your Web applications and sites.

>"_Higher-order systems create new sources of value_" - Simon Wardley

We now count on an extensive catalog of managed cloud services and pure serverless primitives. There is a battle in this server-side space between second-tier cloud platforms such as Vercel or Netlify (they don't own Datacenters) and first-tier cloud ones such as Cloudflare and AWS (they own Datacenters). They all compete with each other to offer the best Web developer experience and optimize those new NFRs. 

Especially for first-tier cloud platforms, this battle is making innovations spring at a pace we have never been before, especially with the emergence of **Edge Computing** solutions.

JAMstack was introduced as a _workaround_ under certain infrastructural assumptions, advocating the separation of server-side stuff from pure Web development for performance and UX reasons. The world has changed, and Edge Computing is breaking those initial assumptions!

I mean, you don't need full round trips to the cloud region to obtain data. You can now serve it from the CDN or even run pieces of logic on edge. That gives you speeds and UX for dynamic Web Apps similar to static sites.

[As I wrote in the past](https://dev.to/peibolsang/the-future-of-cloud-computing-is-developer-experience-g0p), computing at the edge is not about CDNs and caches anymore; this is something else. We are now talking about moving part of our applications and services to an edge location. An edge location is where cloud providers cache content so that it can be very quickly accessed by local referrers. It also allows local access to the cloud platform's network backbone, avoiding the public internet between the edge location and the regional data center from where content originates.

At the edge, client requests and application logic can be processed and executed without sending that request to a service running on the origin cloud region. Of course, this approach still qualifies as serverless because you don't need to provision or manage any type of runtime. Additionally, this approach comes with further benefits, such as global distribution and automatic multi-region access for your applications out of the box.

## Edge Computing use cases

Okay, then, how does edge computing help Web development? I think it can make it better, faster, and cheaper with solutions that help and support the Javascript development community. Solutions such as [Cloudflare Workers](https://workers.cloudflare.com/) (or [Cloudflare Page Functions](https://developers.cloudflare.com/pages/platform/functions)) are very comfortable for Web developers as they offer the same native Javascript APIs that developers are used to working within the browser. It's a very natural ecosystem for them.

In its current form, I would choose Edge Computing services only as an add-on layer on top of my server-side components running at the cloud origin for very concrete use cases:

1. **Data Filtering**: Filter data coming from the application components before sending a response to the client. This can be done based on user-specific criteria such as location or device type. The goal is to avoid data processing and filtering as much as possible in the browser so that it can receive ready-to-render data.
2. **Stateful Requests**: Combined with lightweight storage at the edge (e.g., Key-Value stores), we could handle sophisticated states on edge on top of the application running on a serverless environment. And we could do it without firing full round trips to the cloud origin region. This would allow Web developers to build session-based online collaboration tools (e.g., Miro dashboard) on serverless computing.
3. **Authorization**: Apply Role Based Access Control rules to UI components returned to the client. Imagine you are including an Admin section in your UI, which options are affected by the user's role. Filtering those UI options at the edge would be a cost-effective and high-performant solution.
4. **Cyber-protection**: Use native cybersecurity features and APIs at the CDN to identify networking patterns such as bot detection and apply URL redirects to avoid exposing the application code running at the cloud region to malicious agents. Also, I've seen edge functions used to prevent _clickjacking_ or _XSS_ attacks by [adding security headers to the response](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-security-headers.html).
5. **Performance**: Remember that edge computing providers own cache data centers worldwide, so I am sure there is one close to your location right now. This allows them to implement powerful caching mechanisms to improve TTFB for static content (HTML, CSS, Javascript bundles) and other techniques, such as image resizing optimization based on user devices. 

## Conclusion

These use cases can be game-changing, especially for Javascript developers building Web applications. Solutions like Cloudflare Workers are based on [Google's V8 engine](https://v8.dev/), allowing response times for client requests under 50ms (i.e., full round-trip, not just internal execution time). Then, as described above, the main logic for the server-side components would run entirely on the cloud region, with a preference for serverless components. But who knows, maybe edge computing will evolve to the point where we can run larger pieces of business logic closer to the user location.

I am getting my hands dirty with a few of Cloudflare's solutions right now, so in my next post, I will cover in detail a few of their most compelling edge computing services. Follow me on [Twitter](https://twitter.com/peibolsang) to keep the conversation going!



How Edge Computing can make the Web better

I heard multiple times Simon Wardley talking about [Conversational Programming as far back as 2019](https://twitter.com/swardley/status/1102889853954478080?s=20&t=8URYAKOdTYQ1kMx1ZCw1Tw), but I think it didn't strike me until I put my hands on it. Yes, as I have shared in this post, [I used ChatGPT to generate about 30%-40% of the code I wrote for octotype](https://octotype.vercel.app/peibolsang/stories/2), and I am still in awe.

Something I noticed is that the model behind ChatGPT is _good enough_ to interpret semi-ambiguous requirements but still needs a considerable deal of *detailed* input that expresses my intent. The same happened when [I re-trained a Stable Diffusion model with selfies to generate cyberpunk-like portraits of myself](https://twitter.com/peibolsang/status/1606318579506454528?s=20&t=RK9Mnof0VooVX8wSUScJHA). That type of thought process to express intent and reduce uncertainty in the input is what many people call **Prompt Engineering**. However, I think this is precisely what Simon Wardley calls **Conversational Programming**.

In other words, Prompt Engineering looks a lot like Programming. When you are programming, there is a process to remove ambiguity and uncertainty, so your intent is understood by the machine, and you express that intent in a language that the machine understands, such as Javascript. Well, that's precisely what we are doing with these AI models, but instead of using a 4GL programming language, we are using our Natural Language.

I said it multiple times, but when you automate something (with AI or otherwise), you are actually **constraining that something with automation**, and you can only constrain something with very low levels of uncertainty. Unfortunately, high-level business requirements to create software are not something that you can automate in full. You still need a process to remove ambiguity and express your intent, and you need to do it iteratively.  You still need to divide and break down your big _uncertain problem_ into smaller, more certain chunks expressed in natural language. Basically, you are programming conversationally.

Maybe, in time, these models get more intelligent so that they offer higher-level abstractions for us to ease the process of removing ambiguity and expressing intent. That is precisely what happened when we moved from assembly to Java! In other words, we may be at the doorstep of a new generation (5GL) of programming languages based on problem-solving using constraints given to the machines rather than commands.

Conversational Programming

This is the story of how I made this site, [octotype](https://octotype.app).

First of all, being a lousy programmer as I am, I wanted to minimize damage and use a stack that maximizes the developer experience. For me, a good developer experience creates spaces for you to focus on fixing the business problem at hand. It's not about magic tools that do hundred of things. That's why the following stack fits the bill for me:

-  **GitHub Issues as CMS** 📚. GitHub's Issue management system gives me all I need to create and manage content behind the scenes. I am very familiar with it, and it's easy to use, widely adopted, and has an out-of-the-box API with a good free tier. It's just perfect!
-  **Next.js with the Blog template** ✍🏻. My new blog site is leaning heavily on this template, and I only added a few new types, components, and UI functionality to fetch data from GitHub through its API, such as issues (as posts), comments, and reactions. Of course, it's a statically generated site, but I have used [Incremental Site Regeneration](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration), so new issues created in GitHub Issues show up as blog posts after a very short while. It's just perfect and lightning-fast. And ISR even works with dynamic paths!
- **Typescript** 💻. I feel very comfortable programming with types. I think it forces you into a kind of healthy DDD thinking and way of programming.
- **Vercel as frontend platform** 🚀. [Nothing to add, you know I am in love with Vercel](https://peibolsang.vercel.app/posts/2)
- **OpenAI** 🤖. Down below, I share 8 times ChatGPT saved my ass. I am still in absolute awe.

Wait, OpenAI? For what? Well, building the whole new site took me about two (2) days. Seriously. It may not sound like a lot to you, but it's a remarkable achievement for someone like me who does not code daily. I have used it extensively to customize the app created from the Next.js template, and ChatGPT helped me to write Tailwind, Typescript, and other Next.js code when I hit a wall. This was one of the main reasons I wanted to build my own site: I felt capable of doing something like this in a reasonable amount of time with this tool. Based on my comments about the developer experience above, I can say that ChatGPT provided me with an **Augmented Developer Experience**.

## The frontend work
The octotype site is 100% pre-rendered, which gives us an optimal user experience with a **super fast site**. This means that the landing page, every user page, and every blog post are pre-rendered on the server using Next.js ISR with an interval of `120` seconds. The data in these pages are generated by fetching the content directly from the GitHub API.

Using Next.js, I managed to maintain simple **yet dynamic URL routes** like `/:username/stories/:number`. Next.js provides a beautiful out-of-the-box feature to help implement this use case where you need to handle combinatorial paths, and it's called [optional catch-all routes](https://nextjs.org/docs/routing/dynamic-routes#optional-catch-all-routes). Using this feature, I could have added a `[[...slug]].tsx` file to _rule them all_, and that would have helped me catch routes such as:

```
- /
- /peibolsang
- /peibolsang/stories
- /peibolsang/stories/1
```

However, since optional catch-all routes are implemented in one TSX file, this would have forced me to implement different layouts on one page with a lot of conditional logic to render different large UI components for each layout. What did I do instead? I didn't know it until I googled it, but you can actually apply [catch-all routes](https://nextjs.org/docs/routing/dynamic-routes#catch-all-routes) to folder names, too, as long as you include an `index.tsx` file under that folder. In other words, `[username].tsx` is the same as `[username]/index.tsx` 🤷🏻‍♂️. This allowed me to create the following folder structure where I can pre-render every page using `getStaticProps` and `getStaticPaths`:

```
- pages/index.tsx
- pages/[username]/index.tsx
- pages/[username]/stories/[slug].tsx
```

This also gives me some future proofing, just in case I want to switch from pre-rendering using `getStaticProps` to SSR using `getServerSideProps` for some of the pages. Why would I want to do that?  Keep reading 😂

## Using GitHub's API
This MVP of octotype uses the GitHub API free tier, [which has a rate limit of `5000` calls per hour](https://docs.github.com/en/developers/apps/building-github-apps/rate-limits-for-github-apps#default-server-to-server-rate-limits-for-githubcom). Why did I choose this? Let me put some use cases based on how the octotype site is designed (i.e., how the app calls the GitHub API in the `getStaticProps` and `getStaticPaths` functions):

 - **Scenario 1**: `10` octotype users with `5` posts each with a site regeneration every `120 seconds` will fire about `3900` API calls. This is still reasonable and within the API rate limits, and we can pre-render all blog posts in this scenario! 
 - **Scenario 2**: An increment to `15` octotype users with `5` posts each with a site regeneration every `120 seconds` will trigger about `5940` API calls, which is above the rate limit of `5000`. 
 
As you can see, the site's scalability is limited due to the API rate restriction, so how can we fix it? I wish I had this problem (😇), but I see different options:

1. We could increment the ISR revalidation from `120 seconds` to `180 seconds` or beyond. This will trigger API calls less frequently, of course. That's cool and all that, but users would see a delay of 3 mins between the issue being created on GitHub and the blog post being published on the Web.

2. For immediate rendering without delay, we could server-side render blog posts which, while detrimental to performance, is a safe option because it will reduce the number of API calls in an order of magnitude.

3. I am unsure whether creating a GitHub App or an OAuth App is a valid option since I'd prefer to stick to the GitHub API free tier. Why? I sought simplicity and wanted to avoid the user logging in with GitHub credentials to get a better API rate limit. For me forcing the user to log in with GitHub credentials **just to read content** was a deal breaker. The audience of every developer's blog shouldn't be restricted to other developers only!

As you can imagine, I hit the limit multiple times while building the site using example Issues. However, Next.js gives us a super handy way of adding local environment variables out of the box. To get a better API rate during development time, I just had to put my personal GitHub token in the `.env.local` file and add a feature flag to use it if it was available (which is not the case on the server)

Finally, rendering the markdown of a GitHub issue as HTML was super easy too. The API itself returns a raw markdown, so you only need a small library like `remark` to parse it and transform it into HTML. Something like this:

```javascript
import { remark } from 'remark'
import html from 'remark-html'

export default async function markdownToHtml(markdown: string) {
  const result = await remark().use(html).process(markdown)
  return result.toString()
}
```


## 8 Examples of Augmented Developer Experience with OpenAI
As I mentioned earlier, I wouldn't have built this site without ChatGPT. Here are some very good examples as screenshots of the type of inputs I gave to the tool together with the provided answer. Did it work? Well, if you are reading this post through octotype's Web, yes, it is. Beautifully. **BIG TIME**

_(Note: dont' even judge me 😇)_

**Example 1: Problem with async/await**: I just copy-pasted a code snippet. Then the AI detected the problem and came up with a solution.

![Screenshot 2023-01-08 at 20 35 38](https://user-images.githubusercontent.com/3844521/211215398-0042407e-fd73-4b50-bc69-aa3258198112.png)

**Example 2: I wanted to implement a simple tabs component**: There you go, say no more

![Screenshot 2023-01-08 at 20 38 08](https://user-images.githubusercontent.com/3844521/211215432-e4b8d2f0-fa25-4391-a751-4f2f5fdcbef9.png)

**Example 3: I did ask the same for a carousel component**: It didn't work at first because of a bug. The AI fixed it:

![Screenshot 2023-01-08 at 20 39 20](https://user-images.githubusercontent.com/3844521/211215507-616ed475-2d8b-4bfd-986f-cfb51cfdd55d.png)

**Example 4: An easy one about pure UI aspects using TailwindCSS**. 

![Screenshot 2023-01-08 at 20 40 40](https://user-images.githubusercontent.com/3844521/211215561-a737cd85-c44b-4e84-94d7-a59caf3368ea.png)

**Example 5: A basic Typescript question**: Because of stupid me 😂

![Screenshot 2023-01-08 at 20 42 05](https://user-images.githubusercontent.com/3844521/211215622-69be4304-a1fb-4e23-bcdd-63e18c34ec38.png)

**Example 6: Using Next.js `getStaticProps`**: These are my programming skills!

![Screenshot 2023-01-08 at 20 43 24](https://user-images.githubusercontent.com/3844521/211215675-b0a3e96e-006d-408c-a13d-9653508798d9.png)

**Example 7: The typewriter effect on the landing page**: This is how I did it

![Screenshot 2023-01-08 at 20 44 44](https://user-images.githubusercontent.com/3844521/211215709-0c8800d0-73f5-4f8c-abad-12547c4f9421.png)

**Example 8: More on the typewriter effect**.

![Screenshot 2023-01-08 at 20 44 44](https://user-images.githubusercontent.com/3844521/211215761-95c9913d-bbc6-4863-b4c7-8a4459d47596.png)




The engineering behind octotype: GitHub Issues as CMS, Next.js, and 8 times OpenAI saved me

## Why is writing and sharing stories important?
As we approach the advent of AGI (artificial general intelligence), it's becoming increasingly crucial for developers in the tech industry to have an audit trail of their public content and a demonstrable record of their insights. In a world where AGI will analyze vast amounts of data and make decisions faster than humans, we will have to prove the validity and accuracy of our work. An audit trail of public content and a record of insights can provide evidence of the thought processes and research that went into a particular conclusion or decision.

This is especially important in the tech industry, where the pace of change is rapid, and the stakes can be high. Having a clear and transparent record of the decisions and the reasoning behind them is essential. But it's also important to consider the long-term implications of AGI. As AI systems become more advanced, they may be able to analyze and understand our work in a way that humans cannot. That's why it's crucial to take control of our narrative and protect the value of our contributions by keeping an audit trail and record of our insights.

So what can we do to ensure our hard work is recognized and valued by humans and AI systems? Here are a few action items to consider:

- Start keeping a record of your public content and insights
- Make sure to document your thought processes and research
- Regularly review and update your audit trail to ensure accuracy and completeness

## How does `octotype` help?
I find modern blogging platforms for developers such as [dev.to](https://dev.to) and [Hashnode](https://hashnode.com/) very compelling, to the point that I have been a user for years. However, with all the tumult going on in the tech industry these days, I wonder how my audit trail of stories would survive if these platforms, for whatever reason, have to close down.

But wait, does it mean we should build our personal blogs and sites for storytelling from now on? Not quite. I think owning your content is super important, but there is a considerable gap between owning it and publishing it to share with others. Not everyone has the time, money, or energy to run their personal blog; yet everyone takes and shares notes.

**That's where `octotype` can help**. Developers can take notes and tell stories as GitHub issues, and `octotype` will publish those issues automatically as shareable blog posts. Yes, that's precisely what you think: `octotype` uses GitHub Issues as CMS.  GitHub's Issue management system gives developers all they need to create and manage content behind the scenes: they are very familiar with it, and it's easy to use, and widely adopted. It has an out-of-the-box API with an excellent free tier. It's just perfect!

## How is this good?
First of all, GitHub Issues gives us a distributed content management system out of the box. You can write your notes, tell your stories using markdown, and share them when you are ready. Yes, you can still share the GitHub issue link itself, but not everyone is a developer who enjoys GitHub's user experience. That's why `octotype` presents your content in a readable, mobile-friendly format to share with the rest of the world. 

I know what you are thinking, GitHub could even close down! Although that's unlikely, you still own your content as a personal Git repository, and maybe in the future, there will be so many blogging platforms you can plug your repository into. That's the power of portability and distribution for content management.

## What are the main features of `octotype`?
- First, you can go from idea to Web publication in less than two minutes. All you need to do is create an `octotype` repo for your user, create an issue with the `published` label, and that's all. You're ready to share your stories via the Web with others.

- Second, you get the same collaboration experience as GitHub Issues, with your issue comments and reactions displayed on the Web. Note that octotype's User Experience is simple by design, as it's intended to supplement the vast number and excellent GitHub communication capabilities. Do you want to follow a new developer? Do it on GitHub. Do you want to be notified about comments on your blog post? Go to GitHub notifications. And so on.

- Third, bring your own publishing workflow. You can automatically create new GitHub Issues as part of your CI/CD process and immediately publish them as blog posts. Or you can create new GitHub issues using GitHub CLI and never leave the terminal. Or you can use GitHub UI on the Web or the Desktop. You own your content, and you own your publication mechanism. 

- And fourth, `octotype` is fast, as most of the content is pre-rendered using Next.js on Vercel. I will share more technical details about the design behind the platform in a future blog post.

I hope this new blog platform fosters collaboration and storytelling amongst developers so we can all share and learn from each other. As you will notice, simplicity is a fundamental design principle of `octotype`, so give it a go, test it, and help refine it.

Happy writing!



octotype.

peibolsang.

A tech blog using GitHub Issues as CMS

Featured Story

The Frontend Cloud

More Stories

It's time to rename serverless

How Edge Computing can make the Web better

Different rendering options

Conversational Programming

The engineering behind octotype: GitHub Issues as CMS, Next.js, and 8 times OpenAI saved me

What's octotype and why do we need it?

Why is writing and sharing stories important?