DEV Community: Jasper Moelker

Svelte Kit, the first ‘serverless-first’ framework?

Jasper Moelker — Wed, 03 Feb 2021 17:04:50 +0000

"The whole serverless thing is a pretty good trend, and Svelte is now a serverless-first framework"

That quote is from Rich Harris, creator of Svelte. A bold statement, but is the newly introduced Svelte Kit really “serverless-first”? And what does that even mean? And if so, how well can this new Svelte seamlessly integrate with serverless platforms like Netlify and Vercel?

Big fat disclaimer: Svelte Kit is in early development. The source code isn't public yet. To get a sneak peek I installed the "next" version (@1.0.0-next.0) of Svelte and its new serverless adapters:

npm init svelte@next
npm install -D @sveltejs/adapter-node
npm install -D @sveltejs/adapter-static
npm install -D @sveltejs/adapter-netlify
npm install -D @sveltejs/adapter-vercel

My findings are based on sifting through the compiled code with the help of Sokra's source code visualiser.

Serverless-first using adapters

Svelte’s answer to become serverless-first in a fragmented landscape of serverless platforms is its introduction of so-called serverless adapters. While all serverless providers like Netlify and Vercel offer similar functionality — static hosting, cloud functions and configurable redirects — they each have their own vendor-specific implementation.
To ensure Svelte runs seamlessly on all of them, Svelte will provide an adapter for each. Each adapter does three things:

copy Svelte’s compiled client-side JS bundles and other static files to the serverless hosting directory.
copy Svelte’s server-side JS bundles and a platform specific render function to the serverless functions directory.
create the redirects configuration with a catch-all route to the serverless render function.

The adapter takes platform specific configuration (files) into account. Here’s the gist taken from the Svelte adapter for Netlify (@1.0.0-next.0):

// get netlify configuration, defined by user in netlify.toml:
const netlify_config = toml.parse(fs.readFileSync('netlify.toml', 'utf-8'));
const publish = path.resolve(netlify_config.build.publish);
const functions = path.resolve(netlify_config.build.functions);

// copy static and client files files to static hosting directory:
builder.copy_static_files(publish);
builder.copy_client_files(publish);

// copy the renderer and server files to cloud functions directory:
fs.copyFileSync(path.resolve(__dirname, 'files/render.js'), `${functions}/render/index.js`);
builder.copy_server_files(`${functions}/render`);

// create _redirects file with catch all route to serverless render function:
fs.writeFileSync(`${publish}/_redirects`, '/* /.netlify/functions/render 200');

While I believe adapters are the way forward towards true serverless integration of JavaScript frameworks, I don’t think Svelte is truly serverless-first yet. Here’s why:

Serverless-first requires server logic

Part of the fun of serverless rendering over static site generation is being able to respond dynamically to incoming requests. For instance if a request has query parameters or a payload, you'd want to use that request data in your Svelte app. As far as I can tell the adapters and Svelte app don't expose this data to the routes yet. Here’s the serverless renderfunction from the Netlify adapter (@1.0.0-next.0):

exports.handler = async (event) => {
  const { path, httpMethod, headers, queryStringParameters
    // body, // TODO pass this to renderer
    // isBase64Encoded // TODO is this useful?
  } = event;
  const query = new url.URLSearchParams();
  // [...] code to append queryStringParameters to query object

  const rendered = await app.render({
    method: httpMethod, headers, path, query, host: null // TODO
  });

  if (rendered) {
    return {
      isBase64Encoded: false,
      statusCode: rendered.status,
      headers: rendered.headers,
      body: rendered.body
    };
  }
  return { statusCode: 404, body: 'Not found' };
};

Judging by the TODO comments, this is clearly a work-in-progress. Svelte already passes some request parameters to the Svelte app render function. But as you can see it doesn’t pass the payload body and host yet. For meaningful serverless apps, Svelte will need to pass these as well as the missing second argument of this lambda handler (async (event, context)) and also pass these onto the routes. In addition Svelte will need to normalise the parameters (and context?) best it can between the different serverless providers for a unified developer experience.

Once Svelte exposes the request and context, developers will want to handle these in their app. A good reference of what this could look like is the recently added [getServerSideProps](https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering) in Next.js. Here’s an example of server-side only logic leveraging the request context:

// example of server-side only logic in a Next.js route:
const { verify, decode } = require('jws')

export async function getServerSideProps(context) {
  const token = context.req.headers.auth

  if (!token || !verify(token, 'HS256', JWT_SECRET)) {
    return {
      redirect: { statusCode: 401, destination: '/login/' }
    }
  }

  const { userId } = decode(token).payload.app_metadata
  const user = await fetchUser({ userId })

  return {
    // will be passed to the page component as props
    props: { user },
  }
}

export default function Page({ user }) {
  // render page with user data
}

