We (Heresy) recently open-sourced a tiny library for working with Stripe’s REST API. From the official package description:
Stripy is a micro wrapper intended to be used for sending requests to Stripe’s REST API. It is made for developers who prefer to work directly with the official API and provide their own abstractions on top if such are needed.
There are currently a bunch of other Stripe libraries available, but we didn’t like the provided abstractions on top of the official API, so we ended up with something fairly simple that works well for us and allows us to upgrade to newer Stripe API versions easily.
Interesting. I’m in the planning stages of integrating Stripe/subscriptions into my app, so this is quite timely for me.
I wasn’t thinking about a lag in the versions between library -> api…that makes sense. I’ll definitely have a good look at Stripy. I did something very basic and similar with the Spotify API, but mostly because I was using so little of the api.
I’m trying to work out the database side to support Stripe at the moment. If anyone has implemented stripe subscriptions and wouldn’t mind taking a look and giving feedback it would be greatly appreciated.
You get high marks for simplicity. Very good Mixfile too with nice docs links. I encourage all package makers to follow this example.
If you’re open to some feedback:
Document parse/1 with examples in the README and module, since it’s intended to be used.
Both headers/1 and url/3 don’t necessarily need to be public, since they’re not used by the user.
Let req/3 take config options to override the Application env, to make it more adaptable and testable. This is the most important point I can make.
Don’t return an HTTPoison struct, since it’s leaky, just use your own. If you drop down to pure Hackney or switch to another HTTP package, the user shouldn’t necessarily be bothered.
@christopheradams Thank you for the kind words, and feedback is much appreciated! About your last point on the HTTPoison struct, do you mean returning a custom struct when there’s an error, successful response, or both?
One or both. It’s not a terribly important issue; the idea is to keep your client code decoupled from the underlying HTTP package. If you have your own %Stripy.Response{} you can really own it and provide good documentation and typespecs.
This is not a universal recommendation. For example if your package works with %Plug.Conn{} there would be little advantage to re-creating your own version of it.
Very good Mixfile too with nice docs links. I encourage all package makers to follow this example.
