Worklog for task "Develop and launch the website"

Progress: Testing the haih.site architecture on a real project

We studied the current implementation of haih.site and refined the criterion for architectural minimalism. An important takeaway: minimalism cannot be measured by the number of technologies or dependencies. The goal is to minimize the total friction of development, operations, and future changes, including the human and AI feedback loop.

Development stack

React/Vite are not inherently redundant, even for a site that primarily serves static content in production.

Vite is justified by a real development requirement: a fast edit → HMR → browser feedback loop without manual user actions like reloading or resetting the cache.

React can be justified by its component model and the locality of changes in a growing UI. For AI, this also provides a predictable, well-known code structure.

Refined principle:

Do not minimize the number of dependencies. Minimize friction. Each added technology must reduce total complexity more than it increases it.

Production serving: baseline

After the build, npm run start was executed and a synthetic benchmark was performed:

ab -c 1000 -n 100000 http://localhost:3000/

Result:

• 100,000 requests;
• concurrency 1000;
• 0 failed requests;
• 11,515.51 req/s;
• p50 27 ms;
• p95 37 ms;
• p99 67 ms;
• max 8,658 ms.

Typical latency was low, but there were occasional large outliers.

Docker + Traefik + Varnish

Next, the same workload was run through a production-like chain:

client → Traefik → Varnish → app

Benchmark:

ab -c 1000 -n 100000 http://localhost:8088/

Result:

• 100,000 requests;
• concurrency 1000;
• 0 failed requests;
• 15,871.02 req/s;
• p50 62 ms;
• p95 74 ms;
• p99 88 ms;
• max 129 ms.

Compared to the direct app server, throughput increased by approximately 38%, and the latency distribution became significantly more stable: the multi-second tail disappeared.

Origin behavior

docker stats showed that during the 100k requests, the app practically did not participate in handling repeated requests.

Before the test, the app had approximately:

NET I/O 9.56kB / 126B
MEM 25.73 MiB

After:

NET I/O 10.9kB / 3.68kB
MEM 26.16 MiB

Meanwhile, Traefik handled about 370MB / 394MB, and Varnish handled 41MB / 328MB.

This confirms a useful architectural boundary: cacheable delivery traffic stops at Varnish and almost never reaches the application layer.

Why the project needs Varnish

A critically important requirement: the site uses dynamic image resizing/processing via Node + Sharp.

Without a cache, a repeated request for the same image variant potentially repeats an expensive cycle:

request
→ Node
→ Sharp
→ decode
→ resize
→ encode
→ response

With Varnish, computation happens on a cache miss, after which the identical variant can be served from the cache without repeating Sharp's work:

request
→ Varnish
   ├─ HIT → response
   └─ MISS → Node → Sharp → result → cache → response

Therefore, Varnish is justified not merely by increasing static HTML RPS, but by isolating the application layer and caching the results of expensive, repeatable computations.

Architectural conclusion

The current stack should not be evaluated as a list of technologies:

React + Vite + Node + Sharp + Varnish + Traefik + Docker

but rather as a set of solutions for specific requirements:

• Vite → fast development feedback loop;
• React → UI composition and change locality;
• Node + Sharp → on-demand preparation of images in the required size/format;
• Varnish → avoiding repetitive processing and preventing cacheable traffic from reaching the origin;
• Traefik → routing/deployment boundary;
• Docker → reproducible runtime/deployment.

A good criterion for each architectural component:

What measurable cost does this component reduce, and does the benefit outweigh the cost of the component itself?

This refinement should be used when developing HAIH showcases and best practices: do not impose a minimum number of technologies, but rather demonstrate the minimally sufficient total cost of the solution with evidence.

Next useful check

For a clean comparison of the cache layer, it makes sense to obtain a third datapoint later:

A. app
B. Traefik → app
C. Traefik → Varnish → app

with the same workload and a separate metric for the number of requests that actually reached the origin.

We will not publish a marketing article based on these findings within this worklog—it will be compiled separately later.