Sapper - the Svelte version of Next.js - has preload which is somewhat similar, but runs both on server- and client-side; and doesn’t expose as much of the context. Whatever it will look like, the new Svelte will need to introduce some way for developers to add their own server-side logic to really be serverless-first.

Serverless-first in development mode

Serverless providers including Netlify and Vercel worked hard to offer tooling to make local development as close to production as possible. Both netlify dev and vercel dev offer full support for serverless functions. But while Svelte Kit offers adapters for these serverless providers, they come in the shape of a post-build step:

npm run build   # svelte-kit build
npm run adapt   # svelte-kit adapt

This feels like an afterthought rather than a serverless-first approach. And this means I can’t test my serverless Svelte app in development, but always need to create a (production) build.
Svelte could achieve serverless-first in development mode by creating the redirects configuration during svelte-kit dev, connecting the serverless render function to unoptimised server bundles and putting the local server of the selected serverless provider in front of Svelte’s own local server. This way, I can also add my own non-Svelte serverless functions to the project and run them in the same development setup. Svelte already made the client-side development experience instant by adopting Snowpack, now it’s time to do the same for serverless development.

A serverless-first future

Seeing as Svelte Kit is in early stages and the Svelte team has already proven they can make a serverless framework with Sapper, I’m optimistic the next Svelte will be truly serverless-first. I hope the serverless functions will be extendible and work in development mode in a future version of Svelte.

Dropbox Paper as a headless CMS

Jasper Moelker — Wed, 30 Jan 2019 12:47:00 +0000

We turned Dropbox Paper into a headless CMS and use it to publish our content elsewhere.

note: originally posted on Voorhoede.nl, so you could read it there too :)

Why? Dropbox Paper is great for editing. We can write in markdown, add rich media, organise documents in folders, content is automatically versioned and others can give feedback in comments. This makes Paper a perfect CMS candidate for document collections like our company playbook. However the Paper UI isn’t ideal for reading, browsing and navigating and a folder with documents doesn’t feel like it’s our playbook. So this is what we came up with:

Organise and edit content on Dropbox Paper

We start our project content-first. Through the familiar Dropbox Paper UI (paper.dropbox.com) we write our content in Paper documents and organise them in folders:

From the URL of our root folder (https://paper.dropbox.com/folder/show/Playbook-e.1g...Mxe), we extract its DIRECTORY_ID (in our case e.1g...Mxe), so we can access it programmatically through the API.

Gather content through the Paper API

We use the Dropbox Paper API to retrieve the folders, documents and their metadata:

We start by listing all documents and getting all folders within our project root folder, filtering by our DIRECTORY_ID.
We then get the meta data of each document to filter out “deleted” documents and gather useful meta data like “date last updated”.
Finally we download the contents of each document as markdown.

We write the data from the API into a folder structure, with a markdown file for each document containing the content plus the meta data as Front Matter (data in YAML format in between triple dashed lines) at the top. For example a document written to playbook/voorhoede-events/meetups.md would look like:

---
doc_id: "rzWK0vA059CSQcQdmKydy"
last_updated_date: "2019-01-08T15:24:33Z"
---

# Meetups

We love sharing our learnings and experiences with others ...

The full source of the Paper API integration is on GitHub.

Build and deploy as a static site

With our content from Dropbox Paper written to our filesystem we can do with it whatever we like. Markdown files with Front Matter are a popular input format for static site generators. We’re already using VuePress, so we’re using this to publish our documents as a static site. The code of our project, including the VuePress setup and Paper API integration, are on GitHub. We’re using Netlify to build and deploy a new version of our site on every code change. And this is the result:

You can view a simplified live demo version of our Playbook.

/publish from Slack

While our site is automatically updated on code changes, it doesn’t update on content changes. 😕 Unfortunately Paper has no means to notify us programmatically when content changes. This means we can’t automatically trigger a new publication. So as developers, we came up with something else close to home: a custom ‘slash command’ to trigger a publication directly from Slack using /playbook:

And that’s it, we’re using Paper as a CMS with a mechanism to publish our content in a custom site, with the look-and-feel we want.

Paper API limitations and drawbacks

During our development we ran into a few limitations of the Paper API:

The Paper API only returns documents opened at least once by the account the API token belongs to.
Paper’s RPC API is very hard to use compared to all the friendly REST and GraphQL APIs out there today.
The Paper API returns documents in a “last accessed/modified/created” order which isn’t very useful to us.
Paper has no webhooks or other mechanism to trigger a new publication on document changes.
Paper has no “team token” to use for authentication. We ended up creating a Dropbox user (~€300/year) just to have a Playbook token.

Our verdict

Dropbox Paper is very suitable as a headless CMS for document collections. It has great authoring tools. As long as you can work with its limitations, you should keep it in mind for the next time you need a quick CMS.

Useful links:

Project source code
Dropbox Paper and the Dropbox Paper API
Static Site Generators and the JAM Stack