Although there isn’t an “official” lib for Stripe (I know it’s just an example) but since you mentioned it, the stripity_stripe is pretty much ok and well maintained - it also allows you to pass additional params into all requests or generate custom requests, so basically even if Stripe’s API is incremented accepting new key-values or new endpoints, you can use them even if stripity_stripe hasn’t been updated.
I also understand the value of having libraries for interacting with common API’s, but on the other hand I think it’s a bit overrated - if I was not asked specifically to use libraries for those interactions, I personally would just use the actual HTTP API. In the case of the most used/relevant ones they’re pretty much well designed and you’ll only be using a very small subset of their functionality - every time I have to use a lib, I have to read the docs of the official HTTP API of the provider and the docs of the lib - and this is not to say they’re not valuable - it’s just they can get out of sync and then there you go hunting for what there’s a mismatch.
I think yours are valid concerns, if you’re developing something you don’t have to worry about writing the interface for the HTTP API and just use something that “no one was fired for using this lib” (in the sense it’s the official, sanctioned one), and writing it might take a toll because handling the API’s responses is not your domain problem. I still think though that in the overall scheme of things it’s a minor part, and eventually after you do it once, it shouldn’t be that time consuming doing it twice or thrice.
Just my opinion, not sure it’s worth even a $0.01 but that’s how I see it.
(and this in the context of the other things the BEAM gives you almost for free, of course all things being equal, without such runtime, there would be no reason to go with a language that has a smaller ecosystem)
