Stripy — micro wrapper for Stripe's REST API

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.

Here’s where I’m at with it : QuickDBD

btw, sidenote, I love that app ^ for sketching out db thoughts!

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.

@soundstruck Glad to hear

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

Some recent updates to Stripy (latest: v1.2.0):

• Ability to pass options directly to HTTPoison
• testing mode that doesn’t fire HTTP requests
• Support for providing your own mock server and responses in testing mode

There’s a detailed example in the readme regarding testing mode/mock server.

I’m using Stripy in production now. So far, so good!