FSLY: The future of Apps on the Edge

Just some light stuff for the weekend…

Lately, I’ve been posting some points on FSLY’s much superior vision and tech about the future of Apps build for the Edge.

Sometimes, a POC ( proof of concept) speaks volumes compared to many pages of technical writing.

I’ve been thrilled with this and thought of sharing some dev excitement with you all! ( thanks to Leon Brocard who built this app):


Try it out! This app built on FSLY’s Compute@Edge, uses Markdown ( a lightweight markup language) in the left panel and converts it to HTML and shows you the final results in the right panel.

Do play around with it ( Try typing in what you like on the left) and see it rendered on the right panel. Can you imagine that it is processed almost instantaneously for every keystroke!!! That’s the direction of the future of apps! This would enable any user ( irrespective of location and distance from the central cloud) to have the same experience in terms of performance.

You just can’t achieve that if your application is just residing on a central cloud. FSLY’s C@E and high performance POPs are making this possible. I will be curious to see a proof of concept such as this from any of FSLY’s competitors ( including NET, who’s Workers use the V8 Engine that was built for browsers and not for the edge.) Do let me know if you can find an example?

Just like I mentioned in one of my recent posts, I feel it’s not too far when the power of C@E will start revealing the weaknesses of the competing solutions. This is the dev in me speaking, so please don’t take it as an input to drive your investment decisions. Personally, I still hold a slightly bigger position in FSLY compared to NET due to my bias.

Somehow, this reminds me of a story about a monk who spent years in a cave perfecting his martial art skills, while others masqueraded as champions until the monk emerged from the cave :slight_smile:




The magic! The app downloads the page you see and a bit of JavaScript


The JavaScript “listens” [input.addEventListener] as you type and sends the “input” [the black box] to the edge server [edgecompute.app] that processes it and returns the output to display on the right side of the page. Neat!

The downloaded edge “app” is very light unlike the huge block of JavaScript that Yahoo Finance uses which is quite a dog! The model Yahoo uses puts the burden on the client which is supposed to be a very capable laptop or desktop computer while the edge model puts the burden on the edge server instead of on the edge client which is probably some small, underpowered, battery powered device.

The curious thing is that shifting of the load from center to edge and back has occurred numerous times as the processing power of servers and clients wax and wane relative to each other.

Denny Schlesinger



Try it out!

This is html rendering using simple JavaScript. I don’t think, this example is doing any justice to the power of compute @ edge.


Hi ronjonb

thanks for that. It does (to me) highlight one of the confusing things about compute@edge, namely, you don’t need the edge (servers) at all for this use case.

You could just have a javascript library and run it on the client (the edge) which I do with the Saul Search page (it renders markdown). All those phone, computer edge devices are way powerful enough to do it.

I do admit I struggle a little with the use cases. Edge implies blindingly fast, and there aren’t (afaics) that many where speed is so critical. Most of the ones I can come up with are fairly simple (AB testing, data munging, personalisation…). Maybe something like autonomous vehicles? Can you come up with other use cases where proximity is so important?

be interested in your ideas



Here are a few use cases:

Autonomous vehicles
Fleet management
Predictive maintenance
Voice assistance


I am sure, Tele/Remote Health is another huge area of opportunity.

1 Like

Obviously this may be a bit one-sided, but you can look to the Cloudflare CEO’s comments on the latest earnings call for some color on this subject. Some of this has already been discussed on the boards a bit.


On use cases:

"One of the most viewed publications during the 2020 elections use Cloudflare workers to power their elections news platform, and ensure its scale during the unprecedented spike in traffic last Tuesday, as well as Wednesday and today. A popular health food company uses workers to power their online ordering system. An online marketing firm working with major brands uses workers to customize content on a per visitor basis. A publicly traded electronics testing firm uses workers to break their on-premise and cloud based infrastructure. An innovative start-up is using workers to power an online crypto scavenger hunt. And one of the largest online learning platforms uses workers to deliver their customized content during this time of skyrocketing demand.

Most used cases today have focused on performance. Over time, I expect those use cases will pale in comparison to what is a much bigger opportunity, helping customers manage the challenges of compliance.

In other words, the future of edge computing will be defined as much by intelligent edge storage as it is by computing. And while others are still working to launch their edge computing platforms, we have products like durable objects in market that are defining that future today."

A jab at Fastly, but more importantly a highlight of the product leadership of Cloudflare. They are not focused on performance, as that is maybe the 3rd or 4th most important aspect of edge computing in their eyes. They announced a ton of new stuff this week around privacy and compliance, where it seems like they are driving the innovation. Not only can you compute on the edge with Cloudflare Workers, but you can store your data side-by-side and be assured of regulatory compliance.

