## 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!



What's octotype and why do we need it?

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

>_(This is an excerpt from the first chapter of my book, "[Building Software Platforms](https://leanpub.com/software-platforms)." I was fascinated by this story and very quickly pattern-matched it to the software industry to see how we could learn from one of the master innovators of our time)_

## Reinventing yourself

Funnily enough, this story is not about technology but gastronomy. Concretely speaking, it is about a restaurant, not just any, but the best restaurant of all time, *El Bulli*. Located in Roses (a charm-filled town in the Spanish C*osta Brava),* the place had already been awarded one Michelin star a couple of years before chef Ferran Adrià joined the staff in 1984. With Ferran's and his brother Albert's ideas, the restaurant's popularity rocketed thanks to the many innovations they brought into the *cuisine,* obtaining two additional Michelin stars in 1990 and 1997. 

With Adrià already at the front of the team, during the late 90s, El Bulli helped put the new Spanish gastronomy on the map and changed the status quo of the gastronomic industry with new technologies such as the kitchen siphon and new techniques such as deconstructions. Adrià's *Molecular Gastronomy concept was disruptive enough to put his restaurant in a* prominent position in an already competitive list dominated by French chefs with their *Nouvelle Cuisine*. 

And this is when the story starts to get interesting. 

In 1998, and with El Bulli already enjoying a leading position among the best places in the world, Adrià took a decision that surprised the entire gastronomic industry (and the whole world). [As he expressed in many interviews](https://www.laverdad.es/sociedad/despegue-gastronomico-20180705004051-ntvo.html), he felt exasperated about going from congress to congress and watching other chefs sharing the results of their ideas while keeping the secrets, and most importantly, the recipes to themselves. The intensity of how those colleagues guarded their creations triggered Adrià's creativity.

As a professional chef, Adrià was committed to improving continuously and changing the world's perception of this type of cuisine as a banal activity carried out by many pompous elitists who were only interested in recognition. He had an alternative vision beyond making El Bulli a lucrative restaurant and another mission rather than just running a business. He wanted to make a positive impact on people's lives through the experience of having food and, as a consequence, leave a legacy. At one of those conferences, in San Sebastián, he proclaimed one of his most famous statements that kickstarted a whole movement within the industry:

> "*The time of keeping recipes in the drawer is over."*

As he said that, he started sharing his famous recipes and techniques publicly, congress after congress. Yes, precisely, this is what you are thinking. Adrià open-sourced El Bulli's recipes to get better as he understood that the best way to protect an idea is by sharing it immediately. The restaurant was good, but they wanted to become the best. They quickly recognized that the only way of getting there was by accelerating innovation and sharing knowledge with the community to compete in identical product and practice conditions. By releasing their secrets in the open, they transformed their technologies and techniques into a quasi-industry standard adopted by many other restaurants across the planet that were pursuing the same kind of success. 

What happened was that the gastronomic industry was starting to compete in a commoditized market. Molecular gastronomy technologies and techniques at their genesis in the early 90s became industrialized by the early 2000s and accessible by all kinds of restaurants. Molecular gastronomy became so popular and handy that all good restaurants included several dishes using this technique in their primary menu. If we look at our kitchens now in the 2020s, we will likely find some sophisticated pieces of equipment, such as siphons, in a shameless attempt to impress our friends with taco foam the next time they come and visit us for dinner.

What happened after this master move won't surprise you. 

Adrià and his team outperformed themselves to the extent that *Restaurant* magazine awarded El Bulli the best restaurant in the world from a global list of 50 places in 2002, 2006, 2007, 2008, and 2009, setting a record high of five times. Again, they were competing in a highly commoditized market where most restaurants used the same products and techniques based on Molecular Gastronomy. Not surprisingly, El Bulli's chefs were again leading in a very competitive market and differentiating themselves from their competitors by using their techniques to produce exclusive and unique dishes. This approach helped Adrià set a new best practice in the gastronomy industry. 

![piramidecreativa-adria](https://github.com/peibolsang/octotype/assets/3844521/4b5c010b-fd28-40df-a401-401c7247af75)

However, little did he know that they were about to die of success except for one person: the visionary chef. 

Adrià started to witness the first signals of burnout in his increasingly mature team. More importantly, he was very frustrated that he had to reject customer after customer because the restaurant's waiting list had extended for months (and even years) of reservations. The team even had to cancel the lunchtime service to focus on one service per day at dinnertime, which raised many questions and concerns to the management team, severely impacting El Bulli's revenue. Adrià estimated that the team couldn't physically and mentally make it beyond 2012, so in an unexpected anticipation maneuver, he closed the restaurant in July 2011.

Although El Bulli as a restaurant has closed forever, its core concept and Adrià's vision didn't stop there. Right after he announced that the most iconic restaurant in modern history was closing at its peak, the Spanish chef revealed the details about how he wanted to build his legacy. Therefore, in the spirit of the experimentation and innovation that led El Bulli to become the number one restaurant, Adrià's next project consisted of spinning up a foundation to foster gastronomy innovation, learning, and sharing experiences with the community. The new entity, known as *El Bulli Foundation, aims to create and deliver* new culinary experiences for its guests.

When this book was written, all we knew was that this master chef wanted to persevere in realizing his vision of leaving a legacy to the world and disrupting the gastronomy industry once again. Indeed, Adrià and his team are closing the cycle of evolution, making the pendulum swing back to genesis to reinvent themselves, formulate uncertain things again, work with poorly understood concepts, and start to compete in an undefined market. They don't love failure at this new stage, but they tolerate the process to create innovations that will help them differentiate with unique gastronomy products in the future. This idea is presented in the following Wardley map:

![1 Differentiate on Operations](https://github.com/peibolsang/octotype/assets/3844521/83c3dcb1-e570-4ff2-81db-cdb8486a6882)

## The lesson for the software industry

There is a hidden lesson for the software industry despite this story's evident survivorship bias and the manifestation of privilege that entails closing a wealthy business at its peak.

We are moving toward a world where technology is so abundant that companies must quickly evolve from product to service differentiation. To make the jump, many of these companies also need to understand that the only way to improve a product is to transform it into an industry standard. **In technology, that could happen by open-sourcing it.** 

After that, companies compete in a services market that fosters innovation to gain new competitive advantages. It took El Bulli, a company in the gastronomy business, over three decades to preserve a leading position by going through this magical cycle, which technology companies are doing in a decade or less. This is how fast technology goes, so be prepared for a bumpy ride.

How the story of the restaurant El Bulli can help the software industry

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

My favorite way to squash commits **by far** is this:

```sh
git reset --soft $(git merge-base main HEAD)
```

It resets all changes compared to `main` and I can commit again as a single commit with a single commit message. 

Don't forget to force push!

My favorite way to squash commits

Hey, have you ever wanted to create a circular nav?


![circle-nav](https://user-images.githubusercontent.com/6593513/213532767-5034b66f-92cb-484b-a80e-aa35910a9f26.gif)

It's like a pizza.

![image](https://github.com/pensjonatus/octotype/assets/6593513/8bf33a50-58b4-40cd-a476-c91110245c56)

Yeah, me too. But how do you put divs in a circle? Math usually goes way over my head, but I was able to put it together eventually.

```ts
function getCircleArray(
  numberOfItems: number,
  radius: number
): CircleCoordinates[] {
  const numberOfSegments = 360 / numberOfItems;

  const angles = [];
  for (let i = 0; i <= numberOfItems; i++) {
    angles.push((numberOfSegments / 180) * i * Math.PI);
  }

  const circleArray = [];
  for (let i = 0; i < numberOfItems; i++) {
    const posX = Math.round(radius * Math.cos(angles[i]));
    const posY = Math.round(radius * Math.sin(angles[i]));
    circleArray.push({ posX, posY });
  }

  return circleArray;
}
```

This returns an array of `posX` and `posY` for a selected numbr of items. All you need to do is place them:

```tsx
    {circleArray.map(({ posX, posY }) => (
        <div
            style={{
              position: "absolute",
              top: -1 * posX,
              right: posY,
              transition: "all 0.5s ease-out",
          }}
        />
      );
    })}
```

I hope you find this useful. 😄 

Circular nav

By "free" apps, I mean Vercel, Github, social media apps, etc., etc., etc. Apps which you don't pay for using money.

When using "free" apps, you're giving a lot of control over your **stuff** to a business. In exchange, you get a modern app deployed to the web. What can Vercel do with your stuff:

- Use it to make money for themselves
- Delete it

That does not sound very good, so why do I like it?

The reason is in the tradeoff. My **stuff** is not really valuable to me, or to anyone else. And it's not really long-lived, either. It will be stale in a few days, to be honest. But using Vercel I can get it out there quickly and have it available temporarily with little overhead.

Why I like "free" apps

## 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

Testing this out. Okay it works, and this is actually pretty cool. I'll take some time and create a post soon lol.

first time

Hello world

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

Hey there fellow devs! Are you tired of using boring old blogging platforms? Well, I've got some good news for you: Octotype is here to save the day!

Octotype is an awesome platform that lets you create and share stories and notes as GitHub issues, which are then automatically turned into sweet blog posts on a mobile-friendly website. It's super easy to use and a great way to share your thoughts with the world.

But Octotype isn't just for sharing your musings. It also keeps a transparent record of the thought processes and research that went into your conclusions or decisions. In this age of artificial intelligence, it's important to have a clear record of your insights and an audit trail of your public content.

And the best part? Octotype provides the same collaboration experience as GitHub Issues, with comments and reactions displayed on the web. This makes it a breeze to get feedback from your peers and helps to create a collaborative team environment.

Overall, Octotype is the go-to platform for devs who want to share their ideas and insights in a simple and collaborative way. Give it a try and see how it can benefit your team!