-
Notifications
You must be signed in to change notification settings - Fork 850
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Streaming requests #1143
Streaming requests #1143
Conversation
300df71
to
10f05be
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I think this looks good and makes sense. Left a few comments. Thanks for putting together the test infrastructure! Curious what @ob-stripe thinks as well.
3c911af
to
ee83267
Compare
ee83267
to
5cfd645
Compare
r? @dcr-stripe this is ready for another review - I removed a test case that was unavoidably flaky and addressed feedback from the previous review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks Richard! 🚢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as well.
Not a huge fan of having to spin up a new process in tests for the test server, but it works and I can't think of a better way.
Reviews
r? @dcr-stripe @ob-stripe
cc @stripe/api-libraries
Summary
This PR adds "streaming" support to our HttpClient.
Similar to PRs in stripe-node, stripe-java, stripe-ruby, stripe-python, and stripe-go.
Up until now, all Stripe methods return JSON;
stripe-php
buffers the JSON into memory, parses it and constructs a StripeObject of the appropriate class before returning it to the user.We plan soon to release a
/pdf
method that will violate this pattern. It will return bytes that the user will likely want to write directly to a file or transmit to another server, without buffering into memory.Towards that end this pr introduces a
requestStreaming
method.requestStreaming
's implementation passes\CURLOPT_RETURNTRANSFER = false
and a callback functionin
\CURLOPT_WRITEFUNCTION
, that curl will then call with bytes from the body.requestStreaming
exposes a similar interface to the caller. The user passes in a callback$readBodyChunk
, whichrequestStreaming
will call with "chunks" from a successful request body as they arrive, before returning.Example of what the end-user experience will look like:
or see the test
I think in an ideal world, we'd return a PSR-7-compatible "stream" interface instead -- users have requested our responses be more PSR-7 compatible in the past. This, though, is the approach I think is most compatible with our current
CurlClient
implementation.