3 ms·

> Ecto prevents N+1 queries by default, which I think is clearly better. To be fair... If you want to protect yourself from these with Rails you can install B

by nickjj 6y ago

> Ecto prevents N+1 queries by default, which I think is clearly better. To be fair... If you want to protect yourself from these with Rails you can install Bullet[0] and get protection through in your face notifications, and you have the option to let it slide because you're taking advantage of caching with Rails and in this case you know what you're getting into and the N+1 query with caching ends up being better because you understand your domain. Rails also has the strong migrations[1] gem which is a huge help for not shooting yourself in the foot for running migrations in production by helping you avoid table locks and other issues / errors. But AFAIK there's no Ecto equivalent, but strong migrations is really really useful. Rails also has the data-migrate[2] gem which is a nice little abstraction for splitting out your schema changes and backfilling data in an automated way. There's nothing like this with Ecto. This one isn't as useful as strong migrations IMO but it's still very handy to have this problem taken care of for you without having to re-invent a new strategy in every project or copy code over. Basically all 3 of these things are something I'd use in every Rails project but with Phoenix I wouldn't have these things except for N+1 query protection. I'm pretty sure you could technically create strong migrations and data-migrate for Ecto but the reality of the situation is today neither of them are available and there's no sign of them coming anytime soon. Meanwhile strong migrations has had ~6 years worth of real world testing at this point. [0]: https://github.com/flyerhzm/bullet https://github.com/flyerhzm/bullet [1]: https://github.com/ankane/strong_migrations https://github.com/ankane/strong_migrations [2]: https://github.com/ilyakatz/data-migrate https://github.com/ilyakatz/data-migrate

techpression 6y ago
For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem, just the general mindset in the Ruby and JS world (although Ruby is a lot better) to just go and depend on the work of others for core functionality.
- nickjj 6y ago
  > For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem. I think this is a really great discussion point btw because depending on a ton of 3rd party libraries that come and go can be an issue for sure. But at some point you need to live in the moment and align your expectations with the current reality and think about what happens to your code base if the library stops being maintained. For example, strong migrations has a 5+ year track record and shows no signs of dying. It doesn't make sense to live your life in fear and avoid 3rd party libraries because one of them might go away in the future because the maintainers get bored or stop using it. Because what happens if that doesn't happen and it ends up being wildly popular and maintained for years? The reality is a lot of people develop libraries, use it for a while time and then move on. This happens in Elixir too. The ExAWS package comes to mind (the most popular AWS package for Elixir). Similar things happened with Arc (file uploads) too. Eventually those tools got replacements or new maintainers. If you're developing an application it makes sense to weigh the pros and cons on using certain libraries but it's not like these libraries immediately go away. Usually there's a huge amount of notice before a library becomes officially dead. There's also tons of opportunities to talk with the authors and collaborate with the community to keep it going. And in this case, the outcome is likely a lot better than you trying to develop a custom solution in total isolation that's not open source. So yeah, there's really no downside to using most 3rd party libraries. Either it fits your app well enough and continues to be maintained while you happily use it (and maybe contribute back changes), or it fizzles out and you got some value out of it and now you have a great head start in implementing a custom solution from it for your unique use case.
ch4s3 6y ago
I will grant that strong_migrations is really cool, and data migrate is nice but not really that hard to implement yourself if you need that. Bullet however IMHO is a way overly complicated way to solve for N+1 queries. I would argue that eager loading associations by default is wrong and a thing ActiveRecord shouldn't do at all. You can opt in to preloading with Ecto when you consciously want to make the tradeoff, which I think is a better default approach.

by nickjj 6y ago

techpression 6y ago

For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem, just the general mindset in the Ruby and JS world (although Ruby is a lot better) to just go and depend on the work of others for core functionality.

nickjj 6y ago
> For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem. I think this is a really great discussion point btw because depending on a ton of 3rd party libraries that come and go can be an issue for sure. But at some point you need to live in the moment and align your expectations with the current reality and think about what happens to your code base if the library stops being maintained. For example, strong migrations has a 5+ year track record and shows no signs of dying. It doesn't make sense to live your life in fear and avoid 3rd party libraries because one of them might go away in the future because the maintainers get bored or stop using it. Because what happens if that doesn't happen and it ends up being wildly popular and maintained for years? The reality is a lot of people develop libraries, use it for a while time and then move on. This happens in Elixir too. The ExAWS package comes to mind (the most popular AWS package for Elixir). Similar things happened with Arc (file uploads) too. Eventually those tools got replacements or new maintainers. If you're developing an application it makes sense to weigh the pros and cons on using certain libraries but it's not like these libraries immediately go away. Usually there's a huge amount of notice before a library becomes officially dead. There's also tons of opportunities to talk with the authors and collaborate with the community to keep it going. And in this case, the outcome is likely a lot better than you trying to develop a custom solution in total isolation that's not open source. So yeah, there's really no downside to using most 3rd party libraries. Either it fits your app well enough and continues to be maintained while you happily use it (and maybe contribute back changes), or it fizzles out and you got some value out of it and now you have a great head start in implementing a custom solution from it for your unique use case.

ch4s3 6y ago

I will grant that strong_migrations is really cool, and data migrate is nice but not really that hard to implement yourself if you need that. Bullet however IMHO is a way overly complicated way to solve for N+1 queries. I would argue that eager loading associations by default is wrong and a thing ActiveRecord shouldn't do at all. You can opt in to preloading with Ecto when you consciously want to make the tradeoff, which I think is a better default approach.