Ep. #48, Dynamic Static Sites with Shalom Volchok of Digital Optimization Group

Brian Douglas: Welcome to another installment of JAMstack Radio, on the line I've got Shalom.

Tell the listeners why you're here. What's your background? What is your correlation with the JAMstack?

Shalom Volchok: Getting to the JAMstack was a long journey.

I wrote my first HTML at a course at Rhode Island School of Design in 1997 when I was in high school, and then I actually ended up studying graphic design.

When I graduated I went and joined my family's company, we had an herbal products company and we sold bulk herbs all over the world.

Then we developed this line of direct to consumer retail herbal products and I started advertising those on the internet, this was like 2003, and business exploded.

We grew over the next couple of years, we grew to a million dollar ad spend and business grew 10x.

Brian: Wait, you were in high school making a website?

Shalom: No, after I graduated college.

Brian: OK, I gotcha.

Shalom: This was 2003. So business exploded, and then I managed that for nine years, and that's where I started getting into a/b testing analytics.

We had this big ad spend and it was hard to know, "Should we be spending more? Should we be spending less? What's working on our site? What's not?"

All kinds of landing pages, all kinds of content. Then we sold that company some years ago, it's actually owned by Clorox now, and then I started working on this experimentation platform.

I had read about this research coming out of Microsoft and Google and Facebook and Amazon about a/b testing and canary releasing, and we wanted to do that.

Brian: How long ago was that?

Shalom: This was, when I started reading about that it was 2008, '09, '10 when I was with the company.

We sold the company in 2011, and then this just picked up steam.

Originally I was thinking we would go back into e-commerce and just have a platform that I wish I had before, and then it got more and more about the technology and less about trying to build an e-commerce site.

Then I started working with React in 2015, maybe '14.

React was the entry way into the JAMstack, and the JAMstack was always really appealing because of performance, of course. Performance is critical, especially for online sales, and then also the operational simplicity. This idea that you can just reduce all your dependencies to a single one at build time, and then just throw that into the CDN.

I wanted to use it, but I never really got a chance to because a/b testing was the thing we really wanted to build out.

So there's always this question, "How can we get these amazing architectural decisions of the JAMstack and also be able to a/b test?"

If we go and add one of these third party a/b testing tools, we got to put it in the head and then that blocks rendering because you're waiting for the a/b test results to load before you can show the page so you don't get a flicker, and then basically you've ruined your awesome CDN-deployed static site pre-rendered with this performance.

You take a huge hit there. So last fall, we came across CloudFlare workers and this whole serverless edge, which is now StackPath and fly.io and Fastly is getting into it a little bit differently.

We started experimenting with server-side rendering at the edge, and now we've gotten into building everything that we're doing at the edge.

We're doing React rendered to stream out of CloudFlare workers, and we've also built a headless CMS for a/b testing.

The traditional headless CMS is again, static JSON deployed into the CDN, which is awesome for simplicity and awesome for performance.

But if you want dynamic data, like for a/b testing, then you're back to square one again.

So, server less edge is this first opportunity where now we embed all of our experimental data into a CloudFlare worker along with the API code, and then essentially that gets pushed out to 190 data centers.

Brian: Gotcha.

Shalom: We've essentially-- It's the equivalent of deploying into a CDN, except all of a sudden now the CDN is dynamic.

Brian: Yeah.

Shalom: Then in the case of React, where the JAMstack maybe would do pre-rendering of your pages so you get that great time to first bite, and now we're doing rendered to stream because workers supports streaming as well.

So we can render the head, start rendering the React application, we bundle the whole CMS data in the same worker as the React server-side rendering, so there's no latency for data look up.

Essentially we've cached a dynamic app at the edge, and from a developer's point of view, it's really like having all the great architectural benefits of the JAMstack with you get to be dynamic.

I think about, "What does the term 'Static site' mean?" I think it's becoming like serverless, where obviously there's servers.

Somebody is running their servers, so does "Static site" really mean that nothing can happen on the server?

What if it's like now the edge is that we've gone originless?

From a developer's point of view, I think we could still call it a "Static site," even though the CDN is doing dynamic things.

Brian: So you're basically taking--

Like, when I approached doing server-side rendering in a React app, I would have to reach for something like a now or a Heroku because I need to have a server that triggers that re-render and bundles it down.

So, rather than pointing to your server, you're pointing it to the edge network or the CloudFlare worker? Is that correct? Did I understand that correctly?

Shalom: Yeah, exactly.

Brian: That is amazing. Do you have examples written in blog posts?

Shalom: Yeah, I have a site up. I don't know if I can share anything here, it's just audio right?

Brian: Yeah, I mean after the fact. You could send me the link for sure, I'd love to share that in the show notes.

