Open bodom0015 opened 2 years ago
One thing that might alleviate one of the above concerns is that it looks like the official set of generators has been xpanded and now includes a generic typescript-fetch
that appears to support Blob responses: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/typescript-fetch/runtime.mustache#L295-L301
I have not used this variant myself, as I didn't think they offered a generic TS generator (last I checked there were only a couple for different versions of Angular), but I was able to generate without issues with their CLI tool:
clowder2-react-frontend % ./node_modules/.bin/openapi-generator-cli generate \
-i http://localhost:8888/api/v2/openapi.json \
-o src/generated-sources/openapi \
-g typescript-fetch \
--additional-properties=supportsES6=true,npmVersion=6.9.0,typescriptThreePlus=true
[main] INFO o.o.codegen.DefaultGenerator - Generating with dryRun=false
[main] INFO o.o.c.ignore.CodegenIgnoreProcessor - Output directory (/Users/lambert8/workspace/syngenta/clowder2-react-frontend/src/generated-sources/openapi) does not exist, or is inaccessible. No file (.openapi-generator-ignore) will be evaluated.
[main] INFO o.o.codegen.DefaultGenerator - OpenAPI Generator: typescript-fetch (client)
[main] INFO o.o.codegen.DefaultGenerator - Generator 'typescript-fetch' is considered stable.
... ... ... ... ...
[main] INFO o.o.codegen.TemplateManager - writing file /Users/lambert8/workspace/syngenta/clowder2-react-frontend/src/generated-sources/openapi/.openapi-generator/FILES
################################################################################
# Thanks for using OpenAPI Generator. #
# Please consider donation to help us maintain this project 🙏 #
# https://opencollective.com/openapi_generator/donate #
################################################################################
Could it be worth considering switching to the official typescript-fetch
generator if it might have better support for file downloads? I wonder if there are other use case gaps for openapi in the current generator... 🤔
This issue was uncovered during PR review: https://github.com/clowder-framework/clowder2-react-frontend/pull/41#discussion_r769123726
We now generate our OpenAPI client code from the spec produced by FastAPI. With this, we should get a client call that allows us to download a file from Clowder, as described by this endpoint in the spec:
Instead we appear to be unable to access
response.blob()
to fetch the actual file contents, as this is handled at a lower level by the generated code. Looking into it, the handling for this that we see in FastAPI's/docs
endpoint appears to be an abstraction that FastAPI has added over the top of OpenAPI:My reasoning for this thinking is that the official Swagger UI does not present this spec in the same way:
OpenAPI does offer a way to specify arbitrary types for response data, but even then I'm not sure if the generator supports it. I still need to experiment to see if this is even possible with the openapi-typescript-codegen generator that we currently use.
TL;DR: there may be a (possibly long) path to getting this implemented using the same codegen pattern we plan to use elsewhere, but ultimately this is not a REST-ful endpoint since it returns binary data. We can make this a lot easier on ourselves by simply making a manual request to that endpoint URL and already have the code that makes this work :+1: ideally if auth were shared between browser tabs, we would just need to open a new tab to that endpoint (see last point below)
Nice to have:
localStorage
to gain the added benefit of auth info being shared across different applications in the same domain. For example, if login to React viahttp://clowder.docker.localhost/login
saved a cookie, then we could open a new tab tohttp://clowder.docker.localhost/api/v2/users
(and hit the API directly). Since we have the same domain, our cookie from the previous tab will be passed along to a different application. This way, we would just need to open a new tab to that endpoint and the browser would automatically handle downloading the file contents and renaming the file. Adopting this pattern may be a much larger discussion, as supporting cookies comes with its own set of headaches (GDPR / privacy concerns, possible security vulnerabilities, etc). That said, this or something similar will be essential if we plan to enable SSO in the very very distant future.