Stripy — micro wrapper for Stripe's REST API

Your Libraries & Projects Libraries
,
#1

Hey all,

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.

Hope someone else finds it useful!

Hex: https://hex.pm/packages/stripy
Hexdocs: https://hexdocs.pm/stripy/readme.html
Source: https://github.com/heresydev/stripy

12 Likes
Best Elixir Stripe library available?
#2

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 : https://app.quickdatabasediagrams.com/#/schema/JK2qGbfjvUe8q5aLMWcE2Q

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

1 Like
#3

You get high marks for simplicity. :slight_smile: 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.
2 Likes
#4

@soundstruck Glad to hear :thumbsup:

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

#5

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.

1 Like
#6

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

1 Like
#7

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

2 Likes

Our Sponsors

© Copyright Elixir Forum | Terms | Privacy & Cookies

Elixir Forum