Hacker News new | ask | show | jobs
by johnonolan 2861 days ago
Heyo, John from Ghost here. Thanks for the kind words so far about 2.0 — it’s been a hectic few months! Earlier this year I talked about how we were shifting focus from simplicity to power - https://blog.ghost.org/5/ - and this is the first big release since that move. Whereas early versions were extremely opinionated and rigid, we’re now starting to bake in more flexibility and configurability to allow for a more diverse set of use-cases.

Some fun technical details from this release:

- New features require building a routing map for all possible URLs on boot, which is a dramatically heavy operation. We were eventually forced to forgo our traditional ORM layer entirely to get any degree of performance (insert: shock/awe)

- Related: It turns out SQLite3 has a query limit of 999 SQL variables, so we had to implement a recursive query strategy for SQLite only. Wild. Default is MySQL though, which was fine.

- Conquered a pretty spectacular memory leak when running in development as a result of trace-logging promises in Bluebird, which is “a full featured promise library with unmatched performance” — …unless you implicitly enable debug traces

Also: Let me be the first to say that I can’t believe there’s still no Postgres support, which is absolutely outrageous.

On a serious note, thanks for all the support and there are several of us hanging out in the comments if anyone has technical questions which they’re curious about.

6 comments

> New features require building a routing map for all possible URLs on boot, which is a dramatically heavy operation. We were eventually forced to forgo our traditional ORM layer entirely to get any degree of performance (insert: shock/awe) - Related: It turns out SQLite3 has a query limit of 999 SQL variables, so we had to implement a recursive query strategy for SQLite only. Wild.

Out of pure technical curiosity, how did this come to be the chosen approach? A query with 999 variables strikes me as a serious code smell, but at the same time I don't doubt you guys seriously considered the alternatives before choosing this route.

We're loading all public-facing resources - so posts, tags, authors and importantly the relations between them - in as few queries as possible, using fairly typical where...in queries in order to build the relations. SQLite uses variables for in queries, and so sites with a lot of content triggered the "more than 999 variables" error.

Solvable, of course, but quite an interesting limitation to discover!

I haven't check the code, but as few queries as possible is not always the best approach. I bet you guys spent a lot of time on the problem, but still very curious how you landed with this decision.

For the relation data, you should check out Hexastore [0] (essentially graph storage). It takes up much more space, but you can follow any paths of relationship and you can do it step by step instead of loading everything at once.

[0] http://www.vldb.org/pvldb/1/1453965.pdf

I discovered a similar limit with postgresql, mainly due to the protocol sending the query length as a 16-bit number, limiting the total length to ~65k characters. In that case it was far better to create a temporary table and JOIN that rather than using an " IN (..)" clause anyway, so that's another option if SQLite supports it.
There's no 16bit number limiting query length in PG, the limit is 1GB and has been for a LONG time. But it's indeed often a good idea to use a temp table for some of such cases.
This sounds like an interesting usecase for a graph database, is that something you have considered?
It's an interesting idea but Ghost is a primarily self-hosted application with a non-technical user base. The freedom to swap out or add core dependencies like database servers isn't really available in that environment.
Oracle had this limitation, too, or at least it did a few years ago.
Hey John -- I recall seeing on your Mastodon account recently that you were interested in supporting ActivityPub for Ghost blogs. Any news on that front?
Yeah! Very interested - we have a highly voted topic for it over on the forum with some ideas, too. It's not a primary focus of the core team right now, but it's the sort of thing we'd be very interested in open source contributions for.

One of the main motivations for people using Medium is the network effect. I think it would be really cool if that could be recreated in a platform-agnostic, decentralised way :)

I'm not sure how you could improve on blogrolls here, but I'm curious to see what you try.
I host several self-hosted blogs using Ghost 1.0 in Docker. When can we expect 2.0 released via Docker please?
The first place to look is the Ghost Docker repository and there’s already an open issue for it:

https://github.com/docker-library/ghost/issues/142

Question: Has the (Electron) Ghost app been updated to work with Ghost 2.0 as well? i.e., am I going to break things if I update my server to Ghost 2.0 then try to publish new posts using the app?
Ghost Desktop has been updated to support the Koeing Editor (see https://github.com/TryGhost/Ghost-Desktop/releases/tag/v1.7....) - Just make sure you're on 1.7.0 ;)
Hell yeah, John. I've absolutely loved watching you and your team grow over the years. Congrats and best of luck moving forward :) New stuff looks excellent.
"Also: Let me be the first to say that I can’t believe there’s still no Postgres support, which is absolutely outrageous."

Postgres is open source.

Why do they owe you?

If it matters, write the code.

It's a joke, the context of which is that they removed Postgres support from Ghost a while ago, and people keep complaining about it.

See: https://blog.ghost.org/dropping-support-for-postgresql/

I have to give him credit, I was here to complain about it.
That's not how he meant it, because it makes no sense.

He meant that he still hasn't taken the time to get some people in his team to support Postgres officially, I guess.