Hacker News Reader

Comment by woutr_be | Hacker News Reader

Doesn’t this highly depend on your use case?

For example, right now I’m building a system that will take in a URL, crawls the webpage, and does some processing on the data. The whole process takes a good 10 seconds. I designed this as a micro service, simply because I know URLs will need to be queued up. Should this have been done as a monolith? Or am I right that micro services was actually the right approach?

View on HN

In rails this would be an activejob (part of the mono), and spinning up workers would be trivial. The "workers" would pull off a redis queue, and you could add different jobs to the queue easy-peasy.

That's fair, maybe I'm already planning to far ahead. But I ended up using RabbitMQ and Node (since i wanted to use Puppeteer for this, I actually needed to render the webpage).

Put Puppeteer calls in a REST API using Express or the like, call API from Activejob/Sidekiq. (I've built this)

Does this then not classify as two different micro services?

Not, it's adding a single microservice to a monolith.

Not sure how that’s different from my current “monolith” with a puppeteer micro service.

But either way, seems that my thinking with adding a micro service was kind of okay.

More than ok - you solved a problem without presumably rebuilding the core app (being presumptuous about the parts of your architecture undiscussed).

I did something like this too, and figured I'd rather do it for free as a lambda running under Vercel rather than create a droplet or something else and pay for it...

Reply on news.ycombinator.com