DEV Community: David Porter

My misadventure with Cloudflare Workers and Vue Serverless Side Rendering

David Porter — Tue, 29 Dec 2020 14:18:08 +0000

In which I talk about my attempt at Vue Serverless Side rendering with Cloudflare Workers

Just in case the lynch mob arrives I will preface this post by saying that I like the Cloudflare Workers Site concept. This post simply highlights that performing Serverless Side Rendering (SSR) with Cloudfare Workers is still quite challenging.

Tell me about Cloudflare Workers

You can think of these like service workers that execute at in the cloud. Cloudflare have hundreds of edge locations around the world and the location nearest to your user will handle that particular request. It's very similar to AWS Lambda@Edge. Not satisfied with that explanation? Here is a very good explanation

What we're trying to achieve

Previously I'd written a post on Vue SSR with Lambda@Edge

Vue Serverless Side Rendering with AWS Lambda@Edge

David Porter ・ Jul 18 '20

#vue #lambda #serverless #ssr

There it was suggested I try with Cloudflare Workers. It was actually very easy to setup a Workers Site with very little config and zero modification to my Vue App. That was very pleasing.

For those looking to give it a go, if you have lots of assets then consider using Backblaze to store your many images.

Hurdle 1 - V8 Engine

So the problem here is that with traditional Vue SSR, it's expected to be executed in a Node.js environment. Cloudflare Workers run directly on V8, the engine that runs Chrome and Node.js among others.

Since Vue 2.5 a simple SSR module is shipped as well which is mostly environment agnostic so you can do SSR with PHP or Python for example. In essence, this renderer simply renders our Vue app to a string. So we lose the cool features like template interpolation and injection that come with the standard Renderer and BundleRenderer.

Thankfully, in response to the challenge below a kind soul (or souls) modified the basic renderer to bring these features back in. // Detect dark theme var iframe = document.getElementById('tweet-1185301603366178817-52'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1185301603366178817&theme=dark" }

Hurdle 2 - App size

Cloudflare Workers are designed to be light and very fast, so Worker scripts are limited to 1 MB compressed size. If your site is a simple one then hey, no worries. If you're running a fully armed and operational battle station which exceeds that limit then like me you're out of luck.

There are probably a few ways to get around this like slimming down our application or storing the bundled app outside of the worker (like in KV or Backblaze) and downloading it at runtime. The first is something we should do anyway, but who has the time! The second won't work due to the next hurdle

Hurdle 3 - Execution Time

A common feature of SSR is fetching data on the server(less) side instead of on the client. This can also be an SSR killer if the fetch operation is slow, but let's stick with wanting to do our API fetching on the server side now.

Worker scripts are also capped to at most 50 ms execution time. This doesn't leave much room for latency on even a simple request let alone a more complex (ie one that requires more time to respond).

So looking back at Hurdle 2 if we were to try to pull in our bundled app from KV, then parse it, then render the app HTML we're probably pushing it on the execution time and that's without any data fetching that may occur within the app.

Verdict

The setup is easier than CloudFront and much more friendly than Lambda@Edge. However, like my review of Svelte/Sapper (hey! Two self promos in the one post!) I think Cloudflare Worker sites are cool but just not quite there for Vue SSR.

Svelte/Sapper vs Vue

David Porter ・ Sep 1 '20

#svelte #sapper #vue #ssr

SSR may not be everything, but it's the great for things like SEO and other applications crawling/scraping your site (eg Facebook crawlers don't wait for client side JS unlike Googlebot).

How to build a tiny Flask Docker image for Cloud Run

David Porter — Sat, 26 Dec 2020 14:51:07 +0000

Hey I know what Cloud Run is, just get to the point!

I'd like to know what Cloud Run is

Cloud Run is a fully managed product within the Google Cloud (GCP) suite which allows you to deploy containerized serverless applications.

Is it like AWS Lambda?

Well... sort of. AWS Lambda is a fully managed platform for deploying serverless applications. However with AWS Lambda you only need to write the code. The GCP equivalent to Lambda is Cloud Functions. The AWS equivalent to Cloud Run would be Fargate.

Why don't I just use AWS Fargate?

The standard way to run a Fargate application is to have at least 1 instance running. As traffic increases the Auto Scaling Group will increase the number of instances to handle the load. If you have an application with lots of traffic and can afford to have an EC2 instance running 24/7 then sure go for it!

If you'd like to deploy a containerized application with the ability to scale to zero (and so only pay for what you sue) then read on my friend because Cloud Run is for you.

Erm OK, so why don't I just use AWS Lambda

Hey no arguments here. But there are some cool benefits.

Concurrency

Where Lambda will spin up a new instance per request, a single Cloud Run instance can service more than request. When the traffic is too much for that instance a second instance is spun up and so on. In the simple example of 2 users sending requests at almost the same time, with Lambda both users experience cold start (waiting for the instances to load up) whereas in Cloud Run only one container will initialize and so the first user still has to wait for the instance to boot up, but the second user enjoys the already warm instance.

