← Back to context

Comment by geerlingguy

5 days ago

I'm already self hosting my own cookieless analytics, and before, I hosted Drupal (LEMP stack) and Apache Solr on separate servers. I'm used to self-hosting, and any comment solution I use will be self-hosted as well (see: https://github.com/geerlingguy/jeffgeerling-com/issues/167)

The code surface with SSG + 1 or 2 small self-hosted OSS tools is much, much smaller than it ever was running Drupal or another CMS.

Yes, SSG pipeline + 1 or 2 small self-hosted OSS tools is way simpler than Drupal.

But all you've done in bought on all the pain and compromise of having to think from an SSG perspective, and that created problems which you've already identified you'll figure out in future

I'm suggesting 2 or 3 small self-hosted OSS tools, where one is a small hand crafted server that basically takes a markdown file, renders it, and serves it as plain HTML with a header/footer.

This is more homogenous, fewer unique parts/processes, and doesn't have the constraint of dealing with an SSG.

I remember my own personal pain from 2010 - 2016ish of managing Drupal and Joomla. I did exactly the same as you in 2016 and went all in on SSGs and in 2024, I realised all of the above. I feel like I wasted years of potential development time reinventing basic personal website features to try and work with an SSG and you literally have a ticket to do just that: https://github.com/geerlingguy/jeffgeerling-com/issues/167. 1 of your 3 solutions involves letting someone else host your comments:(

A custom framework/server is the end destination for all nerdy personal websites - I can't wait to see what you make when you realise this:)

edit/p.s. I love you and all your work. Sorry for sounding disagreeable, I'm excited to see what you learn from you SSG journey, I hope you prove me wrong!

  • Definitely not disagreeable, more just "there are two right answers" ;)

    For me, an unstated reason for SSG is being able to scale to millions of requests per hour without scaling up my server to match.

    Serving static HTML is insanely easy, even on a cheap $5-10/month VPS. Serving anything dynamic at all is an order of magnitude harder.

    Though... I've been using Cloudflare since 2022, after I started getting regular targeted DDoSes (was fun initially, seeing someone target different parts of Drupal, until I just locked down everything except for the final comment pages). The site will randomly get 1-2 million requests in a few minutes, and now Cloudflare eats those quickly, instead of my VPS getting locked up.

    Ideally, I'll be able to host without Cloudflare in front at some point, but every month, because of one or two attacks, the site's using 25-35 TB of bandwidth (at least according to CF).

    • Thanks for the response, I appreciate it. If anyone's wrong here, I'd much rather it was me, if not just because that would mean we've not wasted millions of hours as a society chasing the SSG dragon! :')

      I totally see where you're coming from, but you just said it yourself, SSGs don't actually solve any problems for you right now that cloudflare doesn't. A site of Jeffgeerling.com scale is the archetypal scale site that _should_ benefit from SSGs, but Cloudflare is the easier, and arguably better, solution to the traffic/bot/scale problem.

      If the problem you hit with Drupal is that it was more and less than you needed and became a headache to maintain, you will hit the same problem with Hugo eventually.

      The solution to that problem is to just write your own server side that does what you need. It's so much more fun and rewarding, and I'm confident if you did it, the output would be better. With modern servers and server side technologies, you would most likely not have a problem running your minimal MD->html server on your current VPS behind Cloudflare.

      Worst case scenario is you spend your time dealing with problems or misunderstandings with your own code, at least that'll be a refreshing change to dealing with problem or misunderstandings in Drupal's or Hugo's code or decisions.

      There's a time and a place for SSGs, and geerlingengineering is the perfect use case, because it has no real interactivity. But - again, please take this from a place of candour than intended offence - from a user perspective, in the process of migrating Jeffgeerling.com to hugo, comments and search have been broken. Your migration to Hugo has just begun, you did the easy hugo part and created a post suggesting it was done. But the extra phases and tickets for comments and search suggest there's no obvious and easy answer on how to finish migrating interactive bits to an SSG.

      Custom server side software is a complete solution, SSGs restrict what your complete solution can be without being one themselves. Nobody really seems to mention this until they move away from SSGs.

      (Sorry for the bluntness again! Thanks again for your content, I stumble across your stuff all the time. I migrated my dad from a Windows XP machine to a Pi, and your resources are particularly useful and accessible for both of us!)

      2 replies →

But how in the world will you shove a decent search into a static site?

I really want to know because there is a Drupal 7 site that I need to migrate to something but I need good search on it (I’m using solr now).

Edit: I should have specified that I need more functionality than just word searching. I need filtering (ie faceted search) too. I’ve used a SSG that uses a JavaScript index and appreciate it, but that’s not going to cut it for this project.

  • The usual way is to create an index on generation time and serve it statically. JS just uses the index to do the search. It's a big file, so I'm not saying it's a great solution for everyone, but it works reasonably well.

    Of course, for my site I just redirect the user to a search engine plus `site:stavros.io`.

  • See https://gohugo.io/tools/search/. Not sure how well they scale to thousands of posts, but they work by statically generating multiple static search index files at build time that are queried via client JavaScript when hosted. The search UX is actually really good because they tend to respond instantly as you type your query and allow complex queries.

  • > there is a Drupal 7 site that I need to migrate to something

    You may be interested in Backdrop, which is a maintained fork of Drupal 7.

    https://backdropcms.org/

    (No experience with it personally. Only know about it from a friend who uses it.)