search

ElementsProject / paypercall

Charge for HTTP APIs on a pay-per-call basis with Bitcoin and Lightning :zap:
https://www.blockstream.com/2018/03/25/paypercall-shows-the-full-power-of-lightning-charge.html
MIT License
148 stars 17 forks source link

Remove reliance on express to work as bare connect middleware #1

Open shesek opened 6 years ago

askmike commented 6 years ago

I would vote for an even smaller promise/async based API so that you can just add a few wrappers, this way supporting Koa for example is also easy. Even allows for easy integration with non HTTP based APIs.

shesek commented 6 years ago

I think that a (req, res, next) function feels more natural in the nodejs ecosystem as the low-level underlying implementation, with alternative implementations for promises, koa, etc built as a wrapper on top. Do you see an advantage to making the underling implementation promise based?

Note that paypercall is built on top of lightning-charge-client-js, which itself exposes a promise-based API that can be used directly for projects that needs more flexibility than what paypercall provides.

askmike commented 6 years ago

Note that paypercall is built on top of lightning-charge-client-js

This is what I meant. Apologies, I couldn't find this the first time I looked through the code!

Do you see an advantage to making the underling implementation promise based?

I agree that connect is a big standard in the nodejs ecosystem, it is probably safer to create a solid basis around a connect plugin over a barebone implementation (that would just wrap around lightning-charge-client-js anyway).

From a Koa perspective: there are ways to koafy a connect plugin on the fly, such as https://github.com/vkurchatkin/koa-connect but they are not as clean. Since promises and async/await is available natively I consider them to be cleaner. Though connect is so much bigger that it doesn't make sense.