The Modern Programmer

In the article Debugging Google Cloud Functions in Node we exposed a first approach of what Google Functions Framework was and how could it be used. The article was mainly focused on debugging Google Cloud Function with HTTP signature, ie, those functions intended to be triggered by an HTTP request. There are however other ways of triggering the execution of a Google Cloud Function, as for instance Cloud Storage , Firestore or, more commonly, by forwarding a Pub/Sub message . This article covers how to debug Google Cloud functions intended to be triggered by a Pub/Sub message. Google Cloud functions with cloud event signature Let's assume we have a function that must be triggered by a Pub/Sub message. To do that, we need to perform two actions: Properly configuring Google Cloud to specify that our function will be triggered by a given kind of Pub/Sub message. This part is described in the official documentation and it's out of the scope of this article...

Linting and formatting tools are common in the Javascript/Typescript (JS/TS) scene, and their benefits are out of discussion: linters allows applying a set of coding style rules, whereas formatters apply a set of not coding but format style rules. Used in a development team scenario, its usage allows unifying the codebase by applying a common set of coding and formatting rules, no matter who the coder was. However, if not properly configured, these tools can collide in their functions, being the most common case the linter formatting code, a task that might be performed by the formatter. This article exposes the way of proceeding in order to allow both tools living in armony. Install and configure a linter The most common linter in the JS/TS scene is ESLint since TSLint , in the moment of writing this article, has been deprecated in favour of the first one. To install ESLint run these commands: $ npm install eslint --save-dev $ npx eslint --init Once installed you c...

In Node, process.env property gives you access to the user environmental variables. Opposite to what you could think, these variables are always treated as strings , no matter the nature of your environment or the way you defined them. Misunderstanding of that said above can give you unpredictible behaviours, as that shown in the next code snippet regarding the usage of a presumably boolean env variable: process.env.FALSY = false; let evaluation = process.env.FALSY ? "This is imposible" : "This is the expected result"; // Since process.env.FALSY is returned as string, // and the bool value of a non empty string is true // it is evaluated not as falsy but as truthy The problem is not just related to boolean values, but also to numeric values, as shown the next code snippet: process.env.ONE = 1; let mustBeSix = process.env.ONE + 5; // Though you could expect mustBeSix being 6 // its result is the string concatenation // of '1' and '5' ie, ...

DISCLAIMER: This article focuses on Google Cloud Functions with HTTP signature, ie, those functions intended to be triggered by an HTTP request. In case of being interested in Cloud Functions being triggered by Cloud Storage, File Storage or Pub/Sub events, read Debugging Google Cloud Functions with event signature in Node . Cloud Functions, the Function as a Service (FaaS) product of Google Cloud, is an attractive resource for those developing solutions in cloud environments. Similar in conception to AWS Lambdas or Azure Functions, they offer serverless processing at an affordable price. From the developer point of view, they don't differ too much of a standard function contained in a program developed in Node, Python, Go or Java, except for debugging: Due to their ubiquitous nature debugging is not easy and most of the times is done following one of these two approaches: Uploading a debug version, running it and then checking its output (logging and/or funct...