I have an issue with the Edge and I don’t understand what could be wrong. What I try to do (I’ve done the same with Cloudfront and Lambda@edge):
Visitor request → edgio → call a 3rd party API and wait for the response to add a header to the original request and add some header on the final response → call the origin
If I m using the Permalink which bypasses the edge, all is working as expected. But when passing through the edge I can see some response headers but they never change and I can’t see any call to the 3rd party API
I’ve checked my configuration and disabled the cache at the edge but nothing has change. It’s like during the build process, edgio cache my header result and keeps it, and that’s all.
It’s like during the build process, edgio cache my header result and keeps it, and that’s all.
If this is the case, it could be based on how everything is defined in the router. What you are doing should be possible. Are you able to provide your routes.js file here so I can review to make sure the right functions are being called for your desired behavior?
@rishi-raj-jain I can confirm your solution works! Thanks a lot.
To better understand my mistake: the compute() “force” the edge to execute the code? That’s why it didn’t work before as expected?
Edgio’s Serverless Compute is what actually runs each time on the serverless (not the edge). Enterprise customers can set their serverless locations to reduce the latency.
@pvr Going back to your original suspicion, I wanted to explain what’s going on now that I see your router.
It’s like during the build process, edgio cache my header result and keeps it, and that’s all.
When edgio build is called, it bundles the router during this process. For each route defined, it will invoke the handler you have defined at build time. So in your original example, the following is happening:
the async handler is invoked at build time
the cache rule is set to exclude the request from caching at the edge
a 3rd-party API call is made
a response header is to be set
the request should proxy to the origin and send back the response
Because all that is determined at build time, then every request is going to get that same header.
When you wrap it in compute() like @rishi-raj-jain described, it knows to process everything outside of compute() during the build, and everything inside compute() is handled in the serverless environment. So the flow is more like:
the async handler is invoked at build time
the cache rule is set to exclude the request from caching at the edge
the compute() identifies an async handler to be invoked in the serverless runtime
a 3rd-party API call is made at runtime
a response header is to be set at runtime
the request should proxy to the origin and send back the response from the serverless runtime
This way you can make your API call and dynamically set everything. Hopefully that helps a little.
