Re:Introducing Fly Edge Apps
by boundlessdreamz on Thursday April 05, 2018 @01:06AM
(#16761929)
What do you mean by "It's already in memory"? If I build an app now and abandon it, will it always be in fly edge memory? I'm sure that's not the case so can you explain that further
Cool! There's obviously some competition coming from the various CDNs and cloud providers, but it's an interesting space and I wish you guys the best. I haven't really wrapped my head around the use cases yet (almost need a distributed edge database before it really ramps up the value) but I'll be playing with this for sure.
We're still discovering the use cases ourselves! We totally agree about an edge db, though.
Right now it's _best_ suited for building proxy-like applications. Aggregating APIs, speeding up existing apps without touching them, user aware caching, etc.
But we're getting constant pressure to expand the scope of what they do, too, which is pretty exciting.
Thinking about this some more: it would be very straightforward to implement a leveldown API on top of fly.cache. That, paired with something like PouchDB, would give you an edge database. You could have one big centralized CouchDB server with a bunch of PouchDB clients at the edges.
Hmmm...
This + persistence (even a simple key/value store with range queries on the index) would be awesome. I use Lambda+DynamoDB for small projects and it feels like driving to the grocery store in a steam roller.
That is a fabulous analogy. I think we'll have something interesting in the next few months, maybe we'll even get the honor of popping up on HN again!
Hey Kurt - Fly user here, I’m definitely a fan of your toolset. It has made last mile/server availability management really simple for us. Above, when you mentioned toying around with various oss faas tools, which ones did you all try out? Any lessons learned to share?
There's no warmup time. We spent some time with various OSS FaaS tools and that was pretty killer. When you deploy, we build a v8 snapshot of your code, then push it out to all the Edge Servers. It's already in memory and ready to rock when a request comes in — less than 1ms to get to your code for most apps.
fly.cache does persist, although it will vary per region (that's a surprising thing we learned about CDNs, cache contents vary per region quite a lot). It's volatile so you shouldn't rely on it for durable data storage, but you also pay for what you use so we have a strong incentive to not evict cache data any more than you request. :)
The global context _can_ be shared between requests but you can't really count on it. There's no guaranty that one request will run in the same context (or isolate or server) as a previous one.
We have some ideas for more durable and structured storage down the road. Building APIs that are location agnostic is fun, but a little mind bending.