3 ms·

I have only 76 posts, and all of them cached on disk take 3MB, so don't have this problem yet. However I'm thinking about something else: I'm going to write a

I have only 76 posts, and all of them cached on disk take 3MB, so don't have this problem yet. However I'm thinking about something else: I'm going to write a blog software with a nice api. It will be storing posts in a database on the server side, and will store them on the local too (as cache) - however the source files will be on disk, versioned by git. And it will send just new versions to server using a local command line utility. I really love publishing with a one liner. This way I could have fast search, and comments on the server side.

stevekemp 10y ago
There are definitely different trade-offs to be made on storage, but it would seem that using both a database and a flat-file structure would be the worst of both worlds. If the database is used to serve the content it must be online, and so you lose one of the big appeals of static-sites: That they are static and can be served trivially. If you're writing in text-files you need some kind of update-process which might become tricky if you edit past-entries, etc. I suspect that publishing with one command doesn't really matter too much on technology; in my own case I just use a Makefile: * Download the comments from the remote server, via rsync. * Rebuild the blog. * Upload the generated HTML-site, via rsync.