Support requests to wasm modules in http processor#2144
Merged
siddhantk232 merged 5 commits intomainfrom Jun 11, 2025
Merged
Conversation
We check if the url is part of a mounted app in the current package. If it is, then we try to create a wasm+proxy:// url for implicit wasm modules present in the app's directory. If the implicit wasm module does **not** exists, we simply bail by creating a full url (prefixed with http) and let the fastn server logic handle it when the http processors calls the full url.
Instead of returning an error in case of no resolution of the url. We simply return the full url (path prefixed with scheme+host) in hopes that fastn server logic will handle it. This is useful in situations like the following: ```ftd ;; index.ftd -- some-record-name d: $processor$: processors.http url: /local/ ``` ```ftd ;; local.ftd -- ftd.json id: 1 name: Someone ``` The resolved will convert url `/local/` -> `http://127.0.0.1:800/local/` (depends on running env) which is where the http request from the processor will be sent and fastn server will realise that it's a local file and will return the correct json response.
amitu
approved these changes
Jun 11, 2025
Contributor
|
Nice touch on the /ftd-file/ stuff! |
Contributor
|
It works with lets-teach. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Handle wasm modules in mountpoints of apps
TLDR: the following code works now:
/teach/backend/hello/maps to a "hello" handler defined in the backend.wasm module which is present atlets-teach.fifthtry.site/backend.wasm.Implementation details:
We check if the url is part of a mounted app in the current package. If
it is, then we try to create a wasm+proxy:// url for implicit wasm
modules present in the app's directory. If the implicit wasm module does
not exists, we simply bail by creating a full url (prefixed with
http/https) and let the fastn server logic handle it when the http processors
calls the full url.
Handle package local relative urls
This is useful in situations like the following:
Instead of returning an error in case of no resolution of the url. We
simply return the full url (path prefixed with scheme+host) in hopes
that fastn server logic will handle it.
The resolved will convert url
/local/->http://127.0.0.1:800/local/(depends on running env) which is where the http request from the
processor will be sent and fastn server will realise that it's a local
file and will return the correct json response.
NOTE: The http processor enhancements don't work with
fastn build. Another PR should at least add a better error message when the processors fails and should show hints (using full urls would make it work withfastn build) to fix it.fix: Wrong filename in the step to extract changelog
This will not let the CI generate the "What's Changed" section.