CORS and request parsing in functions is a cloud infrastructure platform that’s a layer over some of Amazon Web Services, simplifying the development of web apps. “Serverless on easy mode!” Developing on means writing cloud functions (i.e. AWS Lambda) that turn into HTTP endpoints, and can access DynamoDB storage.

I used it for the first time a few days ago, to build a quick-and-dirty API for an experimental wiki project. I managed to read and write content (arrays of strings) in the storage. Getting it to work involved a few obstacles, described below… with fixes :) founder Ryan replied on Twitter and showed me some helpful stuff, so I’ll update the relevant sections of this post with better solutions.


Cross-origin resource sharing is when browsers load information from various servers. Security features in modern browsers let servers control when this is allowed to happen. This sometimes causes annoying obstructions during development, when working with multiple local servers. (I was serving my frontend and my local begin endpoints on two different ports.)

My API worked in Postman, but in Chrome I got this complaint

I found a post from the blog about enabling a cors boolean:

But that didn’t work.

What worked was adding this to the response header:

Update: That blog post is outdated. But the cors boolean can be made to work. You need to use wrap the handler function with a helper, instead of exporting it directly.

2. Request parsing is built on the Architect serverless app framework. This provides some helper functions, including one for translating base64 encoded JSON strings into JS objects. In apps, all request body data comes in this format.

The docs suggest that body, here, should be a JavaScript object. But I ended up with stuff like: eyJ0aXRsZSI6Indpa2kiLCJwYWdlIjpbInN0ZWFtIiwid2F0ZXIiLCJpY2UiLCJlbGVwaGFuIl19

What worked: using standard Node and JS functionality.

(btoa is the standard function for converting binary to ascii in browsers, not in NodeJS.)

Update: the bodyParser works fine as long as the request comes with the right content-type. Here’s the fetch call I was using:

The no-cors option breaks it. It sends the wrong content-type and makes the response ‘opaque’ (i.e. useless). So, don’t use no-cors.

The CORS error situation again rears its ugly head.

Without ‘no-cors’, the request was being sent properly, but failed. I got errors with something called the CORS preflight request. This is sent before with the OPTIONS call, to check the features the endpoint says it supports. doesn’t let you set OPTIONS handlers for arbitrary paths. And luckily, we don’t need to. The solution is to listen for calls on the root path (‘/’) — the GET handler will greedily consume OPTIONS calls too. See here. Solution I implemented here. That response tells browsers that it’ll allow:

  • any origin (so you can make that more restricted/specific if you want)
  • any method from “GET, POST, OPTIONS”
  • whatever header(s) came with the request

This isn’t set by default in the CRUD starter todo app. It’ll probably be something I include as boilerplate for everything I make. I like open APIs and powerful frontends. But security considerations for certain use-cases would make other options more appropriate.

Despite these issues, seems nice to work with, and suitable for several of my project ideas.

Ideas including:

  • Wikis (particularly, something compatible with Federated Wiki)
  • News river
  • Dating site

systems humanist / web dev

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store