I tend to agree with the sentiment that performance will not be the attribute which matters most to many companies and developers. As a software developer myself, ease of development, compliance, and functionality often come ahead of performance. Performance needs to be good enough in most cases, not necessarily best-of-breed.

On Workers, specifically:

“Looking at GitHub and other sources of data on developer engagement, we believe more developers write and deploy real applications and code on Cloudflare workers every month, than every other edge computing platform combined.”

I’m open to being proven wrong when Fastly (finally) releases their product, but right now Cloudflare has a lot of momentum with Workers. Developers are obviously taking a liking to the product.


This is html rendering using simple JavaScript. I don’t think, this example is doing any justice to the power of compute @ edge.

Wrong. All that JavaScript is doing is communicating with the server and rendering the response which is what AJAX also does. The heavy lifting is being done on the edge server edgecompute.app which could be running anything.

You could just have a javascript library and run it on the client (the edge)…

Yes, you could but with IoT devices you want very light clients so let the edge server do the heavy lifting for hundreds of edge clients.

This is getting very off topic for the board so I’ll end here. Thanks.

Denny Schlesinger


Also security. It takes a lot of power to continuously scan, but with compute at edge you can focus in on areas of interest.

Some good news…and an update

Sometime back I had written…

“I’m also not sure where Shopify is right now in it’s journey with using lucet-wasi ( Lucet, FSLY’s native WebAssembly compiler and runtime that was open sourced). It appears that lucet-wasi has to provide more functionality to be really useful (https://bytecodealliance.github.io/lucet/lucet-wasi.html). I know that FSLY has been working quite a lot on making AssemblyScript ( a TypeScript like language that compiles to WebAssembly) . I also know that they’re working on enabling TEL ( Network Error Logging, a W3C spec ) with C@E using Fastly Insights. I ran a quick test and saw that Spotify is using Insights and probably is a C@E beta customer).”

Well there seems to be some nice traction… Some good news from Shopify…

How Shopify Uses WebAssembly Outside of the Browser.

This is from the Shopify engineering blog ( If you’re interested to read it, I’ve provided the link at the bottom)

"Through our research we found that developers in our ecosystem were most familiar with Javascript. Unfortunately, Javascript was precluded as it’s a dynamic language like Ruby. Instead, we chose a language with familiar TypeScript-like syntax called AssemblyScript.

"Architecture of our Code Execution Service

We use an open source tool called Lucet (originally written by Fastly). As a company, Fastly provides a programmable edge cloud platform. They’re trying to bring execution of high-volume, short-lived, and untrusted modules closer to where they’re being requested. This is the same as the problem we’re trying to solve with our Partner code, so it’s a natural fit to be using the same tools.

At first glance, there are a huge number of languages that support a WebAssembly target. Unfortunately, there are two broad categories of WebAssembly compilers which we can’t use…

These are powerful tools in the right conditions, but aren’t built for our use case. We need tools that produce WebAssembly, rather than tools which are powered by WebAssembly. AssemblyScript is one such tool.

We’ve also integrated AssemblyScript into our own early stage tooling. We’ve built integrations into the Shopify CLI which will allow developers to create, test, and deploy modules from their command line."

Link: https://shopify.engineering/shopify-webassembly




Thanks for sharing that update. Am I right in thinking that this is more of a tip of the hat to Fastly and an acknowledgement that Shopify is using their open-source tool than a development that will have an impact on Fastly’s operations or bottom line? Like many here, I can plug in my computer and turn it on pretty easily, but what happens out there on the edge is a little fuzzier for me.




Hi Dorset,

Your understanding is correct ( to some degree). I’m more thrilled about the direction since FSLY is already supporting AssemblyScript in Compute@Edge. And a lot of those are going to run on FSLY’s edge.

And like this Shopify example where this App is outside of the browser, we should be seeing a ton of services taking that approach as we head into the future of apps on the edge.


1 Like

Looks like things may be going on pretty well with Fastly’s Compute@Edge…

Here are some examples from Fastly’s own site how “Content Stitching”, “A/B Testing”, “Health Checks for video and streaming”, “Microservice Migration”, “Waiting Room Tokens for SaaS”, “Security Checks” are all benefiting from Compute@Edge.

Since the text is better formatted at their website, I’m sharing the link for readability:



ronjonb ( @cloudandstocks on twitter)