Tag Archives: node

Dock Life: Using Docker for All The Things!

Interesting take by the folks at nystudio107: instead of installing things such as node locally, why not run it in a container with an alias linked to it?

Instead of installing all of the tools & pack­ages you’re used to using, we use Dock­er images that some­one else has cre­at­ed that con­tain these tools & packages.

In order to seam­less­ly pro­vide access to var­i­ous tools run via Dock­er, we’re going to use shell aliases.

For example, to have node available, set up this alias:

alias node='docker run --rm -it -v `pwd`:/app -w /app node:16-alpine '

With that set up, you can run node script.js as you’d normally do.

Same can be done for other node versions, npm, composer, deno, …

Dock Life: Using Docker for All The Things! →

Cloud Function to generate SVG Sparklines

Zach Leat recently created a cloud function that dynamically generates sparklines. Under the hood sits the the sparkline-svg package to generate the SVG. The datapoints themselves can be passed in via the URL.

Image URLs have the formats:

  • /[height]x[width]/[values]/
  • /[height]x[width]/[values]/[color]/

The code is meant to be deployed as a Netlify Serverless Function.

Every Fire needs a Sparkline →
Sparkline API (GitHub) →

💡 This reminded me of Spark SVG which I covered back in 2013.

It’s an SVG file with a snippet of JS contained inside it, a technique originally developed by Stuart Langridge. On load it will draw the sparkline, using the values as passed in the via the querystring.

<embed src="https://sparksvg.me/line.svg?0,4,7,10,8,12,9,7,3,0" type="image/svg+xml">

Upside with this approach is that you can host this SVG file on your own servers, without needing a cloud function. Downside however is that you need to include the SVGs via <embed> — to allow script execution — and require JS on the client to show them properly.

Fastify, Fast and low overhead web framework, for Node.js

It’s been a while since I’ve set up a server with Node, but turns out Fastify is preferred over Express nowadays.

Fastify is a web framework highly focused on providing the best developer experience with the least overhead and a powerful plugin architecture. It is inspired by Hapi and Express and as far as we know, it is one of the fastest web frameworks in town.

import Fastify from 'fastify';
const fastify = Fastify({ logger: true });

fastify.get('/', async (request, reply) => {
  return { hello: 'world' };
});

const start = async () => {
  try {
    await fastify.listen(3000);
  } catch (err) {
    fastify.log.error(err);
    process.exit(1);
  }
}
start();

Apart from the core there are lots of plugins for authentication, cors, forms, cookies, jwt tokens, etc.

Fastify, Fast and low overhead web framework, for Node.js →

CommonJS to ESM in Node.js

With Node 12 and up supporting ES Modules natively and Node 10 — the last version to not support it unflagged — going EOL, it’s time to start migrating your code to ES Modules. Aral Balkan took the time to convert his tool “Place” to embrace them and documented his work:

Yesterday, I refactored Place, which is a non-trivial Node.js app, to use ECMAScript Modules (ESM). Here’s a diff of the full set of changes.

This is the approach I took and some of the issues I ran into, in case it helps someone else

First step: set "type": "module" in your package.json …

CommonJS to ESM in Node.js →

Related: Also see Sindre Sorhus’ post Get Ready For ESM

10 best practices to containerize Node.js web applications with Docker

Solid list of tips by the folks over at Snyk:

By the time you’re at number 8 your mind may have dwelled, but don’t skip out on that step though! It not only allows you to build smaller images but also prevents you from having unnecessary files (read: security risks) left inside your container. Basically you install your dependencies in one throwaway container, and then copy the resulting folder into your main container.

10 best practices to containerize Node.js web applications with Docker →

Running the same Node.js code on Google Cloud Functions, App Engine, and Cloud Run

Google Cloud has a number of options to run your code. We can deploy a function to Cloud Functions, an app to App Engine, or an app with a custom runtime (a Docker container) to Cloud Run.

In this post the same code snippet is deployed to all three Google Cloud Platform features. Locally the Functions Framework is used .

Portable code migrating across Google Cloud’s serverless platforms →

Optimizing JavaScript packages for tree shaking

Geoffrey Dhuyvetters from madewithlove on how authors of (open source) JavaScript packages can optimize their builds for tree shaking:

How do we create a package that exposes both CommonJS & ES modules while making sure we don’t break cross-platform support? Publishing 2 separate packages is an option (e.g. lodash/lodash-es). But there is a nicer, more maintainable option that obviates the need to publish twice. We can provide an extra build step that creates an ES version of our package and links it via package.json.

The package.json links both builds like so:

{
  …
  "main": "build/cjs/index.js",
  "module": "build/esm/index.js",
  …
}

Didn’t know you could als provide a module field, similar to name … handy!

Optimizing JavaScript packages for tree shaking →

Deno, a new way to JavaScript

Ryan Dahl – inventor of Node.js – has been working on Deno, a new take on Node as if it were designed today.

From async-await to ArrayBuffers, the JavaScript language has changed significantly in the decade since Node.js was designed. Deno takes advantage of these developments and incorporate lessons learned in the development of Node to provide a new JavaScript platform built on V8 and Rust. This talk will teach the audience how to get started with Deno.

I especially like the compatibility with ES Modules.

Slides are also available.

🎧 FYI: The audio gets better after a few minutes. No worries there 😉