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

with cloudflare workers #40

Open
ImPeekaboo opened this issue Dec 8, 2023 · 3 comments
Open

with cloudflare workers #40

ImPeekaboo opened this issue Dec 8, 2023 · 3 comments

Comments

@ImPeekaboo
Copy link

Thanks for your project, this is so useful.
Is it possible to make this work on cloudflare workers?

@warren-bank
Copy link
Owner

after reading this blog post that announced support for ES modules..

off-hand, I see 3 minor issues:

  1. the call to get_middleware would need to be made from a new entry point, which defines the params object
  2. the middleware.request method would need to be called from within the serverless fetch method.. and its parameters (ie: req and res) would need to be mocked in such a way that input data from Request is made available to the code.. and output data written to res is ultimately output through a new Response object
  3. HLS Proxy uses CommonJs modules, and it seems that Cloudflare Workers only supports ES modules.. so that's probably the biggest roadblock

at a higher level:

  • I'm not really sure that I see much benefit to doing this
    • compute-per-request is stateless.. so prefetch wouldn't be possible
    • isolates would allow saving a prefetch cache in memory, but I'm guessing the expense to do so would be prohibitive

le shrug..

to summarize:

  • this use-case can't be integrated into the project repo, since it would require switching from CommonJs to ES modules.. and that would break a lot of things.. since CommonJs imports occur at runtime and ES modules are loaded ahead of time
  • it probably wouldn't be very difficult to make a few changes that:
    • convert all require statements to use ES import syntax
    • either permanently enable or disable certain features, for example:
      • params.hooks
      • params.cache_segments
    • add the necessary boilerplate wrapper, for example:
      import {params} from './cf-worker-params.js'
      import {get_middleware} from './hls-proxy/proxy.js'
      
      const middleware = get_middleware(params)
      
      export default {
        async fetch(request, environment, context) {
          // https://developers.cloudflare.com/workers/runtime-apis/request
          // https://developers.cloudflare.com/workers/runtime-apis/response
          const response = new Response()
      
          // minimal mock for: https://nodejs.org/api/http.html#class-httpclientrequest
          const req = {
            url:     request.url,
            headers: request.headers,
            //...
          }
      
          // minimal mock for: https://nodejs.org/api/http.html#class-httpserverresponse
          // to do: migrate API input data to the `response` object
          const res = {
            writeHead: ()=>{},
            end:       ()=>{},
            //...
          }
      
          await middleware.request(req, res)
      
          return response
        }
      }

@warren-bank
Copy link
Owner

interesting rant.. which pretty much echoes my opinion exactly

it mentions something that I wasn't aware of..
maybe it was added later (after I'd already made up my mind about ES modules)..
which is that there exists an import() statement to allow dynamic imports..
asinine..
but would make the rewrite from CommonJs much easier.

@ImPeekaboo
Copy link
Author

I see.
Thank you for your humble response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants