Clear Writing


- Make decisions about -> Decide on 
- Majority of -> Most
- For the reason that -> Because
- Loop back on -> Connect
- Has the opportunity to -> Can
- In order to -> To
- At all times -> Always
- On a daily basis -> Daily
- A number of -> Some

Serverless 3D WebGL rendering with ThreeJS


![3D model of a helmet](https://serverless-3d-rendering.vercel.app/api/render?model=https://serverless-3d-rendering.vercel.app/DamagedHelmet.glb)

This image above was rendered in a serverless function on page load.

3D rendering is a high-cost task, often taking a long time to compute on GPU accelerated servers.

Browsers are becoming more capable. The web is more powerful than ever. And serverless is the [fastest-growing cloud service model](https://www.rightscale.com/lp/state-of-the-cloud). There must be a way to take advantage of these technologies for rendering 3D content for cheap at scale.

Here's the idea:

- Create a React app and display a 3D model using [react-three-fiber](https://github.com/pmndrs/react-three-fiber)
- Create a serverless function which runs a headless browser displaying WebGL content
- Wait for WebGL content to load and return the rendered image

We'll be using NextJS for this.

The final project is on [GitHub](https://github.com/tiivik/serverless-3d-rendering).

---


## 3D viewer

Let's start by creating a new NextJS application. We'll bootstrap the project from the NextJS typescript starter.

```bash
npx create-next-app --ts
# or
yarn create next-app --typescript
```

Running `npm run dev` should present you with the "Welcome to NextJS" page. Cool.

Let's create the page that's going to display a 3D model.

```bash
touch pages/index.tsx
```

```tsx
// pages/index.tsx

export default function ViewerPage() {
  return <></>;
}
```

To keep things simple we'll be using [React Three Fiber](https://github.com/pmndrs/react-three-fiber) and [Drei](https://github.com/pmndrs/drei), a collection of helpers and abstractions around React Three Fiber.

Let's install both dependencies:

```bash
npm install three @react-three/fiber
npm install @react-three/drei
```

Let's set up the 3D viewer. We'll use the [Stage](https://github.com/pmndrs/drei#stage) component to get a nice rendering environment.

```tsx
// pages/index.tsx

import { Canvas } from "@react-three/fiber";
import { Stage } from "@react-three/drei";
import { Suspense } from "react";

export default function ViewerPage() {
  return (
    <Canvas
      gl={{ preserveDrawingBuffer: true, antialias: true, alpha: true }}
      shadows
    >
      <Suspense fallback={null}>
        <Stage
          contactShadow
          shadows
          adjustCamera
          intensity={1}
          environment="city"
          preset="rembrandt"
        ></Stage>
      </Suspense>
    </Canvas>
  );
}
```

Now, we'll need to load a 3D model. We'll be loading a glTF asset, [a transmission format](https://www.khronos.org/gltf/) that's evolving into the "JPG of 3D assets". More on that in future posts!

Let's create a component to load any glTF asset:

```bash
mkdir components
touch components/gltf-model.tsx
```

We'll also traverse the glTF scene graph to enable shadow casting on meshes of the glTF:

```tsx
// components/gltf-model.tsx

import { useGLTF } from "@react-three/drei";
import { useLayoutEffect } from "react";

interface GLTFModelProps {
  model: string;
  shadows: boolean;
}

export default function GLTFModel(props: GLTFModelProps) {
  const gltf = useGLTF(props.model);

  useLayoutEffect(() => {
    gltf.scene.traverse((obj: any) => {
      if (obj.isMesh) {
        obj.castShadow = obj.receiveShadow = props.shadows;
        obj.material.envMapIntensity = 0.8;
      }
    });
  }, [gltf.scene, props.shadows]);

  return <primitive object={gltf.scene} />;
}
```

We'll be using a glTF asset downloaded from KhronosGroup glTF sample models [here](https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/DamagedHelmet/glTF-Binary/DamagedHelmet.glb).

Let's add the GLB (binary version of glTF) to the `/public` directory. You could also pass a GLB hosted elsewhere to the `useGLTF` hook.

You might need to install `npm i @types/three` for the type checks to pass.

Let's add the GLTFModel to our viewer page:

```javascript
// pages/index.tsx

import { Canvas } from "@react-three/fiber";
import { Stage } from "@react-three/drei";
import { Suspense } from "react";
import GLTFModel from "../components/gltf-model";

export default function ViewerPage() {
  return (
    <Canvas
      gl={{ preserveDrawingBuffer: true, antialias: true, alpha: true }}
      shadows
    >
      <Suspense fallback={null}>
        <Stage
          contactShadow
          shadows
          adjustCamera
          intensity={1}
          environment="city"
          preset="rembrandt"
        >
          <GLTFModel model={"/DamagedHelmet.glb"} shadows={true} />
        </Stage>
      </Suspense>
    </Canvas>
  );
}
```

Update the `styles/globals.css` to set the canvas to screen height:

```css
// styles/globals.css

html,
body {
  padding: 0;
  margin: 0;
  font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen, Ubuntu,
    Cantarell, Fira Sans, Droid Sans, Helvetica Neue, sans-serif;
}

a {
  color: inherit;
  text-decoration: none;
}

* {
  box-sizing: border-box;
}

canvas {
  height: 100vh;
}
```

With that in place, you should now see the 3D model rendered on `http://localhost:3000/`

![Helmet 3D Viewer](/images/helmet-3d-viewer.jpg)

## Serverless rendering

Let's leverage the client-side 3D viewer and provide access to 2D rendering through an API.

To keep things simple, the API will take any 3D model URL as input and return an image of that 3D model as the response.

**API**

GET: `/api/render?model={URL}`

Response: `image/png`

### Create the API route

```bash
mkdir api
touch api/render.ts
```

⚠️ Note that we're creating a new api directory and not using the existing `pages/api`. This is to avoid functions sharing resources and exceeding the serverless function size limit on Vercel (where we'll be deploying the app to). More info [here](https://github.com/vercel/vercel/discussions/4903#discussioncomment-900135) and [here](https://github.com/vercel/vercel/issues/4739).

⚠️ Also, in order for serverless functions to be picked up from the root directory you'll need to run
`vercel dev` locally to test the API route (as opposed to `npm run dev`).

Let's set up the initial function:

```tsx
// api/render.ts

import type { NextApiRequest, NextApiResponse } from "next";

export default (req: NextApiRequest, res: NextApiResponse) => {
  res.status(200).json({ name: "Hello World" });
};
```

With this, you already have an API route live on `http://localhost:3000/api/render`.

Behind the scenes, the rendering is going to happen in an AWS Lambda function. Hence we need to use a custom-built Chromium version to handle the headless browser.

Let's install the dependencies:

```bash
npm i chrome-aws-lambda
npm i puppeteer
```

Let's finalize our render function:

```tsx
import type { NextApiRequest, NextApiResponse } from 'next'
const chrome = require('chrome-aws-lambda')
const puppeteer = require('puppeteer')

const getAbsoluteURL = (path: string) => {
  if (process.env.NODE_ENV === 'development') {
    return `http://localhost:3000${path}`
  }
  return `https://${process.env.VERCEL_URL}${path}`
}

export default async (req: NextApiRequest, res: NextApiResponse) => {
  let {
    query: { model }
  } = req

  if (!model) return res.status(400).end(`No model provided`)

  let browser

  if (process.env.NODE_ENV === 'production') {
    browser = await puppeteer.launch({
      args: chrome.args,
      defaultViewport: chrome.defaultViewport,
      executablePath: await chrome.executablePath,
      headless: chrome.headless,
      ignoreHTTPSErrors: true
    })
  } else {
    browser = await puppeteer.launch({
      headless: true
    })
  }

  const page = await browser.newPage()
  await page.setViewport({ width: 512, height: 512 })
  await page.goto(getAbsoluteURL(`?model=${model}`))
  await page.waitForFunction('window.status === "ready"')

  const data = await page.screenshot({
    type: 'png'
  })

  await browser.close()
  // Set the s-maxage property which caches the images then on the Vercel edge
  res.setHeader('Cache-Control', 's-maxage=10, stale-while-revalidate')
  res.setHeader('Content-Type', 'image/png')
  // Write the image to the response with the specified Content-Type
  res.end(data)
}
```

Here's what happens in the function

- Launch Lambda optimized version of Chrome in a serverless environment or via puppeteer when developing locally
- Navigate to a URL displaying the 3D model passed in the query parameter
- Wait for 3D model to be rendered
- Cache the image result
- Return the image

Notice the line `await page.waitForFunction('window.status === "ready"')`.

This function waits until rendering is complete. For this to work, we'll need to update our viewer page and add an `onLoad` method to the `GLTFModel` component. We'll also add a router to pass a `model` query parameter to the `GLTFModel` component:

```tsx
// pages/index.tsx

import { Canvas } from '@react-three/fiber'
import { Stage } from '@react-three/drei'
import { Suspense } from 'react'
import GLTFModel from '../components/gltf-model'
import { useRouter } from 'next/router'

const handleOnLoaded = () => {
  console.log('Model loaded')
  window.status = 'ready'
}

export default function ViewerPage() {
  const router = useRouter()
  const { model } = router.query
  if (!model) return <>No model provided</>

  return (
    <Canvas gl={{ preserveDrawingBuffer: true, antialias: true, alpha: true }} camera={{ fov: 35 }} shadows>
      <Suspense fallback={null}>
        <Stage contactShadow shadows adjustCamera intensity={1} environment="city" preset="rembrandt">
          <GLTFModel model={model as string} shadows={true} onLoaded={handleOnLoaded} />
        </Stage>
      </Suspense>
    </Canvas>
  )
}
```

Also, we'll need to update our `gltf-model.tsx` component with a `useEffect` hook:

```tsx
import { useGLTF } from "@react-three/drei";
import { useLayoutEffect, useEffect } from "react";

interface GLTFModelProps {
  model: string;
  shadows: boolean;
  onLoaded: any;
}

export default function GLTFModel(props: GLTFModelProps) {
  const gltf = useGLTF(props.model);

  useLayoutEffect(() => {
    gltf.scene.traverse((obj: any) => {
      if (obj.isMesh) {
        obj.castShadow = obj.receiveShadow = props.shadows;
        obj.material.envMapIntensity = 0.8;
      }
    });
  }, [gltf.scene, props.shadows]);

  useEffect(() => {
    props.onLoaded();
  }, []);

  return <primitive object={gltf.scene} />;
}
```

#### Test drive

Let's see if our API is functional.

`http://localhost:3000/api/render?model=/DamagedHelmet.glb`

Boom 💥 server-side rendered glTF model:

![](/images/helmet-ssr.jpg)

Rendering of this 3D model takes ~5 seconds. When deployed to a CDN the image is served in ~50ms after the initial request. Later requests trigger revalidation (re-rendering in the background).

#### ⚡ Caching ⚡

We're taking advantage of the  `stale-while-revalidate` header by setting it in our serverless function.

This way we can serve a resource from the CDN cache while updating the cache **in the background**. It's useful for cases where content changes frequently but takes significant amount of time to generate (i.e. rendering!).

We set the maxage to 10 seconds. If a request gets repeated within 10 seconds, the previous image is considered to be fresh – a cache HIT is served.

If the request is repeated 10+ seconds later, the image is still **immediately** served from the cache. In the background, a revalidation request is triggered and an updated image is served for the next request.

## Deployment

In this example we're deploying the service to [Vercel](https://vercel.co/) by running `vercel` using their [CLI](https://github.com/vercel/vercel/tree/main/packages/cli).

#### ⚡ Boost the performance of the function ⚡

You can improve the performance of the function by configuring more memory available for it. Boosting the memory upgrades the CPU and network performance of the underlying AWS Lambdas.

Here's how to configure the Lambda to have 3X the memory than default configuration.

`touch vercel.json`

```json
{
  "functions": {
    "api/render.ts": {
      "maxDuration": 30,
      "memory": 3008
    }
  }
}
```

---

The final project and functioning API can be found on [GitHub](https://github.com/tiivik/serverless-3d-rendering). 

Thanks for reading! 


My new favourite way to write


![Nota](/images/nota.png)

I love [markdown](https://et.wikipedia.org/wiki/Markdown). I take notes in markdown. I keep todos in markdown. I [write emails in markdown](https://www.yourtempo.co/) and publish this blog in markdown.

The posts and pages of this blog live as markdown files in a git repository. Whenever I add or update a markdown file, the site and its static pages are rebuilt.

Here's the problem. I want publishing to be seamless. I don't want to think about git or committing files when adding or editing a blog post. I don't want to switch from markdown editor to terminal or git tool. I want to write, save and see changes live on site without friction. Typically you'd do that on a publishing platform or CMS, most likely through a web interface.

How does one publish to git from a writing app? There are headless CMS solutions like [Forestry](https://forestry.io/) that commit to a git repository and Ulysses can [integrate with Medium](https://ulysses.app/integrations/medium), but [I've ditched it](/blog/i-read-this-article-on-medium).

I often collect links, thoughts, pieces of information that I'd like to include in a post. This happens throughout the day, ad hoc when I don't have the time to organize them. The next best thing is to drop the links or notes into the place they end up in - the post itself.

I'm looking for something simple, publishing straight from the app I have always open - my notes app.

Then I found [Nota.md](https://nota.md). The developers call it _Pro writing app designed for local Markdown files_. What caught my attention was its Command Pallet feature – the ability to run arbitrary commands within the app.

A few niche things I'd like the app to do:

- When the app is quit, reopen the last notes (a surprising amount of markdown editors don't do that)
- A seamless workflow to publish to git within the app
- Ability to show which files are new or modified in git

Nota seemed to tick the right boxes.

Here's how I publish with Nota.

After installing Nota, hit `CMD+Shift+P` and choose `Create New Custom Command`. 

![Nota Create Custom Command](/images/nota-create-custom-command.jpg)

This creates and opens a new file from `.nota/commands/my-command.sh`.

First, let's rename the command:

`mv .nota/commands/my-command.sh .nota/commands/publish-to-git.sh` 

Edit the content of that file with the following:

```bash
#!/bin/bash
# @parameters workspace file
cd $1 && git add $2 && git commit -m "Update via Nota" --allow-empty && git push
```

Here's what this snippet does:
1. Change directory to your Nota workspace (where your notes live)
2. Commits the changes to the current open file
3. Pushes the file to git

Now, whenever you have a file open, you can hit `CMD+Shift+P` and search for "Publish to Git".

Also - "A" and "M" tags in the notes list indicate whether files are new or modified in git.

![Nota Publish to Git](/images/nota-publish-to-git.jpg)

Tada! 🎉  This is now my favourite way to write and publish to git.


Is there a tool or workflow I haven't considered? Let me know on [Twitter](https://twitter.com/rainerselvet)!

Add syntax highlighting to NextJS markdown blog


Want to add beautiful syntax highlighting to your markdown blog? Here's how you can easily do that with [NextJS](https://nextjs.org), [react-markdown](https://github.com/remarkjs/react-markdown) and [react-syntax-highlighter](https://github.com/react-syntax-highlighter/react-syntax-highlighter).

The final project can be found in CodeSandbox [here]().

First, create a new NextJS project by running

```bash
npx create-next-app
```

Let's get the dependencies
```bash
npm i react-markdown
```
```bash
npm i react-syntax-highlighter
```

For the purposes of this guide, we'll simply create one page with some placeholder markdown content.
```bash
touch pages/blog.js
```


https://jfelix.info/blog/how-to-make-a-static-blog-with-next-js

https://github.com/react-syntax-highlighter/react-syntax-highlighter/blob/HEAD/AVAILABLE_LANGUAGES_PRISM.MD

https://github.com/react-syntax-highlighter/react-syntax-highlighter/blob/HEAD/AVAILABLE_STYLES_PRISM.MD


Personal blogs


I love reading personal blogs. They are unique corners of the Internet, often with the best writing out there.

They make [carving out your own place](https://world.hey.com/dhh/no-more-platforms-please-8f01445e) on the internet possible.

Here are a few that I follow. 

- [https://leerob.io][1]
- [https://jsomers.net/blog][2]
- [https://telmo.is][3]
- [https://rauchg.com][4]
- [https://just-be.dev][5]
- [https://notebook.lachlanjc.com][6]
- [https://davemart.in][7]
- [https://michaelsoolee.com/writings][8]
- [https://arslan.io][9]
- [https://tik.dev][10]

[1]:	https://leerob.io/
[2]:	https://jsomers.net/blog
[3]:	https://telmo.is/
[4]:	https://rauchg.com/
[5]:	https://just-be.dev/
[6]:	https://notebook.lachlanjc.com
[7]:	https://davemart.in
[8]:	https://michaelsoolee.com/writings/
[9]:	https://arslan.io
[10]:	https://tik.dev

I read this article on Medium


Medium’s built-in distribution is great, their tooling around publishing is excellent. There’s no complicated setup involved and you can start writing right away. The chances of getting your post promoted in a large publication are real. Medium resurfaces old articles, shares them in newsletters which is great for promotion.

It is quite safe to say that with zero marketing effort an article on Medium has a bigger chance of getting noticed compared to publishing on your own domain.

I like Medium a lot, yet I decided to run this personal blog myself.

Why ditch Medium?

I find myself telling _“I read this article on Signal v. Noise blog…”_ or _“I read this article on MacStories blog…”_. Yet whenever I find a memorable article published on Medium, I say _“I read this article on Medium…”_. Articles on Medium are predominantly Medium’s articles, not your articles. The face of the individual author shines through less than Medium does. How many names of self-published authors on Medium could you name? Of course, it all makes sense for Medium as a platform and the tradeoff can be worth it due to the benefit of distribution it offers.

Medium doesn’t feel the right place to write short articles. Articles that describe a quick hack you found during development, storing a snippet of useful information, posts that are just a little too long to fit into a tweet. Medium just feels wrong for that.

Perhaps the decision is influenced by me trying to be a lot more mindful about the content I consume. I rarely go to a generic podcasts website, instead, I open my favourite podcast app (which is Castbox btw!) to listen to Joe Rogan or Indie Hackers. I already know what I want to listen to before opening the app. I want to do the same with the written content I consume and write. Instead of popping up in a platform’s recommended list, I want to write as good content that people remember this domain like I remember authors publishing on their own.

Content written here is mine forever. I’m not paranoid of Medium going bust or placing all articles behind a paywall nor do I deeply care but it’s still nice to know that what I’ve written exists indefinitely in a GitHub repo, which I can publish anywhere, anytime, free or paid.

I find enjoyment in customizing the way the site looks, tinkering with its CMS and site generator and learning about all the modern tools around it. It exposes me more to the backbones of web technologies, and a lot of the knowledge carries over to product ideas.

With that being said, I don’t write Medium off completely – I keep open the possibility of cross-publishing here and on Medium if I so desire.

Subscribe to the newsletter