6 comments

[ 4.5 ms ] story [ 30.0 ms ] thread
> skip the database, the ORM layer, the glue code, the data model, and all that ancillary stuff, and simply cache the ebook objects themselves

It is nice to see people thinking in this direction, instead of just assuming you need a full database if you have any data. For non-transactional key-value storage, it works well in many cases, even with 100GB+ of data.

I think their site was one of the first places I ran across AVIF (AV1 image files) in the wild.

I had assumed it was a CDN they were using but this suggests they may have done it by hand, which is cool.

It's all done by hand! Thumbnails are compressed using go-avif when they're created.
ACabal, are you involved in the standard ebooks project?
A month has about 2.6 million seconds in it; 1.2 million page hits per month works out to half a request per second.

Dynamic web frameworks considered to be worst-in-class for performance, such as Rails, are capable of rendering basic HTML dozens of times per second on a Raspberry Pi.

Reading this article is like listening to a teenager, having successfully microwaved a plate of hot pockets, tsk-tsking the complex machinery of a commercial kitchen.

I'm not up to date with Ruby on Rails, but isn't it in roughly the same class of 'classic' web that this article describes? i.e. server side stuff delivered to the browser with minimal JS? I think it was the last time I looked at it.