> 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.

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.

> 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.

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 or 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.

Here's some links by way of an answer for you...

Stripe, including webhooks support, actively developed: https://github.com/code-corps/stripity_stripe

Global pay solution that supports everything: they are all a bit crap you're right, the best I've found is https://github.com/aviabird/gringotts and ex_money really is amazing that integrates with it (I would suggest it's better than the equivalent ruby gem). To be fair I'm not sure I'd want to use the pay gem with anything complex as you need to be able to use the specific quirks of each API properly (for example it can't pause subscriptions on stripe right now even though stripe supports this: https://github.com/pay-rails/pay/blob/master/lib/pay/stripe/...).

You're also right about noticed, after looking into it more it would be worth building for elixir for sure. Ravenx represents a start but it's unmaintained and doesn't have a huge number of strategies. It depends on how much I needed to do notifications like this. For the apps that I've built we've just needed database and grouped emails sent once per day, no need for texts or slack etc. There's no reason these couldn't be added fairly simply but I agree noticed is very neat. It's definitely a few weeks work to roll your own from scratch so to be honest I'd probably just integrate with Twilio and just pay for someone else to handle this for me.

Thanks.

> Stripe, including webhooks support, actively developed

I've looked into Stripity Stripe. For some time it was unmaintained and ended up getting taken over by another maintainer. It's also not as comprehensive as the official Stripe libraries. There's also a very big difference in using an official Stripe library and hoping for the best with a random one someone developed. Just skimming the code base it looks like the Checkout module is missing features that exist in the official Stripe library in every other supported language.

According to the README file for Stripity Stripe it's also using Stripe's API version from 2019. There have been multiple major API updates since then, and there's been an open issue since November 2020 to add support for newer API versions with no replies. Personally I would be using one of those major features too.

And this really is the point I'm trying to drive home. With Ruby, Python, Go, PHP, Node, Java and .NET these are problems you don't even need to think about. You just pick the payment provider's official SDK and start coding immediately, often times there's also an abundance of resources to implement the billing code itself into your app too through blog posts, official docs, YouTube videos, and even paid products like https://spark.laravel.com/. Stuff that makes integrating billing into your app (through Stripe, BrainTree and Paddle) being something you get done in 1 day instead of 3 months.

With Elixir it becomes weeks of comprehensive research, evaluating questionable libraries, opening PRs, and becoming a full time library developer just to get to the point where you could even maybe begin to start accepting payments with just Stripe. Then you have to repeat the whole process for PayPal, BrainTree and / or Paddle. These are all super popular payment providers.

> the best I've found is https://github.com/aviabird/gringotts

I asked the Gringotts developers if they would be supporting PayPal about 5 hours after they announced the project ~3 years ago. He said it was coming and to stay tuned. It's now ~3 years later and PayPal support isn't there. Neither is BrainTree or Paddle. Here's the open issue for PayPal support from 2018 (not by me, I asked on another site) https://github.com/aviabird/gringotts/issues/114. The Stripe integration is also missing a ton and hasn't been touched since 2018.

By the way, the Pay gem is really good. It's a smart abstraction and supports a ton of different subscription / 1 off payment use cases. Even complex ones like the type of app I was building.

> It's definitely a few weeks work to roll your own from scratch so to be honest I'd probably just integrate with Twilio and just pay for someone else to handle this for me.

Twilio ends up being 1 potential delivery method, it's not really someone you pay to solve the problem for you.

There's wanting to show notification in the app over websockets, saving them into a database, emailing them out only if they are unread, maybe sending a text through Twilio, Slack and other providers.

The noticed gem handles all of this for you (and supports Twilio too).

Notifications in general is another example where other frameworks have this solved in very good ways, but it becomes another example where you have to stop developing your app and start developing a notification library with Elixir.

At this point we've only talked about payments and notifications too. There's lots of other examples and these are all things to think about if your goal is to build an application.

Now don't get me wrong, it still takes a lot of custom code and effort to build an app with Rails but the time spent isn't on low level generic problems. It's letting you focus on your custom application's business logic.

And with less opinionated frameworks like Flask you can lean on Python being extremely well supported by almost every service that offers an SDK and also being able to find solutions to nearly every web dev problem online in some form or another (blog posts, youtube, stack overflow, etc.). That goes a long ways because at least you're not starting from scratch.

What I love with Phoenix/Elixir is that there's plenty of features I wouldn't bother with in a more traditional language. You want a PubSub? It's just there, you can use it in one line. You want a Redis? Registry is there, also in one line. It's like a whole tech stack in one language.

I saw a presentation about Phoenix/Elixir that described this once and it really impressed me. It's been 4 or so years that I've been meaning to pick up Phoenix for a project but still haven't.

Was it a publicly available online presentation? If, please share title or link if you can.

It was a slide from a conference I believe but I wouldn't know how to find it - some elixir people in the thread might know. It was something illustrating all the external tools you'd normally reach for and how Erlang/Elixir just had all of this built into the language and VM.

That sounds like one of Saša Jurić's talks:

GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić

https://www.youtube.com/watch?v=JvBT4XBdoUE

https://elixirforum.com/uploads/default/original/2X/a/a2524c... (also from Saša Jurić's book)

Thats it! Thank you!

Thanks.

You can watch this small twitter demo: https://www.youtube.com/watch?v=MZvmYaFkNJI. It's what sold me on the technology.

Thank you.

I want to use this, but every time I try to switch it is not there yet.

Sure it has the core stuff, but things like ActionMailer and the built in S3 support in ActiveStorage, Devise, keep me going back. Too many of those things are not there... yet ... with Phoenix

Also nothing beats active record after they added Arel which turns your query into an AST and optimizes it before sending it out - Ecto is not really there yet and doesn't look like it will get there

I think most packages are just as good if not better than their Ruby equivalents these days (and really we can do all of the things you mentioned in elixir), the active record pattern is obviously easier to understand than Ecto, but if you know how to write well optimised SQL you never want to go back to an ORM (even if it tries to rewrite your queries for you with magic).

ActiveRecord and the scenic gem for database views is a very powerful combination. For the vast majority of queries, you don't need to write optimized SQL by hand.

When you do, you can push that work to a version controlled database view, and wrap it in a ActiveRecord class interface and still get all of the ORM niceties.

The difference here is between two different philosophies:

1) I want the thing to just work, it doesn't matter about underlying complexity, give me the magic and the version controlled database view and the ORM niceties.

2) I don't trust magic as it has bitten me in the arse before, let me make and be able to fix things myself as I'm working at a (slightly) lower level.

I'm not saying either is correct but in Phoenix/Elixir magic stuff tends to be kept to a minimum. One man's "for the vast majority of queries" is another persons "will work fine until you need to do something complex".

It's all trade offs and I choose mine carefully as I'm sure you do.