3 ms·

> Phoenix and Elixir, if you understand the choices made, is also a wonderful choice Until you want to integrate Stripe, BrainTree, PayPal or Paddle and then y

by nickjj 6y ago

> Phoenix and Elixir, if you understand the choices made, is also a wonderful choice Until you want to integrate Stripe, BrainTree, PayPal or Paddle and then you can't find an official library for Elixir. Even common things like pagination isn't fully solved with well maintained libraries in Elixir. Then there's things like wanting to create notifications (showing unread icons, sending email / sns notifications, etc.) where Rails has this solved with well supported gems but there's nothing like this in Elixir. There's dozens of other things too, and all of this adds up to you having to be an expert in Elixir and have to write all of this functionality from scratch. If you're in it for the long haul and are investing years into the project with a big team that's fine, but if you're a solo developer building an app and want to focus on writing your app's features, in my opinion Phoenix can't really be compared to Rails. Especially with Hotwire Turbo being recently announced, now you can get all of those awesome real time features into a Rails app quite easily (IMO even easier than Live View). I started a SAAS app with Phoenix a while back and ultimately backed out of it because all of the above. It just felt like I was in a perpetual state of having to write libraries instead of my application. It was one of those things where I got super excited initially but after 2 years of trying, waiting for certain features to come, etc. it ended up not being for me. I have no regrets tho because I learned a really big lesson from that, which is if you want to build something now, use whatever tech stack you know right now and if you're very much inclined to deviate from that and learn something new then pick something based on what exists today in that tech stack. Not what's "on the horizon" or "coming soon". You could set yourself up for waiting forever, or if that feature you wanted in the future does come out it could be way different than what was originally claimed and now it feels like you've delayed what you wanted to do for so long for nothing. In other words, nothing is ever going to be perfect. Just pick something and build it. Also trust what folks do, not what they say.

andy_ppp 6y ago
I think often the things that don’t exist are not there for good reasons... using Stripe’s api for example from a module is pretty trivial in my experience, it’s just HTTP and you don’t need to be super clever about it. What specifically are you struggling to paginate, I’ve never found that difficult to implement even with quite clever options. Again notifications doesn’t sound particularly difficult and I don’t see why I’d want to rely on some complex gem that does every option when I don’t need them. Elixir+Phoenix I agree is definitely lower level but there are things it does much better than Ruby on Rails. I’d rather not have to rely on gems and write the simplest implementation specifically for my use case. It’s a trade off, but one I’m much happier with.
- nickjj 6y ago
  > I think often the things that don’t exist are not there for good reasons... using Stripe’s api for example from a module is pretty trivial in my experience, it’s just HTTP and you don’t need to be super clever about it. It's way more involved than inserting an auth token header into an HTTP request and calling some API endpoint. For example, what about verifying webhooks? The official libraries for Stripe (Python, Ruby, Node, PHP, Go, JS, etc.) deal with this for you. But with Elixir, you're on your own. This is very low level code to have to deal with and it's extremely important you get it right. You're left having to parse Stripe's specification on this and then implement the code yourself in Elixir. It's so tricky and involved that the Dashbit company (the creator of Elixir and members of the core team work there) wrote a blog post on it at https://dashbit.co/blog/how-we-verify-webhooks https://dashbit.co/blog/how-we-verify-webhooks. But before a few months ago that blog post didn't exist. Also this isn't the only thing you'll have to do yourself when it comes to interacting with Stripe using Elixir. Then you'll have to do similar things for other payment providers all which are different in a lot of ways, but with Rails you have the combination of having official Ruby clients from those payment providers and even the Pay gem which lets you support payments from multiple providers. That could easily be a few months of dev time just for that abstraction alone if you had to go about that from scratch and your implementation wouldn't have any track record until you start using it and ironing out the bugs from real world experience. > Again notifications doesn’t sound particularly difficult and I don’t see why I’d want to rely on some complex gem that does every option when I don’t need them Don't take this the wrong way but this seems to be the mindset of almost everyone I chatted with when it comes to Elixir. When someone asks how to do something, the answer is it's trivial or easy to implement but there's rarely any examples posted on how to do it and almost never in a production ready way. In my mind trivial or easy means I can sit down in maybe a few hours or a day and write a production ready solution, complete with tests and have it work exactly how I want without running into any major roadblocks. I'd be curious to see how you would implement https://github.com/excid3/noticed https://github.com/excid3/noticed or https://github.com/pay-rails/pay https://github.com/pay-rails/pay in Elixir / Phoenix. Based on your responses of saying these things are easy I'm guessing you've written large apps with Phoenix where you've developed features like this in a production app? It would be fantastic if you could post some code examples or a blog post on how you went about this. Not just to answer my specific question but I'm sure the community would appreciate having concrete examples of how it's done. This way maybe more folks would use the framework.

