-- Leo's gemini proxy
-- Connecting to capsule.adrianhesketh.com:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
As I mentioned (//2017/07/27/serverless-web-apps-without-client-side-javascript) I'm using the Serverless Framework (serverless.com) to build a new product using Node.js.
I'm fairly new to node, but there was a feature I was really missing, and that's async/await which I think makes Node.js much less cluttered with boilerplate syntax than using callbacks or promises.
When I first tried to use it I got a syntax error. _Of course!_ I should have noticed that the version of Node.js that AWS Lambda currently supports (6.10.3) doesn't include async/await.
Surely there's an easy way to get async/await to work with Serverless?
Callbacks came first, then Promises (in their various guises) then finally async/await. It looks like quite a bit of a mess to anyone who's coming fresh to Node.js, but on the other hand, I've been using a similar feature in C# since 2012, and it's not really any different to the situation there - delegates / event handlers for handling events in the early days (callbacks), then later lambda expressions and `Task` were added (promises), then the language got async / await on top to make the code clearer.
Since there's 3 ways of achieving the same objective, Node.js libraries use all of the different mechanisms depending on how old they are.
I must have missed the official promises developments entirely, since there were a number of various ways of doing it floating about. Fortunately there's a really good interactive guide at [0] which explains how the different systems work and why they're important. This was really helpful for me.
This blog was also handy to guide me in how I could convert code I'd written which used callbacks to using promises. [1]
Once I had my code using Promises, I wanted to step up to async/await to simplify more. Since I can't update Node.js on AWS, I'd need to update my code somehow.
From doing a bit of React.js, I knew that modern javascript code needs to be "transpiled" (i.e. modified / converted) to run on anything but the very latest Web browsers and that Babel [2] is often used to do this.
So, I knew I needed to get Babel to convert my modern javascript to javascript suitable to run on an older Node.js runtime.
I didn't find Babel's documentation particularly helpful, and a lot of the suggestions on Stackoverflow etc. are out-of-date with current best practice, but thanks to a few issues and questions on Stackoverflow, I worked out what I needed to do:
- Install Babel into my project (`npm install --save-dev babel-cli` and `npm install --save-dev babel-preset-env`)
- Add a `.babelrc` file to tell Babel what rules to apply (in my case, compile to the version of node that the current environment is using - which I've also set to be the same version that AWS Lambda uses)
- You've got to be careful here. If the Node.js version on the machine that's transpiling the code is newer than the target version, then Babel won't do the correct operations.
- Update the `packages.json` to add scripts in to:
- Run the Babel executable against my Node.js code
- Ignore the node_modules folder so that it doesn't attempt to transpile everything.
- Ignore the output folder.
- Run tests against the newly transpiled output.
- Update the Serverless.yml to use the transpiled output (under the /lib directory) which is compatible with the AWS Node.js version.
Once I had support for it, I needed to refactor my code. Here's an example of the process I used to migrate some code I wrote to read from Google's Geolocation API and parse the output into a Location class.
module.exports.postcodes = (apiKey, postCode, callback) => {
const url = `https://maps.googleapis.com/maps/api/geocode/json?address=${escape(stripWhitespace(postCode))}&key=${escape(apiKey)}`;
console.log(`postcode: ${url}`);
fetch(url)
.then(response => response.json())
.then((s) => {
console.log(`postcode: retrieved data: ${JSON.stringify(s)}`);
const rv = new Location(s.results[0].geometry.location.lat,
s.results[0].geometry.location.lng);
callback(null, rv);
})
.catch((error) => {
console.log(`postcode: error: ${error}`);
callback(error, null);
});
};
module.exports.postcodes = (apiKey, postCode) => new Promise((resolve, reject) => {
const url = `https://maps.googleapis.com/maps/api/geocode/json?address=${escape(stripWhitespace(postCode))}&key=${escape(apiKey)}`;
console.log(`postcode: ${url}`);
fetch(url)
.then(response => response.json())
.then((s) => {
console.log(`postcode: retrieved data: ${JSON.stringify(s)}`);
resolve(createLocationFromGoogleResponse(s));
})
.catch((error) => {
console.log(`postcode: error: ${error}`);
reject(error);
});
});
module.exports.postcodes = async (apiKey, postCode) => {
const url = `https://maps.googleapis.com/maps/api/geocode/json?address=${escape(stripWhitespace(postCode))}&key=${escape(apiKey)}`;
console.log(`postcode: ${url}`);
const response = await fetch(url);
const locationData = await response.json();
console.log(`postcode: retrieved data: ${JSON.stringify(locationData)}`);
return createLocationFromGoogleResponse(locationData);
};
function exampleCallback(a, b, callback) {
callback(null, a+b);
}
function examplePromise(a, b) {
return new Promise((resolve, reject) => resolve(a + b));
}
exampleCallback(1, 2, function(err, result) {
console.log(result);
});
// Doesn't work at all. Callbacks and promises are not backwards compatible.
examplePromise(3, 4, function(err, result) {
console.log(result);
});
// Promises are handled with then and catch.
examplePromise(5, 6)
.then(results => console.log(results))
.catch(err => console.log(err));
// But it's possible to await the promise instead inside an async function.
// console.log(await examplePrommise(7, 8));
The usage example shows that it's important to note that the API surface changes when migrating from callbacks to Promises, so calling code _will_ be needed for that, just not from when migrating to async / await.
I think it's worth the effort of back-porting async/await to AWS Lambda to make code much easier to read, despite the added complication of a build step.
- https://javascript.info/callbacks
- https://benmccormick.org/2015/12/30/es6-patterns-converting-callbacks-to-promises/
- https://github.com/babel/babel/issues/5532
- https://stackoverflow.com/questions/35748116/babel-ignore-several-directories?noredirect=1&lq=1
- https://stackoverflow.com/questions/10753288/how-to-specify-test-directory-for-mocha
- https://stackoverflow.com/questions/33527653/babel-6-regeneratorruntime-is-not-defined
- https://github.com/babel/babel-preset-env
-- Response ended
-- Page fetched on Sun Apr 28 09:20:25 2024