4 ms·

Can you self host these workers? Otherwise you get vendor lock in which is a no go.

• vonadz 5y ago
  Self hosting would pretty much defeat the whole purpose of workers. The point is that you don't need to self host.
  • lsaferite 5y ago
    Their point is, can you mitigate vendor lock-in if you need to do so? The fact that you don't even consider that is a sad commentary in itself.
    • deleted 5y ago
      [deleted]
    • vonadz 5y ago
      If their point was can you mitigate vendor lock-in, they should have said that instead of asking about self-hosting. Saying you have vendor lock-in because you can't self-host something is very strange in the context of this article. I didn't make a point of vendor lock-in because migrating this process flow to a self-hosted HTTP server would take about 5 minutes. On top of that, this flow is going to be very similar for any vendor offering javascript functions. Perhaps it is my fault for not including a section discussing this, but I assumed that the audience for this would primarily be people understand basic javascript and could deduce the portability of the code by looking at it.
  • nicoburns 5y ago
    The point is that you don't need to host them in production. Being able to self-host is still very useful for testing and local development workflows
• ignoramous 5y ago
  Yes, miniflare [0] lets you run Workers locally, but I wouldn't treat it to production traffic. There's also Deno, which is very similar in technology to Workers [1]. Others are building "Workers" atop WebAssembly, and things are looking up on that front as well [2][3]. See also: https://github.com/debarshibasak/awesome-paas https://github.com/debarshibasak/awesome-paas [0] https://github.com/cloudflare/miniflare https://github.com/cloudflare/miniflare [1] https://deno.land https://deno.land [2] https://github.com/suborbital/atmo https://github.com/suborbital/atmo [3] https://github.com/krustlet/krustlet https://github.com/krustlet/krustlet