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

Consider adding compression #155

Open
Siegrift opened this issue Dec 3, 2023 · 4 comments
Open

Consider adding compression #155

Siegrift opened this issue Dec 3, 2023 · 4 comments
Labels
on hold We do not plan to address this at the moment

Comments

@Siegrift
Copy link
Collaborator

Siegrift commented Dec 3, 2023

See: https://github.com/expressjs/compression/tree/88ba108ccebd131f336b7a0fa310f50bcc982992

Our responses are quite large and are well compressible. This could speed up the request-response time. Note that Signed API will be behind CDN so compression should only work if it's supported by the CDN.

@bbenligiray
Copy link
Member

Cool idea

Note that Signed API will be behind CDN so compression should only work if it's supported by the CDN

I don't understand why we care about the CDN if we will compress at the server side

@Siegrift
Copy link
Collaborator Author

Siegrift commented Dec 4, 2023

I think it needs to support the compression to understand that the response is compressed. For example, if someone asks for non-compressed version.

I don't think this is an issue (compression is standard for a long time) but It would be nice to double check.

@bbenligiray
Copy link
Member

Alternatively implement an alternative endpoint that serves the compressed version

@Siegrift Siegrift added the on hold We do not plan to address this at the moment label Dec 12, 2023
@Siegrift
Copy link
Collaborator Author

Siegrift commented Mar 7, 2024

What I mention here is not entirely accurate. When CDN gets a requests it computes "cache key" for it and looks whether it has something stored for this key. If yes, it sends the response. There are different ways how to create the cache key (often configurable), but AWS only looks at domain name and URL path. However, we can configure caching strictly on the CloudFront layer, without the origin support.

Another point to optimize would be pushing data from Airnode feed to Signed APIs. The problem is that both services are CPU bound and the compression optimizes bandwith, but for the cost of CPU (due to compression/decompression). So I am not keen on the idea.

I think it having CDN compression is kinda nice, especially since there is no code change. Still this doesn't feel worth the effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on hold We do not plan to address this at the moment
Projects
None yet
Development

No branches or pull requests

2 participants