3 ms·
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
by woutr_be 5y ago
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?
- baash05 5y agoIn 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.
- woutr_be 5y agoThat'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).
- bdcravens 5y agoPut Puppeteer calls in a REST API using Express or the like, call API from Activejob/Sidekiq. (I've built this)
- woutr_be 5y agoDoes this then not classify as two different micro services?
- bdcravens 5y agoNot, it's adding a single microservice to a monolith.
- woutr_be 5y agoNot 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.
- bdcravens 5y agoMore than ok - you solved a problem without presumably rebuilding the core app (being presumptuous about the parts of your architecture undiscussed).
- yawnxyz 5y agoI 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...