First of all, I'm just here because tf-next build enables me to actually use my next-app in a manually configured environment using CloudFormation/SAM. Good job 👍 .
I want to understand why you made the decision to implement the launcher and bridge (the runtime of the lambda proxy) in a way that you create a local http server and call it directly from inside the code. It seems to me that this just creates a massive unnecessary overhead.
The only thing that is needed is the routing stuff from the generated now__launcher.js.
The render function can be called directly with mocked req/res objects:
const mod = require('./.next/serverless/pages/index.js')
mod.render(
{ headers: {}, url: 'http://127.0.0.1/' },
{
setHeader: v => { console.log('next:setHeader', v)},
getHeader: v => { console.log('next:getHeader', v); return undefined; },
hasHeader: v => { console.log('next:hasHeader', v); return false; },
end: console.dir
}
);
First of all, I'm just here because
tf-next buildenables me to actually use my next-app in a manually configured environment using CloudFormation/SAM. Good job 👍 .I want to understand why you made the decision to implement the launcher and bridge (the runtime of the lambda proxy) in a way that you create a local http server and call it directly from inside the code. It seems to me that this just creates a massive unnecessary overhead.
The only thing that is needed is the routing stuff from the generated
now__launcher.js.The render function can be called directly with mocked req/res objects: