feat: get attachment and icon URLs without async requests #97
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Aug 28, 2025
achou11
approved these changes
Aug 28, 2025
This was referenced Aug 28, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an initial fix for #96. This almost entirely removes RPC requests for icon and attachment URLs, by making a single request for the server port, and then returning all other URLs synchronously.
This includes a "hack" because we do not expose a method for getting the server port, and instead we use the existing
getBlobUrlmethod with fake data to parse the port. Because the server lifecycle is maintained by application code, not comapeo-core, it probably doesn't make sense for core to implement an API for the server port, but instead create an API in application code and pass a getPort function to core-react, however that can be a follow-up that requires deeper changes.This moves logic for URL structure into this library, temporarily, which needs to be kept in sync with the URL structure defined in the fastify plugins in Core. In a follow-up we can export functions from Core, or an extracted "core blob server", which will move the URL structure logic into one place, but this temporary fix is the quickest for now that minimizes changes to different modules.
This is slightly "hacky" under the surface, but the advantage is that there are zero API changes, and no changes needed to Core or application code, and it should just work with a significant reduction in requests for URLs.
Follow-up work can clean this up, see #96.