File Download response.blob not available from generated client code

[bodom0015]

This issue was uncovered during PR review: #41 (comment)

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:

		"/api/v2/files/{file_id}": {
			"get": {
				"tags": ["files"],
				"summary": "Download File",
				"operationId": "download_file_api_v2_files__file_id__get",
				"parameters": [{
					"required": true,
					"schema": {
						"title": "File Id",
						"type": "string"
					},
					"name": "file_id",
					"in": "path"
				}],
				"responses": {
					"200": {
						"description": "Successful Response",
						"content": {
							"application/json": {
								"schema": {}
							}
						}
					},
					"422": {
						"description": "Validation Error",
						"content": {
							"application/json": {
								"schema": {
									"$ref": "#/components/schemas/HTTPValidationError"
								}
							}
						}
					}
				},
				"security": [{
					"HTTPBearer": []
				}]
			},

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 👍 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:

• If we can customize the return type in FastAPI with something that will play nice with the generator
• Otherwise, if there is a way to somehow mark that particular generated method as "don't use this" or "see other" or something, that would also be helpful
• Longer term: if FastAPI could accept multiple auth types then we could use Cookies instead of localStorage to gain the added benefit of auth info being shared across different applications in the same domain. For example, if login to React via http://clowder.docker.localhost/login saved a cookie, then we could open a new tab to http://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.

[bodom0015]

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... 🤔