I mentioned this because I had Kenton Varda, the engineer that instituted CloudFlare workers at CloudFlare.

Shalom: Yeah, right.

Brian: At the time it was super alpha/beta. I could do some trivial things, like replace names on the page, but I would've never thought to even attempt to render my entire string to an actual edge network, which is amazing that you've figured that out.

Going back to your delivering that, how does your a/b test network work on the edge too as well?

Like, I'm going to your site and you have whatever your load balancer for your a/b test network, how is that triggering dynamically?

Shalom: Let's say you're coming to our site and we're a/b testing the headline.

So actually, it is a full headless CMS, so you can a/b test arbitrary schema.

But let's just say you have your headline, your subhead and maybe an image, and you want to a/b test that, so you created three variations in the CMS and now you want to deploy that to your site.

We would actually bundle all three of those variations into the worker with the React app and we would dynamically choose one of those, assign it to a visitor and server-side render that, pass in only these selected variation as data so we can rehydrate on the client, and then essentially the RSDK would hydrate the app pick it up and there would be no network requests for that initial load.

Then when you navigate you would hit the API to load in, again, dynamic variation assignments, and again from a worker.

So you just get back the single variation assigned to the user.

Brian: That sounds pretty elegant. When I approach the JAMstack, I always find these educations that I have to write hacks around.

One thing that you've explained, which is the authentication piece of it, basically an authentication piece.

So I log into a JAMstack site and it stores a cookie in local storage, so that way the next time I come it knows I'm already logged in.

But I always like that first time, especially in React, because in JavaScript you have every variable is assigned undefined right off the bat.

I always get that weird error sometimes, if I'm not handling the data properly I'll get "Undefined"and it breaks the page.

Then I have to refresh and it shows up, and it sounds like you can be a little more elegant when you have things like an edge network and CloudFlare workers to talk to, to do things magically for you. Is that correct?

Shalom: Yeah. "Magically,"I think, is a pretty good word.

You talked about having to pull out Heroku or something if you wanted to do a server-side rendering in the past, and going back to--

I remember when AWS Lambda first came out, I think this was 2015 maybe or something, and we jumped in there early and actually implemented server-side rendering with React.

But then the cold start times were like 1-2 seconds, and we just abandoned it.

Because it was like "OK, yes. It's great. It's scalable, it's serverless,"and all of this. But you're trying to go for something really performant, and so we were running inside of Amazon for a long time building out clusters.

ECS, Docker, this kind of stuff. Now it's like-- Even there, we used to think that if you had a website that was big enough that really wanted to be doing this globally, you could deploy into all of Amazon's data centers and then you could use route 53 to do global DNS and route to your users.

But this is massive operational complexity, you could need easily a full time engineer just to monitor a stack like that, and all of a sudden it's like with this introduction from CloudFlare and the other providers that have this serverless edge, is really like the CDN. You're just throwing it over there. You've eliminated all the runtime dependencies , you've built them into the app, and then I heard from one of the engineers in CloudFlare that they had a client running 100,000 requests per second through a worker.

Which is like, not--

Brian: Is that expensive on the worker side?

I haven't looked at workers since the last time we chatted, maybe a month or two back.

Have they identified a pricing model for this? Like, is this on the same level as Lambda where I'm not paying until I'm a serious product?

Shalom: Yeah. They actually came out with a free tier pretty recently, you can get 100,000 requests per day, maybe, on their free tier.

What we're offering is obviously this high level service, so it's one of the things that we're using.

But if you're just a developer and you want to go use workers and dink around yourself, the pricing is great as a serverless platform.

I think it's probably the most cost effective out there.

Brian: Excellent. When I think of a/b testing I think of places like Optimizely, I think they had a really good a/b testing product back a couple of years ago.

They don't have an edge network, because I always conflate Optimizely and Fastly together, but they are only just blocks away in San Francisco, and I think that's probably usually the problem.

Shalom: Sure. They go into that category, and I hesitate to talk about any specific company. I don't want to--

Brian: Yeah, fair enough.

Shalom: But when I talk about the approach of installing a third party SDK, then there's only so much you can do.

If you're adding a/b testing as a third party SDK, you'd have to block the dom while it renders, and if you're building a modern site I wouldn't want to do a/b testing that way.

I want my a/b testing to be passed down as props to my React components, and I just want it native.

Native in their native server-side rendering, so it's a different thing.

If you're running Magento, or you're running a WordPress site or something, these third party SDKs are great because they offer people an easy way to get started with that.

But if you're really trying to squeeze performance and it matters, like if you have a lot of revenue, you could be losing--

Especially for online advertisers where someone clicks on your ad, if the site doesn't load I'm gone.

