Skip to content
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

How to customize serverless-iiif #20

Closed
ryantomaselli opened this issue Jun 1, 2021 · 3 comments
Closed

How to customize serverless-iiif #20

ryantomaselli opened this issue Jun 1, 2021 · 3 comments

Comments

@ryantomaselli
Copy link

Hey guys;

Firstly thanks to all who built serverless-iiif. It's working great.

I have need to override the headers that are returned here:
https://github.com/nulib/serverless-iiif/blob/v2.0.1/src/index.js#L46

Also, would it be possible to allow for more than just tiff images on this line:
https://github.com/nulib/serverless-iiif/blob/v2.0.1/src/resolvers.js#L7

Is there intention to make those bits configurable?
Is there a reason for having the service only work on tifs?

Thanks for any pointers.

@mbklein
Copy link
Member

mbklein commented Jun 1, 2021

Hi @ryantomaselli! Thanks for asking. A little background about the project may help. serverless-iiif was originally developed as a small proof-of-concept repo extracted from a bigger project I wrote to serve up images for NU's Digital Collections. It's since grown into a full-fledged project, but it still has some code in it that belies its “minimum viable demo project” roots.

The TIFF limitation isn't a hard technical limitation – the server will work with whatever source image you give it, as long as it can be read by the sharp image library. I chose pre-tiled pyramid TIFFs because they already have multiple resolutions and tiles embedded in them, so sharp can carve them up more efficiently than other formats. But as long as the source image is accessible and sharp can parse it, it should be fine.

Same with the headers – I went with a sane default for a public server just to prove the concept.

The hard-coded .tif extension is easy enough to change – resolvers.js is meant to be the file that gets overridden and customized for specific configurations anyway. So the short answer is that the things you mentioned are not difficult to change, but they're not configurable – you'd have to fork the repo, make those changes in code, and deploy your customized version.

In that vein, perhaps moving the response headers into a resolver would solve that issue for you as well, along with more documentation on how to easily deploy a customized version of the server. (Did you deploy your existing service using the Serverless App Repository link, or the command-line sam tool?)

We're just now working on moving serverless-iiif out of Northwestern University Library's GitHub organization an under the umbrella of the Samvera Community. I'll still be maintaining the project, but I'll have more help and hopefully some additional perspectives and use cases to make the service more generalizable.

@ryantomaselli
Copy link
Author

Ah! Thanks for the detailed response @mbklein, that helps.

Yes I did deploy using the Serverless App Repository link and I made the edits to those 2 files using AWS Console directly (for now).

Some documentation on "how to easily deploy a customized version of the server" would be unreal.

Great to hear this project will getting more investment!

@mbklein
Copy link
Member

mbklein commented Oct 21, 2021

@ryantomaselli serverless-iiif now supports an alternate customization method – the use of a CloudFront distribution with a viewer-request function to handle things like file resolving (as above), as well as authentication/authorization and other things. Full documentation for it isn't available yet, but there's an early draft/intro in the README, and issue #53 calls for improved customization docs.

@mbklein mbklein closed this as completed Oct 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants