DEV Community: Julián Duque

Interested in IoT dev? Want early access to the Arduino Explore IoT kit? Tell us more...

Julián Duque — Thu, 13 Aug 2020 19:04:30 +0000

Hello DEV Community! 👋

Heroku is partnering with Arduino and CascadiaJS to deliver an IoT workshop next month during the CascadiaJS Plugged In conference, and we are giving away 6 free tickets 🎟 and the opportunity to have access to one of the upcoming Explore IoT Kit from Arduino (a new product from Arduino, yet to be released!).

The ticket includes:

CascadiaJS Conference attendance
A spot in the IoT Development Workshop facilitated by Arduino and Heroku
An Explore IoT Kit from Arduino (not yet released!)

If you want to participate, here is what you need to do:

👉 Reply to this post as a comment with a creative idea and tell us: What would you build using the Explore IoT Kit from Arduino and Heroku? 👈
Make sure you include your Twitter handle (if any)
Confirm you will attend the conference and share a write up with the community

The top 6 ideas with most votes (Hearts 💜) will be selected! 🎉

You can submit your ideas between August 13th and August 21st, 2020, the top 6 ideas will be chosen on August 25th, 2020, and selected participants will be announced here and on @Heroku and @CascadiaJS twitter accounts.

If you are selected, we would love to see your idea come to reality! We want you to share with the community what you built and how you built it!

Update: Both conference and workshop are going to be remote, more information about the workshop can be found in the CascadiaJS 2020 website, the IoT Workshop will be hosted on September 2nd, 2020.

Update 2: Thank you very much for your submissions, definitely a lot of great ideas to implement!

The time has come and we have selected the attendees for the IoT Workshop at CascadiaJS with Heroku and Arduino.

Congratulations to:

Matías Blayer
Ricardo Trejos
Diana Rodriguez (Super Diana)
Javier Pedrosa
Chris Bongers (DailyDevTips)
Manuel Benitez (manwey)

Thank you very much for your participation!

Let's Debug a Node.js Application

Julián Duque — Mon, 03 Aug 2020 16:08:55 +0000

There are always challenges when it comes to debugging applications. Node.js' asynchronous workflows add an extra layer of complexity to this arduous process. Although there have been some updates made to the V8 engine in order to easily access asynchronous stack traces, most of the time, we just get errors on the main thread of our applications, which makes debugging a little bit difficult. As well, when our Node.js applications crash, we usually need to rely on some complicated CLI tooling to analyze the core dumps.

In this article, we'll take a look at some easier ways to debug your Node.js applications.

Logging

Of course, no developer toolkit is complete without logging. We tend to place console.log statements all over our code in local development, but this is not a really scalable strategy in production. You would likely need to do some filtering and cleanup, or implement a consistent logging strategy, in order to identify important information from genuine errors.

Instead, to implement a proper log-oriented debugging strategy, use a logging tool like Pino or Winston. These will allow you to set log levels (INFO, WARN, ERROR), allowing you to print verbose log messages locally and only severe ones for production. You can also stream these logs to aggregators, or other endpoints, like LogStash, Papertrail, or even Slack.

Working with Node Inspect and Chrome DevTools

Logging can only take us so far in understanding why an application is not working the way we would expect. For sophisticated debugging sessions, we will want to use breakpoints to inspect how our code behaves at the moment it is being executed.

To do this, we can use Node Inspect. Node Inspect is a debugging tool which comes with Node.js. It's actually just an implementation of Chrome DevTools for your program, letting you add breakpoints, control step-by-step execution, view variables, and follow the call stack.

There are a couple of ways to launch Node Inspect, but the easiest is perhaps to just call your Node.js application with the --inspect-brk flag:

$ node --inspect-brk $your_script_name

After launching your program, head to the chrome://inspect URL in your Chrome browser to get to the Chrome DevTools. With Chrome DevTools, you have all of the capabilities you'd normally expect when debugging JavaScript in the browser. One of the nicer tools is the ability to inspect memory. You can take heap snapshots and profile memory usage to understand how memory is being allocated, and potentially, plug any memory leaks.

Using a supported IDE

Rather than launching your program in a certain way, many modern IDEs also support debugging Node applications. In addition to having many of the features found in Chrome DevTools, they bring their own features, such as creating logpoints and allowing you to create multiple debugging profiles. Check out the Node.js' guide on inspector clients for more information on these IDEs.

Using NDB

Another option is to install ndb, a standalone debugger for Node.js. It makes use of the same DevTools that are available in the browser, just as an isolated, local debugger. It also has some extra features that aren't available in DevTools. It supports edit-in-place, which means you can make changes to your code and have the updated logic supported directly by the debugger platform. This is very useful for doing quick iterations.

Post-Mortem Debugging

Suppose your application crashes due to a catastrophic error, like a memory access error. These may be rare, but they do happen, particularly if your app relies on native code.

To investigate these sorts of issues, you can use llnode. When your program crashes, llnode can be used to inspect JavaScript stack frames and objects by mapping them to objects on the C/C++ side. In order to use it, you first need a core dump of your program. To do this, you will need to use process.abort instead of process.exit to shut down processes in your code. When you use process.abort, the Node process generates a core dump file on exit.

To better understand what llnode can provide, here is a video which demonstrates some of its capabilities.

Useful Node Modules

Aside from all of the above, there are also a few third-party packages that we can recommend for further debugging.

debug

The first of these is called, simply enough, debug. With debug, you can assign a specific namespace to your log messages, based on a function name or an entire module. You can then selectively choose which messages are printed to the console via a specific environment variable.

For example, here's a Node.js server which is logging several messages from the entire application and middleware stack, like sequelize, express:application, and express:router:

If we set the DEBUG environment variable to express:router and start the same program, only the messages tagged as express:router are shown:

By filtering messages in this way, we can hone in on how a single segment of the application is behaving, without needing to drastically change the logging of the code.

trace and clarify

Two more modules that go together are trace and clarify.

trace augments your asynchronous stack traces by providing much more detailed information on the async methods that are being called, a roadmap which Node.js does not provide by default. clarify helps by removing all of the information from stack traces which are specific to Node.js internals. This allows you to concentrate on the function calls that are just specific to your application.

Neither of these modules are recommended for running in production! You should only enable them when debugging issues in your local development environment.

Find out more

If you'd like to follow along with how to use these debugging tools in practice, here is a video recording which provides more detail. It includes some live demos of how to narrow in on problems in your code. Or, if you have any other questions, you can find me on Twitter @julian_duque!

Deploying Node.js microservices to ZEIT Now

Julián Duque — Thu, 04 Apr 2019 21:08:55 +0000

ZEIT Now is a cloud platform to deploy serverless applications, one of the things I like the most about Now is their DX (Developer Experience), it makes it very pleasant to deploy microservices to the cloud.

In this article we are going to learn how to install Now and start deploying with one single command, now.

Prerequisites

Node.js 10 LTS Installed
A terminal
Code editor of your choice
A ZEIT Now account, you can signup for free here

Installation

First, let's install now CLI from npm by running the following command:

$ npm install -g now

Login

Next, we need to identify ourselves in the platform, now CLI offers an easy way to do this by running:

$ now login

This will ask for your email and will send you a Verification email, just by clicking on Verify will log you in the platform, it's like magic 🔮!

Verifying email

Successful login from Terminal

Create your first Microservice

We are ready to start creating our first microservice (or serverless application, you name it).

Now provides a list of examples, for our exercise we are going to use Node.js ⬢, but hey!, Now supports other languages and platforms too, just give it a try with the one you like the most 😉

To start witht he Node.js template let's run the following command:

$ now init nodejs microservice

This will create a folder called microservice with the Node.js template.

Now is time to deploy our example to the cloud, let's go to that folder and execute now to see what happens!

$ cd microservice
$ now

Deploying to Now and running our microservice

Before continuing with our next trick, let's explore the files we are deploying:

`index.js`

It contains a simple function with the request and response objects from Node.js, this will be executed on every request made to our microservice.

module.exports = (req, res) => {
  res.end(`Hello from Node.js on Now 2.0!`);
};

index.js

`now.json`

It's the deployment configuration file, used to specify the name of our project, the type of builders we are going to use, routes, etc. More information can be found in their documentation.

{
    "version": 2,
    "name": "nodejs",
    "builds": [
        { "src": "*.js", "use": "@now/node" }
    ]
}

now.json

Monorepo

What we have seen so far seems simple, but, here comes the real power of now, we can mix and match different microservices in a monorepo to create a full serverless project.

For our next trick, we will create a Nuxt.js static application that will be doing API requests to a Node.js microservice, both are going to be deployed to now using the monorepo approach.

Let's create a monorepo folder and then run create-nuxt-app, this will create a basic Nuxt.js application for you, just make sure to select Axios support in the features section, we will use it later 😉.

$ mkdir monorepo
$ cd monorepo
$ npx create-nuxt-app www

create-nuxt-app

We have our frontend application almost ready, we will need to add an API to our monorepo project, let's create an api folder and add a Node.js microservice in there (no need to create the now.json, we will take care of that later).

Let's create a bands microservice:

$ mkdir api
$ touch api/bands.js

`api/bands.js`

module.exports = (req, res) => {
  const bands = [
    {
      name: 'Dio',
      genre: 'Heavy Metal'
    },
    {
      name: 'Anthrax',
      genre: 'Trash Metal'
    },
    {
      name: 'Tenebrarum',
      genre: 'Gothic Metal'
    }
  ]
  res.end(JSON.stringify(bands))
}

yes, I like Metal 🤘

Let's create a Deployment Configuration file to wire up our two project in the monorepo.

`now.json`

{
  "version": 2,
  "name": "monorepo",
  "builds": [
    { "src": "www/package.json", "use": "@now/static-build" },
    { "src": "api/*.js", "use": "@now/node" }
  ],
  "routes": [
    { "src": "/api/(.*)", "dest": "/api/$1" },
    { "src": "/(.*)", "dest": "/www/$1" }
  ]
}

More information about how routes work in their documentation.

Here we are creating both the API and the Web project in one single repo using two different serverless applications, one served by @now/node and the other built by @now/static-build.

Before deploying let's add the following to our www project:

Add a now-build script to the package.json file as following:

"now-build": "API_URL=https://monorepo.julianduque.now.sh npm run generate"

This will setup Axios to discover our API endpoint in the proper URL (make sure to use your alias here), and will tell now how to generate a static site for Nuxt.

Let's update our pages/index.vue page to execute the Bands microservice we implemented with Node.js

export default {
  components: {
    Logo
  },
  data: function () {
    return {
      bands: []
    }
  },
  methods: {
    async loadBands () {
      try {
        this.bands = await this.$axios.$get('/api/bands.js')
      } catch (err) {
        console.error(err)
      }
    }
  }
}

Add a Button to the <template> and render the items with Vue.js

<a v-on:click="loadBands">Load Bands</a>
<ul v-bind:key="band.name" v-for="band in bands">
  <li>{{ band.name }} - {{ band.genre }}</li>
</ul>

And voila! We have connected our two serverless applications in one monorepo with Now!

I hope you liked this tutorial and if you speak Spanish let me invite you to my semi-weekly Node.js show on Twitch - Node.js ¡En Vivo! 💜