Developer Freedom

Being a container you can write it in any language with any libraries or even your own binaries.

Lambda does allow custom run-times but if that's not enough then a Docker container is what you need.

Note During reInvent 2020 AWS announced the ability to deploy your own containers to Lambda. So I guess it's just concurrency?

That was confusing, what is Cloud Run?

It's a platform that allows you to deploy serverless containerized applications where you only get billed while your application is responding to requests.

Dockerfile

Here is an example Dockerfile to build your Flask application.

Those with a keen eye will note this is a multi stage build. This allows us to install everything required to build the app in one container and then copy over the built application into another container and then only deploy precisely what is required to run the app which gives huge savings on size.

The next thing to note is that the second stage uses a Distroless python image as the base image. This is a super lean image which contains the barest of bare essentials to run our Flask application.

Application Code

Ok, so let's look at a sample app. Here is our app.py, a simple Flask app.

Wait a minute, the Dockerfile makes no mention of an app.py but rather a wsgi.py.

Waitress

If you've used Flask before hopefully you know not to use the built-in development server that comes built in. Why not you say? Because in plain terms, it only services one request at a time, killing our whole selling point of concurrency.

Enter Waitress: a production quality WSGI server. The benefit of waitress over other WSGI servers (eg NGINX) is that Waitress is written purely in python so we don't need to install any additional libraries onto our image. This means we can keep it nice and small (Yay!) and serve requests concurrently (Woo!)

Here's an example wsgi.py file

How to deploy?

Google have plenty of documentation on this so I'm not going rehash all of that.

Why bother do all this?

The python slim Docker image comes to around 60MB compressed, but with Distroless you can get this down to 20MB. That might seem a bit "who cares" but let's look at it from another angle.

On the front end developers have been scrimping and saving on file sizes for years with uglifying and compression so that pages load faster for the end user. It's all about that Time To First Paint. Here every KB counts and all sorts of DNS pre-fetching and pre-loading goes on to get the content to the user as quickly as possible.

Serverless applications are still a relatively new paradigm. Classically (and still currently) a website will be serviced by a dedicated server, meaning that boot times aren't an issue because the server ideally boots once and then runs forever.

However in the serverless world, when a request comes in a new service is provisioned and the application image is downloaded onto it and then booted up. So now size matters, and our Distroless app should boot up 3 times faster than the slim app! Then obviously the next area to look at is application start up time, but that's beyond the scope of this article.

Summary

Multi stage builds, Distroless and Waitress are your friends here.

Svelte/Sapper vs Vue

David Porter — Tue, 01 Sep 2020 15:14:06 +0000

In which I highlight the gap between Sapper and Vue

