stripity_stripe
httpbeast
Our great sponsors
stripity_stripe | httpbeast | |
---|---|---|
3 | 5 | |
914 | 438 | |
1.2% | - | |
9.1 | 3.5 | |
30 days ago | 3 months ago | |
Elixir | Nim | |
BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
stripity_stripe
-
Don't be that open-source user, don't be me
I think this needs a big qualifier. I feel the same way, when it's a project I'm capable of doing the work for. For example, I recently needed a way to deal with Stripe early fraud warnings and the library I used didn't have those yet, so I added them (this was all on my own time I should add)[1].
However, there are tons of dependencies that we use for all sorts of things that are highly complex where very few people would be able to send a PR (openssl for example). Things in highly complex codebases, or deeply unfamiliar languages, etc. I maintain a forked linux driver for a wireless card for example, and I don't expect there's more than a handful of people that could hack on it without introducing tears and devastation.
For the projects I maintain, I would just say, "if you can, please consider a PR. If you're not sure it would be accepted I'm happy to be asked! If you can't send a PR, give as much info as you can and be polite. With that we're good.
[1]: https://github.com/beam-community/stripity_stripe/pull/728
-
Complete integration with Stripe in a Phoenix application
I recently had to create a subscription payment solution for Tolc, a C++ to other languages bindings compiler. During the process I wish I had a simple to follow, unassuming tutorial that I could follow. Since I couldn't find one, I wrote one myself! Even though I could use the excellent stripity_stripe, I still had to overcome some pitfalls.
-
Learning Ruby: Things I Like, Things I Miss from Python
I'm going to attempt to answer by way of links to active projects 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.
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.
httpbeast
- Nim v2.0 Released
-
Don't be that open-source user, don't be me
Thank you to the author for writing this.
Entitlement in open source is a massive problem, I have experienced it first-hand many times. The problem is that it discourages contributions not only from the existing maintainers but also from people who may volunteer to fix issues in the future. Would you be willing to contribute if most of the issues are just asking for things (often rudely) and not even saying thanks when an issue is resolved?
Unfortunately I have seen far worse examples than the one linked in the article[1]. I would encourage people to not only think twice before acting this way but to also call out people that are acting entitled in open source to discourage such actions.
1 - https://github.com/dom96/httpbeast/pull/35#issuecomment-7218...
- Nim Version 1.6 Released
- Nim 2.0 – Thoughts
What are some alternatives?
gringotts - A complete payment library for Elixir and Phoenix Framework
GuildenStern - Modular multithreading Linux HTTP+WebSocket server
Stripe - Stripe API client for Elixir
happyx - Macro-oriented asynchronous web-framework written in Nim with ♥
cashier - Cashier is an Elixir library that aims to be an easy to use payment gateway, whilst offering the fault tolerance and scalability benefits of being built on top of Erlang/OTP
jester - A sinatra-like web framework for Nim.
dnsimple - The DNSimple API client for Elixir.
cligen - Nim library to infer/generate command-line-interfaces / option / argument parsing; Docs at
unsplash-elixir - Unsplash API client for Elixir
prologue - Powerful and flexible web framework written in Nim
airbax - Exception tracking from Elixir to Airbrake
norm - A Nim ORM for SQLite and Postgres