So a huge waste could be just never even seeing the landing page.

Brian: Yeah. That's real. It sounds like with the work you're doing, every millisecond counts at this point.

Shalom: Yeah.

Brian: I saw in our note sheet you are using the Preact CLIA too as well. Are you still leveraging Preact for a lot of these projects?

Shalom: We launched a developer preview in July, and we are supporting React right now as our entry thing, because it's got a bigger community around it.

I love Preact, there is a repo that we have up on our GitHub which is an early--

This was last fall, one of the early experiments with CloudFlare workers was with the Preact CLI and wrapping that to get server-side rendering.

There's actually, there's an example of that up and that's a full blown progressive web app with server push.

The other thing we're doing is we embed all the static assets into the worker, so the worker is serving the static assets as well, and CloudFlare has server push so we're doing a server push of the JavaScript assets while rendering to stream the React application.

There's not even an origin, everything is cached. It's perma-cached.

Brian: How do you know when to invalidate the cache and then push it again?

Or are you just waiting until something triggers some interaction on the app itself?

Shalom: Actually in the current iteration we're not doing a progressive web app, so we don't have the service worker on the client caching it.

I think with wanting to do a/b testing, that adds some challenges. I'd really want to--

If a client really had a large budget and really wanted to experiment, like "Can the progressive web app give us more?" Or "We really need off-line support."

I think that could make sense, but I think for a lot of people, especially because the edge is so close that if you don't need the off-line support just hitting the edge server is so close.

With a/b testing, we actually don't have any. There is no cache in validation because there is no caching.

It's essentially that we are in the cache. We are the-- It is the cache, the cache is dynamic, which is pretty crazy.

Brian: Yeah. The way you explain it, it sounds really trippy. I'm just thinking of-- I just saw End Game recently.

When Ant-Man jumps out of whatever that nether region is, that's where you're writing code. Directly there.

Shalom: Directly, yes. We are writing it directly there, yes.

Brian: That's really powerful, and I'm not sure if I-- I don't know if my brain is completely wrapped around this idea.

I know you've sent me some repos to look at, and I skimmed through them trying to understand this concept, but it just makes me want to tinker and try this out myself.

So, you're the Digital Optimization Group?

Shalom: Dot com. That's our website, yeah. In the GitHub repo.

We're on an enterprise CloudFlare plan, which we needed to get on to do this, and we started talking to them in the beginning of the year.

I think it was like a two month courtship, let's say, with all kinds of engineers and CloudFlare just to get the approval that they're excited about this use case and they want to support it.

We got some limits lifted, like how big a script can be that we deploy to give us space to be able to actually embed the application and embed the static assets.

Brian: That's nice. That's hard to get attention of people, and also leverage engineering and support time too as well, but I'm glad you're able to kick the tires and press on some nozzles and stuff like that for this.

Shalom: Yeah, it's been pretty exciting.

Brian: Cool. Anything else you want to share about some of the work you're doing, and maybe other places that we can find some of this content as well?

Shalom: Yeah, I can definitely prepare some stuff for you that you can put up.

There's a couple really interesting-- I'll post these blog posts on CloudFlare of optimization things that they've come out with, one of them is http2 prioritization from a server controlled.

Generally the browser says, "These are the priorities that I want you, server, to give me, my assets. Because I think they're the best."

But with workers you can actually control that and say, "No. We know better, and we want to send down this blocking script because we know you need it, this blocking CSS because we know you need it, and then we're going to send you down images along with the fonts."

Maybe you wouldn't have asked them later because you haven't gotten to that yet, so I think there's a lot of interesting opportunities going forward for us to build in these performance optimizations into our platform, or even for people who just are developers using workers directly.

Another one is a progressive jpegs. Progressive jpegs, the way they're optimized is they've ordered the bytes so that the first 15% of the bytes as they come into the browser can give a blurry version of it.

Then the details come in later, but 50% of the image, I usually can pretty well see what it is.

If you have multiple images on the page they're going to generally load one at a time, so even though an individual image is loaded progressively, the other images are still waiting.

One of the things that CloudFlare is working on with workers is to do multiplexed progressive jpegs, so you can actually load in parallel if you have a number of images.

The first 15 % of these six images and then the further ones.

We're pretty excited about the future of performance and dynamic performance and what we can build in to just get developers out of a box. They just write React code and then deploy, and they don't have to worry about configuring any of that or dealing with the learning curve, which I think is a big part of the appeal of the whole static sites and JAMstack, is that you build it and then it's taken care of in an awesome way for you.

Brian: Yeah, that is the beauty.

I have a lot of ideas and I have a lot of projects I have to ship just randomly, side projects or sites that have to stand up for events, and being able just to know how to coordinate your UI and not worry about the whole deployment process or interaction with servers and anything like that, that makes my life a lot easier.