So I wrote a lovely article with examples comparing Vue and friends to Svelte and Sapper. But twice the draft refused to save and so I gave up. The main point to get across is that .vue components are far more readable than .svelte components. However on every count Svelte requires less code as is their mantra (and it's a good one). But there is one thing where Sapper doesn't quite measure up.

SSR and State Management

While on the surface Server Side Rendering (SSR) is much easier in Sapper, there is one thing isn't quite there. How do we pass the server state back to the client. First let's look at Vue

Vue SSR & Vuex

Vuex helps us manage state centrally in our Vue apps. If you follow the guide the Vuex store is setup as a singleton. It looks something like this.

import Vuex from 'vuex'

const store = new Vuex.Store({
  ...
})
export default store

This is fine on the client, we'll only ever have one store. However when we run SSR we need to service many clients and requests and we can't mixup the store across those requests, so now it needs to look like this.

import Vuex from 'vuex'

export default function createStore(){
 return new Vuex.Store({
  ...
  })
}

Now you can initialise many stores for your many requests. The same principle applies to the Vue app itself as well as Vue Router and Apollo. A quick example of that is as follows.

import Vue from 'vue'
import createStore from './store'

export default createApp(){

  const store = createStore()

  const app = new Vue({
    store
  })

  return { app }
}

in entry-client.js

import createApp from './app'

const { app } = createApp()

app.mount("#app")

On the server once our app has processed the route, mutated the state and rendered the HTML we need to pass the Vuex state to the client before it hydrates, otherwise it will hydrate from a fresh store and now your app will be out of step with your store (which is bad). This is pretty straightforward and you can read about it here. In short the store state is dumped inside <script> tags in the server rendered HTML and when Vue is initialised on the client it slurps it up and updates the client state to match.

Sapper

If you have no idea what Sapper is, it's the equivalent of Nuxt but for Svelte. The creator, Rich Harris, has a nice article introducing Sapper.

Back to SSR, it's not quite the same in Sapper. We don't have the same concept of a Vue class that we can initialise and then feed it things like routers, stores and Apollo clients. In Svelte we have the concept of stores, but as singletons.

When the stores are written to on the server they hang around between requests. This is bad news, not only can you send a user incorrect data, you could send someone else's data (Yikes!). So the best approach would be to not mutate the stores on the server.

But we like having a store on the client and we want the state from the server to come down. Sapper has a couple of approaches towards achieving this.

Session Data

On the server Sapper uses sessions for your user data which you can use to set data on the server and then pass down to the client.

Preload

In the preload function we can fetch data server side before rendering. So in a component you can write something like this

<script context="module">
  export async function preload(page, session) {
     let animal = "dog";
   return { animal }
  }
</script>

<script>
  export let animal;
</script>

<p>
  { animal }
</p>

Then it's up to you on the client side to synchronise the store yourself in the onMount hook. Note that onMount is never called on the server so you can be confident that it is only running on the client.

The preload function however is comparable to asyncData from Nuxt.js and can run on both server AND the client. You can get around this by using the process.browser variable and only executing your server logic inside an if block, but this is cumbersome.

Apollo Client

A big feature of Apollo is caching. In Vue, if we fetch some data server side with Apollo, we can pass down the Apollo state as we did with the Vuex state. Like the above, you've got to handle the heavy lifting yourself and there is no recommended/documented way of doing it and some of things you enjoy (or at least I enjoy) in Vue SSR you just won't be able to achieve with Sapper. While it's not critical, without it you're missing out on an advantage of Apollo.

Summary

Should we all run off and learn Svelte to keep ourselves employed?

The above state management and singleton problem aside... No, if you can do React or Vue then you're still good. If you can't do either of those I would strongly recommend learning one if you want a job as a front end developer. We are in for interesting times however as Svelte production bundles are much much smaller than Vue which means your Time To Interactive (TTI) is also going to be much smaller with Svelte.

Vue + Relay + Server Side Rendering (SSR)

David Porter — Tue, 04 Aug 2020 02:43:12 +0000

In which I describe how to achieve Server Side Rendering with vue-relay

GraphQL is a pretty swish alternative to REST. That's not to say it's better or worse, but in certain situations it's pretty handy. Relay is a JavaScript framework designed for hooking up React applications with a GraphQL API. GraphQL + React + Relay are the foundations of the current Facebook application. All three are open-sourced, developed by Facebook and designed for Facebook. This means that whilst they are strongly supported and maintained they are primarily geared towards Facebook's needs and concerns.

Why not use Apollo?

Well, my recommendation would be to use Apollo. It's flexible, easy to get started and most pertinent to this article, it's SSR ready. There is a nice article at How To GraphQL which explains the difference between Apollo, React and urql.

In summary Relay is very rigid and demands strict protocols to be followed. This is handy for Facebook so that amongst all their developers Relay is used consistently across the board. For developers starting out it can be a steep learning curve and for small applications is probably not worth the hassle. It also requires a strong coupling between the API and the client. That's not such a bad thing, but quite a departure from REST.

Pushing on with vue-relay

So for whatever reason, we're sticking with Relay and we're going to use vue-relay.

Assumptions

Architecture

Although a front-end framework Relay demands that your GraphQL server implements a few things. You can read about these here. In short you must:

Implement the Node interface
Implement a refetch mechanism based on the global ID
Implement a connection model for slicing and paginating through queries that return lists

Note that you don't need to do these from scratch. Whichever language (Node.js, Python, Go, etc) you have used to implement your GraphQL server with, it's highly likely that implementations exist for supporting relay.

Server Side Rendering (SSR)

This guide assumes that you've got SSR in place, but you can't seem to hook it up with relay. If you don't already have SSR implemented then checkout out the Vue SSR Guide.

If you don't have a server then I've written a post on how to do it with AWS Lambda@Edge.

Vue Serverless Side Rendering with AWS Lambda@Edge

David Porter ・ Jul 18 '20 ・ 9 min read

#vue #lambda #serverless #ssr

QueryRenderer

I also assume that you know how to use vue-relay. If you don't, first give the docs a read. Also read and re-read the Relay docs. Relay is so rigid that every last detail counts.

GraphQL schema

Not SSR specific, but worth a mention. When working with relay you need to compile your queries first with relay-compiler. Another reason why I would recommend Apollo, but it does help you fix up any mistakes in your schema and queries and if you're like me you make loads.

In order to run the compiler you need the API schema in a schema.graphl file accessible from your client side code. If your schema is defined in code, then you'll need to export the compiled schema. As an alternative the smart cookies at Prisma have developed a tool to introspect your GraphQL API and spit out the schema for you. Very convenient.

Prefetching

A good starting place is fetching the data. I'm going to use serverPrefetch which is available in components for Vue versions 2.6.0+. I recommend you do too, because implementing it yourself is cumbersome, but not impossible.

relay-runtime provides a fetchQuery method for manually querying your GraphQL API. fetchQuery requires the same things that the QueryRenderer requires. An environment, a query and some variables. So it would look something like this.

import { fetchQuery } from 'vue-relay'
...
serverPrefetch(){
  return fetchQuery(this.environment, this.rootQuery, this.variables)
}

Environment

If you've followed the Relay Guide to setting up the Environment, then I'm going to make a few tweaks. We're going to define the Relay Environment within Vuex store.

Stepping through the important parts we've set up the initial state like so

state: () => ({
    environment: null,
    cache: new QueryResponseCache({ size: 250, ttl: 60*1000 })
})

We start with environment set to null and setup the cache using the QueryResponseCache constructor provided by relay-runtime. It will become clear why soon.

Next we define an init action. This will setup the environment using the cache. We will use Environment from relay-runtime which looks like this.

const environment = new Environment({
  network,
  store
})

for the network part we supply a network layer using Network.create() again from relay-runtime. The things to note here are that instead of defining the cache in the global scope we reference the cache that we defined in the Vuex state.

const cache = state.cache;

The cache is important because we are going to populate it with the result from our GraphQL API. Then when hydration occurs on the client the QueryRenderer will retrieve the results from the cache.

Next, you'll notice that unlike the Relay documentation I have opted to use axios over fetch. This is because axios works on both the client and the server. You could use fetch if you used something like node-fetch on the server.

Then at the end we update the environment in our state

commit("setItem", {key: "environment", value: environment})

QueryRenderer

Now we need to update the props we pass to the QueryRenderer. Here is what it should look like in your template block.

<query-renderer :environment="environment" :query="rootQuery"
                    :variables="variables" v-slot="{ props, error}">

The environment props needs to come from Vuex store so we add a computed property

computed: {
  environment(){ return this.$store.state.environment }
}

entry-server.js

Here is our entry point to our app for SSR.

Of note here is

await store.dispatch("init")

Here we are calling the init action we defined just above to set up our Relay Environment.

context.rendered = () => {
  const responses = {}
  store.state.cache._responses.forEach( (value, key) => {
    responses[key] = value
  })
  store.state.cache._responses = responses
  context.state = store.state
};

Another reason to go for Apollo here. The QueryResponseCache that powers our cache is a Map. When we render the page we also need to pass the state of the application through. The state is simply serialized with JSON.stringify. But you can't serialize a Map. Fortunately for the cache key we use the query and variables as a string. So we can convert this Map to an Object, update the store.state and set the context.state.

entry-client.js

Finally we're going to tie it all together in the hydration step. On the entry point of our application, if we're hydrating a rendered page we need to update our Vuex store to match. Normally this is straight-forward but recall that we just butchered the cache in order to serialize it. Now we need to convert it back to a Map.

If there is a window.__INITIAL_STATE__ we do the following to convert the _responses Object back to a Map.

const responses = new Map()
// We initialize the store state with the data injected from the server
if (window.__INITIAL_STATE__.cache && window.__INITIAL_STATE__.cache._responses){
  for (const [key, value] of Object.entries( window.__INITIAL_STATE__.cache._responses)) {
      responses.set(key, value)
  }
}

Then we override the Vuex state, initialize the cache and update the cache._responses with the Map we just created.

store.replaceState(window.__INITIAL_STATE__)
store.commit("setItem", {key: "cache", value: new QueryResponseCache({ size: 250, ttl: 60*1000 }) })
store.commit("setCacheResponses", responses)

Then finally call the init action to set up the Relay Environment.

As this is a simplified application, if yours is more complex you need to ensure that the init action doesn't undo the work of SSR by resetting anything that was set with store.replaceState. You can do this by specifying this in a separate action and dispatching on the client only for example.

Summary

Unless you're working at Facebook, use Apollo.

Head Management in Vue Apps

David Porter — Sat, 25 Jul 2020 12:49:47 +0000

In which I go over your options for managing the <head> section in Vue applications

If you've just polished off your first Single Page App (SPA) with Vue, you may have a missed a detail. All your pages have the same title; the title defined in index.html. If you don't have this problem then well done to you! If you do have this problem and you want to know what you can do then read on.

Why do I need to worry about it?

For the client

Not a huge deal, but without head management all of your pages will have the same title, so no matter what page your user is on, the browser tab will read the same.

For the web crawler

Oops, this is a big deal. Having the same title, meta, structured data will be the same for all pages and this will impact your Search Engine Optimisation (SEO). I'm not an SEO expert so I won't dwell too much on why, but at the very least your Google search results will all look the same if your <head> section is identical for all pages. At the worst Google may treat all your pages as duplicates and only list your home page.

How do I do it?

Before we launch straight into it I'm going to assume you've got some Server Side Rendering (SSR) in place. If you don't then checkout out the Vue SSR Guide.

If you don't have a server then I've written a post on how to do it with AWS Lambda@Edge.

Vue Serverless Side Rendering with AWS Lambda@Edge

David Porter ・ Jul 18 '20 ・ 9 min read

#vue #lambda #serverless #ssr

It's important to have SSR in place otherwise search engines and other web crawlers will not see your efforts. They will only see index.html.

Target Output

Here's what we're hoping our SSR rendered application looks when we're done.

<!DOCTYPE html>
<html lang="en">
<head>
    <title>Parent Title</title>

    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <meta name="keywords" content="vue head management">
    <meta name="description" content="Description set by Parent">

    <script type="application/ld+json">
        {
        "@context": "http://schema.org",
        "@type": "WebSite",
        "name": "Parent Title",
        "description": "Description set by Parent"
        }
    </script>

    <link rel="preload" href="/static/js/main.3e60a259.js" as="script">
</head>

<body>
  <div data-server-rendered="true">
    <h2>Parent</h2> 
  </div>
  <script src="/static/js/main.3e60a259.js" defer></script>
</body>
</html>

1. Mixins

If you've gone through Vue SSR guide then you've probably had a crack at this method or at least seen it.

First build the mixin.

Now use the mixin in a component. First import the mixin as standard. In the created/mounted hooks these mixins will look for a title and/or meta key. You can either pass a string or a function.

Finally in our SSR html template we have access to our title string and meta object and we can reference these inside mustache tags. If you need to use the raw output use a triple mustache -> {{{ }}}

Advantages

We have full control of our head management

Drawbacks

Lots of code to get it going

2. Vue-Meta

Part of the Nuxt.js framework. If you don't know what Nuxt.js is here is the summary. Named after Next.js for React, Nuxt is a complete framework based on Vue, which includes routing, state management, SSR and more. Nuxt handles all the heavy lifting so you can rapidly develop fully featured web applications.

Enough about Nuxt. Vue-Meta is a quick and easy-to-use library for head management. Let's see it in action.

First include it in your application

import VueMeta from 'vue-meta'

Vue.use(VueMeta)

Here's an example of how you include it in your components.

Note the vmid, this is important if you have child components that may overwrite the meta information. If you don't use the same vmid it will write duplicate tags in the output html (which is bad), so make sure you have matching vmids for the same meta name. The same goes for script tags with application/json+ld types which house structured data.

Now to include this in our SSR we need to make a little change to our entry-server.js file and add the vue-meta results to the context.

And in index.html it now looks like this:

Much nicer! OK, {{{ meta.inject().title.text() }}} is a bit of a mouthful but now we don't have to write and manage our own mixins.

3. Vue Helmet

A nod to React here, React Helmet is a head management library for React via reusable components. Vue Helmet is inspired by the React version and there are a couple of implementations floating around. In this example I'm using the @jnields/vue-helmet implementation which supports SSR.

In our components we use it like this:

Note this:

<helmet-provider :context="context">

We need to pass the application context as a prop to HelmetProvider and so we need to modify main.js a little to pass the context through.

And finally in index.html

Easier than the mixin option, but in my opinion not as nice as the Vue Meta option. I find it nicer to work with Objects than with components.

One issue I did find is that if you define a <script type="application/ld+json"> tag in a parent component and then try it overwrite it in a child component it will generate two script tags. I haven't tested how Google feels about this, but results are likely to be unreliable. If you recall I stressed the importance of setting the vmid in your Vue Meta objects. Unfortunately we don't have that option here, but perhaps one of us should submit a PR for it.

Anyway there you have it. Make your own mind up but I recommend using Vue Meta. If you want to get your hands dirty then go for the mixin option.

Vue Serverless Side Rendering with AWS Lambda@Edge

David Porter — Sat, 18 Jul 2020 13:21:05 +0000

Note, while this post refers to Vue SPAs, the concept is the same for React apps

divporter / ssr-lambda-edge

Serverless Side Rendering with Lambda@Edge

Single Page Apps (SPAs) are great. I'm a big fan. You can offload all that HTML generation to the client, and SPAs make up the 'J' and 'M' in JAM stack. An important distinction in sites built with JAM stack is that the SPA is served by a CDN and not a traditional web server. The client and server should be completely uncoupled.

In AWS world you simply upload your SPA to S3 and serve it with CloudFront. But what do we do about SEO? Well, when GoogleBot crawls the page it will run any synchronous JavaScript (within a time limit) and then crawl the resulting page. Note the synchronous there which means GoogleBot won't see any data that is fetched when a regular client loads the page.

Enter Server Side Rendering (SSR). For the unfamiliar, here's a quick summary. When a user makes a page request instead of serving an empty index.html and main.js the server looks at the route, fetches any required data and then renders the HTML from your SPA according to the SPA routing (eg Vue Router) and then serves up nicely rendered HTML. So now when GoogleBot sees your page all of your dynamic content is there.

Oh but wait... we don't have a server. So we turn to Lambda. Before that, let's look at our options.

SSR everything

One option is to do SSR for all page requests that CloudFront receives. A problem there is that SSR isn't fast and when there's data fetching involved it's only as fast as the API it's pulling from. So instead of loading your index.html page quickly and showing your users a nice loading screen. They just see a blank page for a few seconds. We can easily implement caching so that the first unlucky user has to wait a few seconds and then every subsequent user gets it lightning fast from the CDN.

SSR for SEO only

This is the option I will focus on. So a "regular" user gets your index.html with the standard SPA client side rendering. GoogleBot on the other hand is treated to a server(less) side rendered html page with all of our dynamic content. Likewise we can implement caching so we don't have to waste Lambda resources rendering the same page over and over.

Architecture Decisions

There are a couple of ways to do SSR for SEO only. Using run of the mill Lambda or using Lambda@Edge.

Lambda

In this model, a Lambda is configured as a CloudFront origin and handles any path that is not an api route, static route, or has an extension other than .html

The Lambda determines whether the user is a web crawler using es6-crawler-detect for example. If it is a bot, then proceed with SSR. If it's not a bot then we'll need to serve up index.html

This is pretty straightforward, but to handle requests for things such as favicon.ico or manifest.json which typically live at the root level we need to either make sure we configure the cache behaviors to serve them from S3, or serve them from our Lambda (which is a little trickier).

Lambda@Edge

Here we leverage the power of Lambda@Edge. Lambda@Edge is a special type of Lambda in that unlike "regular" Lambda functions which run at the data centre of your specified region Lambda@Edge runs at the CloudFront edge location where the request is made. In principle it should be faster because it's closer to your user.

In this scenario we are going to tell CloudFront whether or not look in the S3 bucket in response to the request, based on the request path and the User-Agent header. So firstly if the path is pointing to a file (eg manifest.json) then we tell CloudFront to get it from our S3 origin. If it's a request to a page (eg example.com/page) then we need to see if it's a bot or not. If it is a bot then we perform SSR and return rendered HTML. If it's not a bot, then serve up index.html from our S3 origin. In comparison to the Lambda model, this lambda doesn't serve up things like manifest.json, it only does SSR.

Lambda@Edge implementation

OK I hear you. Enough is enough, I've set the scene. Show me some code I can use. Let's start with the Lambda@Edge handler.

WARNING: the response object is very very delicate. For another example refer to the AWS docs

So what is happening? Let's say a request has been made to https://example.com/page and CloudFront has been configured to look in our S3 bucket to fulfil this request. Now let's consider two User-Agent scenarios

Scenario 1. User-Agent is GoogleBot

Looking at the if statement



if ((!path.extname(request.uri) && !request.uri.startsWith('/api')) || (request.uri === '/index.html'))

This will evaluate to (true && true) || false which is true.
Then the next one is obviously true



if (CrawlerDetector.isCrawler(userAgent))

So we're going to be doing some SSR.



if (request.uri === '/index.html')

This line exists so that Vue router in our SPA treats index.html as the '/' route. Although not true in this case, it's worth pointing out.

Alright now to do some SSR.



const ssrResponse = await new Promise((resolve, reject) => {
  const renderer = createBundleRenderer(serverBundle, {
    runInNewContext: false, // recommended
    template,
    clientManifest
  })

  renderer.renderToString({}, (err, html) => {
    if (err) throw err
    let minified = minify(html, {
      caseSensitive: true,
      collapseWhitespace: true,
      preserveLineBreaks: true,
      removeAttributeQuotes: true,
      removeComments: true
    })
    const response = {
      status: '200',
      statusDescription: 'OK',
      headers: {
        'content-type': [{
          key: 'Content-Type',
          value: 'text/html; charset=utf-8'
        }],
        'content-encoding': [{
          key: 'Content-Encoding',
          value: 'gzip'
        }]
      },
      body: zlib.gzipSync(minified).toString('base64'),
      bodyEncoding: 'base64'
    }
    resolve(response)

  }, reject)
})

The first part is standard SSR according to the Vue.js SSR Guide. For more information check it out, it's pretty cool. Skipping over that, let's get down to the response object, it has to be exactly right or CloudFront will error out. It's important to compress the HTML returned in the response body because we've got to limit the generated response to 1 MB. Check out the CloudFront Quotas for more information. If your compressed response is over 1 MB then we can handle this another way which I'll cover later.

Getting back to it, now that the SSR has rendered the HTML and we've generated the response object, now we simply return it.
CloudFront will then cache the response against the url https://example.com/page + User-Agent. So next time GoogleBot comes along it will serve the SSR rendered HTML straight from the cache. Noice!

Scenario 2. User-Agent is Mozilla/5.0 etc etc

Now a real user is coming to look at https://example.com/page. Although the request url is the same, the User-Agent is different so CloudFront won't serve from the cache. It will make a request to the origin where our Lambda@Edge will intercept it. Looking at the logic.



if ((!path.extname(request.uri) && !request.uri.startsWith('/api')) || (request.uri === '/index.html'))

This is true again.



if (CrawlerDetector.isCrawler(userAgent))

This is false however as we are not crawlers. So nothing left to do but proceed with the request untouched. This means it will continue with its original intentions and look in S3 for the page. As this is an SPA there is no /page folder so it will send back a 404. Typically when hosting SPAs on CloudFront you convert 404s to 200s and serve up index.html and so for this request the user gets the standard index.html and the HTML rendering and data fetching occurs on the client side as we intended.

Scenario 3. Request is for manifest.json

As this file has an extension it fails the first hurdle and we continue with the request and the file is retrieved from S3 happily.

Serverless Implementation

That's great, but how do I set up all this up in CloudFront? This section makes an assumption that you have the following good to go:

An S3 bucket with your static website files
An API (optional)

Oof! Alright, I'll point out some the key lines in the serverless.yml. First up, in the function definition we have a lambdaAtEdge key. While serverless.com now supports Lambda@Edge as a function event, the @silvermine/serverless-plugin-cloudfront-lambda-edge plugin has been around much longer and as such I've been using it long before Serverless rolled out native support for Lambda@Edge functions. And to be honest despite my efforts I couldn't get the CloudFront event to work with multiple origins. So vive le Silvermine plugin. Anyhoo, this plugin connects the Lambda@Edge function to our CloudFront distribution.

Which is a great segue to... our CloudFront distribution which we define in the resources section. Skipping ahead to CacheBehaviours which is a list of paths and instructions for how CloudFront should handle them. Note these are applied in the order that they're defined. First up is the /api path. This allows our API to be called under the same CloudFront domain as our front end. If you don't have an API or you don't need/want it living under the same domain then you can delete this block. Last up is the * path which points to our S3 bucket. Note this section:



ForwardedValues:
  Headers:
    - 'User-Agent'

This tells CloudFront to forward the User-Agent and use it as part of the cache key. If we miss this, then we can't determine if we're dealing with users or bots.

Then in the Origins section is where we give CloudFront the details of our API (delete if not required) and our S3 bucket (required).

Finally the last thing of note is the custom error response.



CustomErrorResponses:
  - ErrorCode: 403
    ResponseCode: 200
    ResponsePagePath: /index.html
    ErrorCachingMinTTL: 5

This is standard SPA configuration stuff so that when we request paths like https://example.com/page which aren't actual files (because we've built an SPA), it will serve up index.html and Vue Router will handle the internal routing.

So that's it, easy-peasy! OK, it's actually very fiddly and delicate, with lots of moving parts, but when you get it working it's magical.

Now to tidy up some loose ends.

Can I SSR everything with Lambda@Edge?

In this article I focused on only doing SSR if the User-Agent is a web crawler. However, if you want to use Lambda@Edge for all page requests then simply remove the es6-crawler-detect parts and now all requests will be handled by Lambda@Edge. It would be a good idea to reduce the MaxTTL and DefaultTTL in the CacheBehaviours for the '*' PathPattern so the data on the dynamic pages is not potentially 2 days old. This is no big deal for crawlers, but for users it's a good idea to give nice fresh data.

My SSR rendered HTML is over 1 MB even after compression

No problemo. First you simply need to create a Lambda with API Gateway proxy and put the SSR code in it. Next add it as an origin in your CloudFront distribution with a path like /ssr. Note that your newly created lambda needs to have a matching stage so that it responds to request at /ssr (eg abcde12345.execute-api.ap-southeast-2.amazonaws.com/api). Then in your Lambda@Edge function, when you want to do SSR, instead of generating the HTML in the @edge function you change the origin to the lambda you just created. Instead or generating a response you modify the request like so.



const ssrDomainName = 'abcde12345.execute-api.ap-southeast-2.amazonaws.com'
      if (request.uri === '/index.html'){
        request.uri = '/'
      }
      request.origin = {
        custom: {
          customHeaders: {},
          domainName: ssrDomainName,
          keepaliveTimeout: 5,
          path: '/ssr',
          port: 443,
          protocol: 'https',
          readTimeout: 30,
          sslProtocols: ['TLSv1', 'SSLv3']
        }
      }
      request.headers['host'] = [{ key: 'host', value: ssrDomainName}];

Just like the response object, the request object is equally fragile so be careful. In the solution in this article we returned the response, this time we return the request instead, which will then divert the request to our SSR Lambda instead of the S3 Bucket.

Deploying a Flask App to AWS Lambda

David Porter — Fri, 10 Jul 2020 17:56:25 +0000

In which I compare deploying Flask Apps to AWS Lambda with Zappa and Serverless Framework

divporter / flask-lambda

Deploying a Flask App to AWS Lambda

One of the first programming languages I learned was Python. The first version (v0) of my hobby site VeganFeeds however was written in PHP with an Apache server connected to a PostgreSQL database serving up dynamically rendered HTML. In the second version, confusingly named v1, I moved from the traditional LAMP stack (or LAPP in my case) to the JAM stack. Being familiar with Python, I decided that Flask would be the 'A' in my JAM stack.

After having built the Flask app, instead of continuing with a traditional web server I decided to give the serverless approach a try. Now that I've finished my trip down memory lane, let's skip ahead to deploying a Flask app to AWS Lambda.

While SAM CLI can deploy Python Lambdas, you can't deploy a Flask app straight out of the box. Although you can with a little help from flask-serverless. I have not used it personally so I won't review it here.

Zappa

Given an existing Flask app, Zappa is the easiest way to get your Flask app up there. And when I first discovered Zappa I knew next to nothing about the AWS ecosystem and so it was a friendly resource to enable me to get my Flask app out into the wild.

It is as simple as:



$ pip install zappa
$ zappa init
$ zappa deploy

Unfortunately though it's never that easy. The above assumes that you have installed your dependencies in a virtual environment within the project directory. So if you haven't done that you will get an error like below:



Error: Zappa requires an active virtual environment!

So let's remedy that by setting up a virtual environment and installing our dependencies into it.



$ python3 -m venv venv
$ source venv/bin/activate
$ pip install zappa flask

OK, so now we're ready to deploy. If we run zappa deploy again we now face a new error.



Error: This application is already deployed - did you mean to call update?

As featured as Zappa is, I find having separate commands for an initial deploy and updating an existing deployments annoying. Anyway, let's do it. Let's call zappa update. And hooray it works.



Your updated Zappa deployment is live!: https://051zc5ynck.execute-api.ap-southeast-2.amazonaws.com/dev

Let's have a look in the browser.

Yep! Looks good.

Chances are though, if you're building an app beyond "hello world" you may end up adding a dependency that works fine on your development OS but is incompatible in the Lambda environment. Then you're going to need to mimic the Lambda environment when installing your dependencies with docker using the very handy Lambda Docker images built by the lambci team. So you could do something like:



$ pip freeze > requirements.txt
$ docker run -ti -v $(pwd):/var/task  --rm lambci/lambda:build-python3.6 bash -c "python3 -m venv zappa_venv && source zappa_venv/bin/activate && pip install -r requirements.txt"

Now the dependencies are built in the correct environment and when you run zappa deploy your Lambda should now work again. But that's a great big ugly command. Sure you use a Dockerfile, but if you're unfamiliar with Docker then that's going to make things harder.

Serverless Framework

Now despite all that Zappa bashing it was around when there was little else and really stretched the capabilities of CloudFormation and did a lot of heavy lifting behind the scenes before native support was rolled out as standard. It also comes with a lot of handy features such as the keep_warm feature to get around the cold start issue.

The Serverless Framework is a more generic tool. Not only covering languages other than Python, such as Node.js and Ruby, but also other Function-as-a-Service (FaaS) providers such as Google Cloud and Microsoft Azure.

Installation-wise the Serverless Framework is not as friendly to set up the first time as Zappa. Obviously aside from a Python installation you will also need Node.js installed as a prerequisite.

Assuming you have node next is to install serverless via npm which ships with Node.js



$ npm install -g serverless

The -g flag means it is now available globally and you need not install it again for future projects. OK, so now what?



$ serverless create --template aws-python3

OK cool, so we have a few files now. handler.py,.gitignore and serverless.yml Focusing on handler.py, this file reveals the bare bones of a Python Lambda handler. So how do we squeeze our Flask app into this? Well we're actually not going to use it at all. We're going to use a plugin. The Serverless community is very active with a slew of plugins to keep things nice and simple. The serverless-wsgi plugin like Zappa is designed for deploying Python WSGI apps to Lambda and abstracting away the handler protocols. You'll notice at the bottom of the link that the plugin draws inspiration from Zappa. To add the plugin you'll need to run



$ sls plugin install -n serverless-wsgi

Note that sls is a handy alias for serverless.
Next we need to add a few lines to the bottom of our serverless.yml file.



custom:
  wsgi:
    app: app.app

Next we need to modify our serverless.yml in the functions section so that it looks like this



functions:
  hello:
    handler: handler.hello
  api:
    handler: wsgi_handler.handler
    events:
      - http: ANY /
      - http: ANY {proxy+}

Unlike Zappa there is no dependency on running a virtual environment, however serverless-wsgi relies on the virtualenv module. In case you don't have it installed simply run



$ pip install virtualenv

followed by



$ sls deploy

With any luck the output will now show the url for our newly created api

And if we open in a browser...

It works great. Now what if we want to add a second exclamation and say 'Hello, World!!'. Unlike Zappa we can just run sls deploy again. The deploy command handles both creation and updates. Lovely!

OK, but what about my dependencies that I need docker for? Well thankfully there's a plugin for that. serverless-python-requirements will do the Docker/lambci stuff for you. It does other nifty stuff too, like zipping them up to reduce their size or even throwing them in a layer for you!

What about Chalice?

Chalice is the offical AWS tool for deploying Python Lambdas. It has a similar syntax to Flask (and other Python WSGI frameworks), so for Flask users it will feel comfortable. But unlike Zappa or Serverless you can't use Chalice to deploy an existing Flask app. You must refactor it first.

Chalice is not as configurable as Zappa and Serverless, so you will not get to enjoy all the features of a Flask App along with the flexibility of Zappa or Serverless. For starting a simple project Chalice will help you get up and running quickly. Then if you find it doesn't meet your needs then you can look to Zappa and Serverless.