Hacker News Reader

Comment by shitduck | Hacker News Reader

Ghost uses SQLite by default, but the ORM allows for other databases seamlessly.

It's awesome that it has an ORM - but ever since I have started using Octopress, which is based on Jekyll, is the more I realize that we don't need a DB for 'just blogging'.

Plain, old, generated HTML works perfectly. Plus it is very easy to host.

If this is something you guys can implement, I would suggest looking at it.

Your hosting will be MUCH simpler, cheaper, more profitable (even though you say you are running a non-profit), general footprint will be smaller, and pages will load quicker.

That's just my $0.02.

I love what I see here, but I can't bring myself to going back to a db-powered blog from Octopress.

The day you guys implement something similar, you will have 1 more user though!

Either way....awesome execution and congrats on everything you guys have done. Love it so far.

> is the more I realize that we don't need a DB for 'just blogging'.

That works for you and me (we're using jekyll here) but not for people that want timed releases and an online editor. Comments will need some sort of database as well, so you'll have to rely on disqus or similar if you're running a static blog.

Ahhh....you are right. Good point.

Comments (outside of Disqus), timed-releases and online editor. Interesting. I can see that.

Why can't you do static generation from an online editor?

Because you need to write somewhere. Now, you can write to the filesystem if you really really want to, but only if there is a writable FS somewhere - so e.g. not on heroku - but in any case writing to the FS and then serving that document is a whole can of worms.

Actually what I want ideally is the admin interface to be a Node app. For drafts use sqlite. For scheduling use sqlite. When I hit publish I want it to generate static assets.

The blog itself I don't need to be served by the Node app, Apache or Nginx can do that fine.

> For scheduling use sqlite.

Well, scheduling and static generation require a cron job that writes the static asset at the predefined time. It all gets complicated from here. You can write the static asset when it's first accessed for example and from there on serve the static file, but that requires a database/storage as well, so you're basically back to square one.

I'd not restrict myself to sqlite here either, but that's a minor nitpick.

Why does it require a database? Ghost has a Markdown editor and presumable stores posts in the database as markdown, just write the markdown to the file system instead of a database? I'm really not seeing any requirement for a database here.

Well, yes, you can write to the filesystem, that's why I'm saying "database/storage". See, heroku for example does not provide you with a writable filesystem and it's also easier to share a database over a couple of hosts than a filesystem. Also, if you want to schedule, you'll need to store the scheduling information somewhere. You can add it to the file itself, just as jekyll does but then you'll have to open all docs just to see if they need scheduling. Or you write a schedule-file, but by the time you're doing that you're effectively building a database. Why not go and use a "real" database adapter and use sqlite for all basic setups since basically, sqlite is a specially formatted file with a library providing useful abstractions on top.

You can. I've done this using a different web editor based on CodeMirror: https://github.com/rascalmicro/red

I do suspect that Xylakant may be right elsewhere in this thread when she points out that it's not possible on Heroku, but I'm not sure.

Anyway, I would love to see Ghost use a pile of static Markdown files rather than a database for posts. Then, in a couple of years, when I want to use something else, I can take my pile of Markdown files and move along.

I'm a half-way house person when it comes to CMSes and databases. I don't think raw content needs to go in the database, it can happily live on the file system (assuming a sane permissions regime) and you can delegate version management to git.

However I feel metadata and other structured data belongs in the database for the usual reason: to support unforeseen future queries. That is, to make plugins and widgets easier to develop and better performing (vs, for example, iterating over every post or every comment to perform some calculation).

One problem I have with static HTML basic CMSes for non-personal publishers is that it can be a pain to migrate markup or templates if not rendered client-side.

If you've got thousands of pages, publishing a HTML change could require re-building of all static pages, which means it can be painful maintain once you get to a certain scale.

Reply on news.ycombinator.com