-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat(PE-4472): add uploadFile, uploadSignedDataItem implementations for node and web #9
Conversation
218b5b8
to
42c2ed9
Compare
42c2ed9
to
7c454f5
Compare
* Alternatively instantiate your own clients independently. | ||
*/ | ||
const paymentService = new TurboUnauthenticatedPaymentService({ | ||
url: 'https://payment.ardrive.dev', |
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.
Writing down some aside thoughts on exposing our ArDrive Turbo "testnet"
This public test API (payment.ardrive.dev / upload.ardrive.dev):
- will accept Stripe Test Cards to reward Credits
- sends data to a live production gateway (arweave.net)
- posts optical bridge GQL info to prod gateway (arweave.net)
- has an optimistic data cache with dev gateway (arweave.dev)
- also accepts free data under 500 KiB
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.
I feel our testnet could offer developers great advantages during building. But our test data should expire and never make it to a live arweave node
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.
agreed - we may need to consider a separate public test environment that is low-cost for us but dev friendly
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.
also a good point to provide some testing utils and constants to help devs write unit tests with the SDK (e.g. test card numbers)
export async function readableStreamToBuffer({ | ||
stream, | ||
}: { | ||
stream: ReadableStream; | ||
}): Promise<Buffer> { |
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.
Doesn't streamToBuffer
gets a performance boost by including the content length?
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.
Yes, a big boost.
src/web/signer.ts
Outdated
async (streamGenerator: () => ReadableStream) => { | ||
// Convert the readable stream to a Blob | ||
const buffer = await readableStreamToBuffer({ | ||
stream: streamGenerator(), | ||
}); | ||
const arrayBuffer = Uint8Array.from(buffer); | ||
// convert the blob to a Uint8Array | ||
const dataItem = createData(arrayBuffer, signer); | ||
await dataItem.sign(signer); | ||
return dataItem.getRaw(); |
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.
Why do we need to convert from readable stream to buffer on the web path?
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.
Seems like if we got all the polyfills setup right for arbundles and the client sends a readable stream generator, we should be able to use the streamSigner like the node path
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.
streamSigner only supports Readables
at the moment - we might be able to create our own implementation that handles ReadableStreams
. right now ReadableStreams get loaded into memory (buffer) - so not optimal
Looking good, left some thoughts |
bd67dc5
to
8a79000
Compare
8a79000
to
50dd308
Compare
We actually do not need to worry about validating the signatures of signed data items sent to the SDK. They will just be forwarded to the Upload Service and it will be responsible for validating the signatures of those data items. Makes it much easier on the SDK side and avoids having to worry about verifying sigs in web vs. node environments.
…ovide multiple data items
3e9c475
to
8262c90
Compare
a88550c
to
6dc641d
Compare
src/common/payment.ts
Outdated
constructor({ | ||
url = 'https://payment.ardrive.dev', | ||
retryConfig, | ||
privateKey, |
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.
Consider abstracting this out into a Signer-like interface for which we could provide some basic implementations. But I just see it as something we'll almost certainly have to excise out in a later version as we begin to abstract for other chains or wallet connection types (e.g. ArConnect).
- change Public/Private interfaces to Unauthenticated<Service>Interface - update tests for uploading signedDataItems - add TODOs for creating ReadableStreams - cleanup examples
5a9a613
to
8f636b1
Compare
While we generally favor composition over inheritance, this pattern is easy to comprehend and avoids redunandancy for simp e HTTP requests that don't have unique implementations.
54b159b
to
b308861
Compare
We separate the builds into differnet tsconfig.json files so specific deps required in web do not get pulled into NodeJS environments and vice versa
Implement private in enviornment specific TurboFactory, update examples in README
0c00d10
to
b56216e
Compare
"./node": { | ||
"import": "./lib/node/index.js", | ||
"require": "./lib/node/index.js", | ||
"types": "./lib/types/index.d.ts" | ||
}, | ||
"./web": { | ||
"import": "./lib/web/index.js", | ||
"require": "./lib/web/index.js", | ||
"types": "./lib/types/index.d.ts", | ||
"browser": "./bundles/web.bundle.min.js" |
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.
these are intentional - and we may want to remove .
for node environments - the only exports available to clients are in lib/node/index.js
for web - the only exports available to clients are from lib/web/index.js
other utilities/common exports are internal and not able to be imported by consuming clients - this should make it very hard to use the SDK incorrectly
Two additional follow up comments:
|
🎉 This PR is included in version 1.0.0-alpha.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 1.0.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
TODO:
consolidate theGET/POST
requests to turbo into a TurboHTTPService class that abstracts away axiosaddAbortController
to uploadsimplementuploadSignedDatatItem
for web - there is no easy way to do this with ReadableStreams - so i may table the implementation for a separate PR (feel free to provide any thoughts, ChatGPT is a bit volatile in it's recs)handle signingReadableStreams
with something likestreamSigner
so they don't have to be loaded in memory - will plan to implement in a separate PRadditional testsrenamepublic
andprivate
static functions tounauthenticated
andauthenticated
Most Recent Updates:
TurboAreaveWallet
class - right now it wraps arbundlesArweaveSigner
depending on the environment (web
vs.node
) - we can move towards implementing ourselves if we want to avoid their stuffTurboHTTPService
that abstracts away axios configuration and handles AbortControllers passed to it. We may eventually want to move away fromaxios
so we could consider changing theCancelledError
to some custom errorBuild Configuration
@ardrive/turbo-sdk/node
includes the exports forNodeJS
environments@ardrive/turbo-sdk/web
includes the exports forBrowser
environments