Because I don't want to have to maintain some side project or some one-time initiative that I had to ship, because I find a lot of my projects happen to be in that realm.

Shalom: Sure.

Brian: So I imagine marketing companies that have some of the campaigns going, if they could have it as "Set it and forget it."

The site I always go back to is SpaceJam.com, it looks exactly like the way it did back in 1996 when you were first making herbal remedy sites for your family.

That same site is the same site today. That's my goal. Even if the design looks off maybe 10 years from now, at least the site still works, and that's pretty much where I want to be.

Shalom: Right, yeah. That's a nice goal. In the last few years we've experienced change like never before, and hopefully it's settling down.

I think the edge-- I think it's going to settle on the edge for a while, because it just feels like it's the natural progression, and the whole JAMstack really pushed that forward.

Taking advantage of the CDN, and now with these dynamic CDNs being able to have dynamic static sites and offers, like "Have your cake and eat it too," for developers.

Brian: Yeah. Speaking of cake, I'm going to transition us to picks if you don't mind. These are jam picks, things that keep us going.

It can be movie related, tech related. I know you went pretty deep on the tech stuff, but if you still got them, keep them coming. If you don't mind, I'll go first.

My first pick-- Speaking of learning curves, I have a couple of projects that have been around since 2016-2017 in React.

I have no problem upgrading my React versions, so React 16.9 is the latest version, but I think 16.8 is when they went full force on React hooks as far as the API.

Or maybe it was before that, but I recently started using hooks and the way in for me to--

Because I haven't been paying attention specifically in the React community for the past basically nine months, so I didn't really follow along.

I figured "The React community will figure out the hook thing, and then I'll come when everybody figures it out and has training courses."

Shalom: Sure.

Brian: So my pick is actually Tyler McGinniss's React Hooks Course. I skimmed through that over the weekend and then switched over to hooks.

I don't want to say it was that easy, but I think he gave me a good platform for me to understand how to switch to fully functional components, because I was using lifecycle methods and pretty much all my--

Anything that needed some state transitions, switching those to the use effect hook was mostly straightforward, but actually works because my app itself was pretty approachable and simple.

So I appreciated that course, check out Tyler McGinniss's React Hooks Course, and then I also wanted to mention there's another podcast that's out there, which is my second pick.

Which is called That's My JAM podcast. I just want to give a shout out to them because they're making podcasts on the JAMstack, so if you haven't heard of it listeners or Shalom, you should check it out.

Shalom: Sure.

Brian: I think they are only a couple of episodes in, so best of luck to that podcast. I'll keep listening. Do you have any picks?

Shalom: We have on our repo-- Which also people can access, it's open source.

It's an early version of a proxy that we built on top of CloudFlare workers, and that actually allows you to route your traffic to any back end, anywhere, globally.

You could run a/b tests between Azure, AWS and Google Cloud and you could run if you had infrastructure on those.

Or if you wanted to migrate from one service provider or one cloud provider to another, I think that's another really nice thing that the edge opens up, is to be able to put your proxy outside of the cloud providers and be able to say "I own my domain and I should be able to point it wherever I want in any way that I want."

People can check that out if they want.

Brian: Yeah, I just gave you gave you a star just now. I will definitely be checking this out.

Shalom: All right, cool.

Brian: Any other picks?

Shalom: Here's something I think you-- We can talk about anything, right? You said food, or hobbies, or anything?

Brian: Yeah.

Shalom: So this is super random, but I'll throw it out there because I've talked about code too much.

I've been dancing Argentine tango for 20 years, so that's a hobby of mine that is a total polar opposite from sitting in front of a computer and programming, that keeps me sane.

It's a random fun thing to do.

Brian: Yeah, we need those. Out of all things, Argentine tango?

Shalom: Yeah. Tango.

Brian: What's the difference between Argentine tango and like, "Tango" tango?

Shalom: Argentine tango comes out of Argentina, but it developed there really independently of anything else.

Then the "Tango" tango is more of a ballroom version that goes with foxtrot or waltz and these kind of things, where they have a few steps and it's just a package.

It's really a package thing, and the Argentine tango started in the 30s and 40s in Argentina. It was a huge cultural thing.

A whole generation was dancing and creating music at that time.

Brian: Nice. When you get famous from this CloudFlare worker stuff and they do celebrity developer dancing competitions, you'll be the first one they call.

Shalom: Yeah. All right.

Brian: Excellent. Shalom, thanks a bunch for coming through and talking about all these really cool things you're doing with dynamic static sites.

Best of luck with continuing this combination with the CloudFlare workers, and listeners, check out the repos and keep spreading that jam.