4 ms·

Don't deal with event-driven architecture when you're at MVP stage. Also, which language and framework do you use? Because if you'd go with PHP/Laravel for exam

Don't deal with event-driven architecture when you're at MVP stage. Also, which language and framework do you use? Because if you'd go with PHP/Laravel for example, there is a neat SaaS solution called Spark: https://spark.laravel.com/ https://spark.laravel.com/

saluki 8y ago
y, recommend you check out the Rails and Laravel SaaS in a box offerings. Rails https://bullettrain.co/ https://bullettrain.co/ Laravel https://spark.laravel.com/ https://spark.laravel.com/ They are good to get up and running quickly, I used spark on a SaaS and it worked well. There are lots of great gems/packages that allows you to work without these though, if you want a little more control on how things are setup.
- CloudNetworking 8y ago
  Wow, that's awesome. Do you know of anything similar written in Python?
  - saluki 8y ago
    Doing a quick search I don't see anything, here's a HN thread from last year. https://news.ycombinator.com/item?id=18010871 https://news.ycombinator.com/item?id=18010871 Maybe a good opportunity for a Python developer to put one together?
- ElFitz 8y ago
  Tried looking for similar frameworks and offerings in Node.js, but no luck so far. That's too bad. Maybe I'll just pickup Rails ^^ Thanks!
ElFitz 8y ago
That would indeed have been better, but the product itself is pretty much à about handling and processing events, so... It feels like having the architecture not be event-driven when the whole product is about dealing with events would be the same as going the event-driven architecture route for, let's say, a knowledge-sharing SaaS But I will definitely keep spark in mind for the future, thank you :-)
Jackypot 8y ago
> Don't deal with event-driven architecture when you're at MVP stage Interested in why you'd recommend that? Event-driven architecture decouples everything up front and the benefits are immediate. In this scenario the introduction of billing is en excellent example. User does something they should be billed for? Raise an event. Listen to it to bill them. Next iteration needs to email the user or update some history? Listen to the event. And so on. All the ephemeral saas infrastructure stuff just hangs off of the domain. And writing the code that way really isn't much more onerous than otherwise so I wouldn't discourage it for an MVP.

saluki 8y ago

y, recommend you check out the Rails and Laravel SaaS in a box offerings. Rails https://bullettrain.co/ https://bullettrain.co/ Laravel https://spark.laravel.com/ https://spark.laravel.com/ They are good to get up and running quickly, I used spark on a SaaS and it worked well. There are lots of great gems/packages that allows you to work without these though, if you want a little more control on how things are setup.

CloudNetworking 8y ago
Wow, that's awesome. Do you know of anything similar written in Python?
- saluki 8y ago
  Doing a quick search I don't see anything, here's a HN thread from last year. https://news.ycombinator.com/item?id=18010871 https://news.ycombinator.com/item?id=18010871 Maybe a good opportunity for a Python developer to put one together?
ElFitz 8y ago
Tried looking for similar frameworks and offerings in Node.js, but no luck so far. That's too bad. Maybe I'll just pickup Rails ^^ Thanks!

ElFitz 8y ago

That would indeed have been better, but the product itself is pretty much à about handling and processing events, so... It feels like having the architecture not be event-driven when the whole product is about dealing with events would be the same as going the event-driven architecture route for, let's say, a knowledge-sharing SaaS But I will definitely keep spark in mind for the future, thank you :-)

Jackypot 8y ago

> Don't deal with event-driven architecture when you're at MVP stage Interested in why you'd recommend that? Event-driven architecture decouples everything up front and the benefits are immediate. In this scenario the introduction of billing is en excellent example. User does something they should be billed for? Raise an event. Listen to it to bill them. Next iteration needs to email the user or update some history? Listen to the event. And so on. All the ephemeral saas infrastructure stuff just hangs off of the domain. And writing the code that way really isn't much more onerous than otherwise so I wouldn't discourage it for an MVP.