[HN Gopher] Blueboat, an open-source alternative to Cloudflare W...
       ___________________________________________________________________
        
       Blueboat, an open-source alternative to Cloudflare Workers
        
       Author : ushakov
       Score  : 96 points
       Date   : 2021-11-23 18:39 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | tmikaeld wrote:
       | This is open source serverless functions that implement Web API
       | functions.
       | 
       | Some distinctions:
       | 
       | 1. Cloudflare Workers are Isolates, Blueboat are processes.
       | 
       | 2. Cloudflare Workers are globally distributed and working in an
       | anycast network, blueboat doesn't manage the network layer and
       | are not distributed.
        
         | mnutt wrote:
         | My recollection is that Cloudflare Workers uses Isolates, but
         | also employs various process-based strategies. More detail
         | here:
         | 
         | https://developers.cloudflare.com/workers/learning/security-...
        
       | nikivi wrote:
       | I thought the reason why Cloudflare Workers were great is that
       | they utilize the many CDN points that Cloudflare owns. Or you can
       | use Blueboat with say Fastly and achieve nearly the same thing?
        
         | zild3d wrote:
         | Same, the cloudflare workers tagline is "Deploy serverless code
         | instantly across the globe to give it exceptional performance,
         | reliability, and scale." Maybe I missed something in the
         | blueboat readme, but don't see how this deploys across the
         | globe and scales automatically
         | 
         | How about 0ms cold starts?
         | 
         | Is this actually open source cloudflare workers or just open
         | source serverless functions?
         | 
         | https://workers.cloudflare.com/
        
         | shoelessone wrote:
         | Same (blue) boat here.
         | 
         | To be honest, how Cloudflare Workers work is a bit of a mystery
         | to me as I've only done some very basic prototyping with the
         | service (and not really focusing on the "edge" aspect of them),
         | but it seems like the important "stuff" that makes them what
         | they are is how they are deployed.
         | 
         | I am REALLY going to show my ignorance here, but is there some
         | chance that the idea is these "workers" are intended to be
         | deployed in the users browser for example, as actual service
         | workers or something? i.e. is this more of a framework for
         | creating service workers vs running in the "backend"?
        
           | ushakov wrote:
           | i think cloudflare worker is basically like a browser tab
           | 
           | the only difference is that your browser is cloudflare and
           | globally-distributed
        
           | emj wrote:
           | Cloudflare workers are executed on servers and quickly thrown
           | away, they use APIs that make this clear as well, it has
           | nothing to do with service workers. Could you expand a bit on
           | you question?
        
           | beepbooptheory wrote:
           | Cloudflare workers != js workers. Kinda seems like that's
           | what you are talking about at the end. In my understanding,
           | Cloudflare workers, and "edge" stuff generally, are more like
           | ephemeral server processes that can happen per request, which
           | are backed by some kind of extensive infrastructure that
           | cloudflare, aws, et al can provide.
           | 
           | Its not a server, but the promise a server will be there if
           | someone hits that endpoint. Anything client side is not
           | changed.
        
         | mnutt wrote:
         | Cloudflare Workers have their own additional compelling value
         | prop in operating on the edge. But I think something like this
         | could offer a lot of value for a different use case:
         | 
         | In building complex SaaS apps, there's usually a constant flow
         | of customer requests for custom features. Scripting, if managed
         | very carefully [0], can provide an outlet for that and also
         | allow people to glue together different features. AWS pushes
         | people towards Lambda for customizing/gluing different AWS
         | services.
         | 
         | A product could use AWS Lambda for its own scripting/glue, but
         | that may end up being a little bit too free-form and depending
         | on the use case Lambda cold start times may be unacceptable. So
         | something like Blueboat could eventually be useful for running
         | untrusted code to power customization of SaaS apps. This is
         | especially the case if your service isn't marketed toward
         | developers who can easily run their own Lambdas.
         | 
         | [0] Opening your app to scripting automatically exposes a huge
         | API surface area which you'll likely have to support for a long
         | time.
        
       ___________________________________________________________________
       (page generated 2021-11-23 23:00 UTC)