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

Additional Response Headers #510

Open
johndcoy opened this issue Nov 4, 2022 · 3 comments
Open

Additional Response Headers #510

johndcoy opened this issue Nov 4, 2022 · 3 comments
Assignees

Comments

@johndcoy
Copy link

johndcoy commented Nov 4, 2022

Either to the Response Headers or Response data, it would be helpful to include last-modified - a date for when the item, monster, etc. was added to the SRC or last edited. This would help identify when an individual index ( i.e animated-shield ) was last modified.

Currently date Response Header outputs today's date.

@bagelbits
Copy link
Collaborator

That's going to be impossible given the current architecture. We currently nuke and replace the DB each time a change is added. We would need to first shift this to be selective upsert/delete depending on what has changed, which is a non-trivial task.
The only other way to handle this would be to manually set this value which is tedious and given the amount of items, potentially not worthwhile.

If you would like to take a crack at the more holistic approach, I give you full reign but it's not something I'm going to want to tackle right now given the complexity.

@fergcb
Copy link
Member

fergcb commented Nov 7, 2022

I can see how a Last-Modified response header would be useful for consumers who rely on caching. Perhaps a good compromise, that would be easier than redesigning the way we update the database, would be to provide the same Last-Modified datetime for every request to the API - the date when the database was last nuked/rebuilt.

The simplest way would probably just be to upsert a single document with a known _id into an admin or meta collection each time the database is deployed, which could then be queried to provide the Last-Modified date for each request.

This would take slightly less effort than running upserts/deletes for each document every time we redeploy. It wouldn't be perfectly granular, but it would allow clients to know when their caches might be out of date.

@bagelbits
Copy link
Collaborator

@fergcb I love that compromise. Thank you!

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

3 participants