3 ms·

I disagree. Over engineering does not relate to a particular framework. In fact, you can over-engineer with any tech. It's the design of the system what defines

I disagree. Over engineering does not relate to a particular framework. In fact, you can over-engineer with any tech. It's the design of the system what defines that (e.g microservices vs monolith for a small web app). It's a simple monolithic application with a relational database. Does this sound like over engineering? I don't think so. It's actually the opposite. Which one seems like an overkill, Server A or Server B (https://pbs.twimg.com/media/CngB1sfWIAAbOFi.jpg https://pbs.twimg.com/media/CngB1sfWIAAbOFi.jpg)? ;)

k__ 10y ago
So you're implying that a simple service that could be implemented with Sinatra should not be considered over engineered because the dev tried to hammer on the problem with Rails? Background: Just today I read that DHH considered Phoenix pretty cool, but Rails is enough if you don't need the real-time features. Anyway, of course you can build your services how you like and it's probably a lot fun to use Phoenix :D
- rafapaez 10y ago
  - If I have to choose a Ruby tech, I would go for Rails, no Sinatra, no Padrino, nop. Whatever you think is simple now it will change in the future. So start with what you know well and has everything you might need, even if you're not using it now. I've seen many "small" services being rewritten in Rails for this reason and that's painful and a waste of resources. - Nowadays I have several reasons not to use Rails for new projects (https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/ https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-...). But I actually I have more reasons to use Elixir instead (https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f847b58#.guroqbfmf https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f...) (http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the-future-of-web-apis-and-apps/ http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the...). And yes, it's fun, incredibly robust and scalable. :D

k__ 10y ago

So you're implying that a simple service that could be implemented with Sinatra should not be considered over engineered because the dev tried to hammer on the problem with Rails? Background: Just today I read that DHH considered Phoenix pretty cool, but Rails is enough if you don't need the real-time features. Anyway, of course you can build your services how you like and it's probably a lot fun to use Phoenix :D

rafapaez 10y ago
- If I have to choose a Ruby tech, I would go for Rails, no Sinatra, no Padrino, nop. Whatever you think is simple now it will change in the future. So start with what you know well and has everything you might need, even if you're not using it now. I've seen many "small" services being rewritten in Rails for this reason and that's painful and a waste of resources. - Nowadays I have several reasons not to use Rails for new projects (https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-rails-for-a-new-company/ https://blog.jaredfriedman.com/2015/09/15/why-i-wouldnt-use-...). But I actually I have more reasons to use Elixir instead (https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f847b58#.guroqbfmf https://medium.com/@kenmazaika/why-im-betting-on-elixir-7c8f...) (http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the-future-of-web-apis-and-apps/ http://blog.carbonfive.com/2016/04/19/elixir-and-phoenix-the...). And yes, it's fun, incredibly robust and scalable. :D