Hacker News new | ask | show | jobs
by etdev 1408 days ago
Thanks a lot!

Here's the basic stack:

• Rails API

• Vue SPA w/ ViteJS

• MySQL

• K8s on Digital Ocean

• Cloudflare worker + caching

• Bento for emails

• Algolia for search / filters

I wouldn't recommend using a client-side rendered application for a project like this though... that was a mistake. Tons of headaches with SEO, social media sharing etc.

2 comments

This is so complex! Wouldn't just vercel next.js + prisma be simpler?
Yeah definitely.

I just used the stack I was used to, didn't really turn out to be the best stack for the job...

Kubernetes is completely unnecessary, although I do enjoy using it.

Having a separate API is kinda nice. I could easily spin up a different front-end like an iOS app and share the same API. And I can write all the server code in Ruby instead of JS, which I prefer to do.

But yeah overall, way over-engineered.

Can you explain more about these headaches? So far i'm still convinced of client side SPAs :D
To see your page content, crawlers need to load your JS and wait for it to hydrate the page.

Google does this (but it's still not ideal). Most other crawlers don't. That means they won't see your rendered content.

This becomes an issue with sharing on social media, because your meta tags won't be read properly. If you share a blog post on Twitter for example, it won't be able to fetch your og:image, title etc so it won't look good.

To fix that, you have to use prerendering or server-side rendering. I'm doing hacky stuff with prerendering inside a Cloudflare worker where it detects that it's a crawler and prerenders the page if so.

SPAs also tend to have slow initial load times, which is becoming increasingly important for SEO. You can't avoid at least one additional network call after loading the initial HTML, and if you're not careful you can end up with chained requests for different components etc.

For sites like mine that rely on SEO and social media, it's a pretty big annoyance.

Thanks for your input! server-side rendering should fix most of the first issue. You can get all the relevant data pre-rendered and it's pretty easy to do with the right framework. I've used quasar.dev for this in the past. It should also solve the initial load times (to an extent). The chaining can be fixed with lazy loading/code splitting.

The only thing i haven't fixed yet is hiding the cookie banner for bots :/