This can really cut both ways, and moderation is key.
I've seen software that's extremely overengineered. Something like ~15 microservices with data (for the same model) split across both Mongo and Redis, spun up via Docker configs hosted on Google Kubernetes Engine. Run by 1 person for a product with low (<1k DAU) traffic.
On the other hand, I've also seen software that's extremely _underengineered_. And that might not be a disjoint set. The same stack I mentioned above implemented an in-house search, task/message queue, deploy system, URL shortener, and mobile notification service - all with a more restricted and buggier API compared to more popular commercial / open-source offerings.
It's highly important to choose your areas of competence. What systems need to be better in X vs. off-the-shelf alternatives? And can you afford to dedicate time and money (through development and maintenance) to support it?
===
I'm going to state a likely unpopular opinion now, and advocate that most typical SAAS / CRUD projects start with Rails, and build from there. I say that because there are many, many well-maintained and battle-tested libraries that have already been vetted in that ecosystem, and the community's mantra is to optimize for engineering productivity (GSD and communication with other engineers) and happiness. There are libraries to set up an ingest pipeline [1], or a pooled background task system [2], or whatever other complex systems you need to build. But when you're just getting started, you want to set up an API with some validations against business logic, and ActiveRecord and Rails(-api) gets you pretty far very quickly for just that.
Another related unpopular opinion I hold is to avoid Node, unless you have a specific reason to use it. Yes, it's new and flashy, but the cost of that is that the ecosystem hasn't matured and tooling you'd expect doesn't yet exist. That's not to say that every new technology should be avoided. I think of it as investing in a sense - you need to place your bets correctly based on research like community, maturity, functionality, and possibly most importantly: how it compares to existing tools (and their trajectories).
> I'm going to state a likely unpopular opinion now, and advocate that most typical SAAS / CRUD projects start with Rails, and build from there.
<3
Rails can get you very, very, far. While it's sexy appeal has faded, it's real beauty has shone. I can hop into most rails codebases and be productive in a few hours. I can come back to my own projects and still understand whats going on. I think that's huge. Sure there are newer things out there, but nothing beats rails for productivity or maintainability and overall developer happiness - tenants i hold in high regard.
Exploring new tech is great - doing it in production is asking for trouble of all sorts. If you want to build something that lasts for a long time, build it as boring as possible.
I've seen software that's extremely overengineered. Something like ~15 microservices with data (for the same model) split across both Mongo and Redis, spun up via Docker configs hosted on Google Kubernetes Engine. Run by 1 person for a product with low (<1k DAU) traffic.
On the other hand, I've also seen software that's extremely _underengineered_. And that might not be a disjoint set. The same stack I mentioned above implemented an in-house search, task/message queue, deploy system, URL shortener, and mobile notification service - all with a more restricted and buggier API compared to more popular commercial / open-source offerings.
It's highly important to choose your areas of competence. What systems need to be better in X vs. off-the-shelf alternatives? And can you afford to dedicate time and money (through development and maintenance) to support it?
===
I'm going to state a likely unpopular opinion now, and advocate that most typical SAAS / CRUD projects start with Rails, and build from there. I say that because there are many, many well-maintained and battle-tested libraries that have already been vetted in that ecosystem, and the community's mantra is to optimize for engineering productivity (GSD and communication with other engineers) and happiness. There are libraries to set up an ingest pipeline [1], or a pooled background task system [2], or whatever other complex systems you need to build. But when you're just getting started, you want to set up an API with some validations against business logic, and ActiveRecord and Rails(-api) gets you pretty far very quickly for just that.
Another related unpopular opinion I hold is to avoid Node, unless you have a specific reason to use it. Yes, it's new and flashy, but the cost of that is that the ecosystem hasn't matured and tooling you'd expect doesn't yet exist. That's not to say that every new technology should be avoided. I think of it as investing in a sense - you need to place your bets correctly based on research like community, maturity, functionality, and possibly most importantly: how it compares to existing tools (and their trajectories).
[1] http://shrinerb.com/rdoc/files/README_md.html#label-Direct+u...
[2] https://github.com/mperham/sidekiq