by nickjj 6y ago

andy_ppp 6y ago

I think often the things that don’t exist are not there for good reasons... using Stripe’s api for example from a module is pretty trivial in my experience, it’s just HTTP and you don’t need to be super clever about it. What specifically are you struggling to paginate, I’ve never found that difficult to implement even with quite clever options. Again notifications doesn’t sound particularly difficult and I don’t see why I’d want to rely on some complex gem that does every option when I don’t need them. Elixir+Phoenix I agree is definitely lower level but there are things it does much better than Ruby on Rails. I’d rather not have to rely on gems and write the simplest implementation specifically for my use case. It’s a trade off, but one I’m much happier with.

nickjj 6y ago
> I think often the things that don’t exist are not there for good reasons... using Stripe’s api for example from a module is pretty trivial in my experience, it’s just HTTP and you don’t need to be super clever about it. It's way more involved than inserting an auth token header into an HTTP request and calling some API endpoint. For example, what about verifying webhooks? The official libraries for Stripe (Python, Ruby, Node, PHP, Go, JS, etc.) deal with this for you. But with Elixir, you're on your own. This is very low level code to have to deal with and it's extremely important you get it right. You're left having to parse Stripe's specification on this and then implement the code yourself in Elixir. It's so tricky and involved that the Dashbit company (the creator of Elixir and members of the core team work there) wrote a blog post on it at https://dashbit.co/blog/how-we-verify-webhooks https://dashbit.co/blog/how-we-verify-webhooks. But before a few months ago that blog post didn't exist. Also this isn't the only thing you'll have to do yourself when it comes to interacting with Stripe using Elixir. Then you'll have to do similar things for other payment providers all which are different in a lot of ways, but with Rails you have the combination of having official Ruby clients from those payment providers and even the Pay gem which lets you support payments from multiple providers. That could easily be a few months of dev time just for that abstraction alone if you had to go about that from scratch and your implementation wouldn't have any track record until you start using it and ironing out the bugs from real world experience. > Again notifications doesn’t sound particularly difficult and I don’t see why I’d want to rely on some complex gem that does every option when I don’t need them Don't take this the wrong way but this seems to be the mindset of almost everyone I chatted with when it comes to Elixir. When someone asks how to do something, the answer is it's trivial or easy to implement but there's rarely any examples posted on how to do it and almost never in a production ready way. In my mind trivial or easy means I can sit down in maybe a few hours or a day and write a production ready solution, complete with tests and have it work exactly how I want without running into any major roadblocks. I'd be curious to see how you would implement https://github.com/excid3/noticed https://github.com/excid3/noticed or https://github.com/pay-rails/pay https://github.com/pay-rails/pay in Elixir / Phoenix. Based on your responses of saying these things are easy I'm guessing you've written large apps with Phoenix where you've developed features like this in a production app? It would be fantastic if you could post some code examples or a blog post on how you went about this. Not just to answer my specific question but I'm sure the community would appreciate having concrete examples of how it's done. This way maybe more folks would use the framework.