DEV Community: KyleJB

A key difference between .then() and async-await in JavaScript

KyleJB — Thu, 10 Sep 2020 17:52:31 +0000

Asynchronous code can be frustrating when its behaviors are not fully understood. In JavaScript, .then() and await are the most commonly used functions for handling asynchronous nature of a Promise. I'd like to take a stab at demystifying some of the quirks that make JavaScript feel "weird" in order to help us take full advantage of asynchrony.

When learning all about fetch() and the Promise fetch() returns, I was introduced to JavaScript's .then()function as a means of handling the asynchronous nature of a Promise. So, what's the deal with async and await? Is it just syntactic sugar to avoid .then()'s callback hell? Searching "async vs .then" in google produces front page results such as this stackoverflow post. But, as we all come to know on our coding journey, the devil is in the details...

In order to examine the behaviors of async-await and then, I built a small program. First, we need to create a database (I used json-server) to make our fetch requests.

Then, we need to write two functions that are practically identical save for one detail - one has to use then and the other has to use async-await. Take note of the carefully placed console.logs , as we will be tracking their appearances shortly.

Towards the bottom of the file, I added two additional console.logs wrapped around my invocation of the aforementioned function, I run both separately like so:

Before you read further, what order will the console.logs come out in? Do take into account the console.logs within the function definition themselves too...

The results!

Notice how then runs through the entire function and then continues the execution after the function invocation before returning back to the function to perform the series of then operations after the Promise was resolved?

Contrasting this with Async/Await, the function halts execution within the function scope continues to execute other tasks that follow its invocation before stepping back into the promise upon its resolution; this behavior will continue until all Promises are resolved.

Pan Wangperawong, quoted below, summarizes the differences succinctly in his blog post, which I encourage you to check out if you'd like more context.

`async-await`

Useful to use if your code works with Promises and needs to execute sequentially. Due to blocking, you might lose some ability to process code in parallel. I've primarily used async-await when making API requests. —Pan Wangperawong

`then`

If you develop your frontend with React.js, a typical use case might be to display a loading screen until a fetch request returns and then using a setState to update the UI. —Pan Wangperawong

An Introduction to Computer Networking for Web Developers

KyleJB — Tue, 18 Aug 2020 15:34:51 +0000

Have you ever stopped to think about how information is transmitted from computer to computer?

It's mind-blowing and we do it all the time – from making fetch calls in our applications to the daily usage of our computers.

Let's contextualize this exploration through the lens of RESTful protocols. Our data, like an email that we'd like to send to a friend, is broken up into "packets" that are transmitted from one computer and rebuilt on the receiving computer. Let's follow an email from your computer with an IP address of 1.2.3.4 as it traverses the internet to your friend's computer at IP address of 5.6.7.8.

We start from the top left corner of the diagram and work our way to the upper right hand corner:

The application layer is where we navigate to https://gmail.com to compose and send an email. If your message is too long, it will be broken up into packets as we enter the TCP layer of the networking protocol stack.
At the TCP layer, packets are assigned to port numbers based on the data type. The IANA governs and documents these conventions. For purposes of this introductory post, our takeaway should be that our packets are assigned to the appropriate port number for the receiving computer.
At the IP layer, our packets receive the destination address (e.g*., IP address of 5.6.7.8*).
Finally, we arrive at the hardware layer (e.g., ethernet cables) where our encapsulated alphanumeric data (i.e., strings) is transformed into electronic signals and gets sent across phone/cable lines – or light, if you have fiber.

Similarly to how UPS or USPS would route your online order from a warehouse overseas to your doorstep, your email packet traverses the internet in milliseconds to your figurative doorstep. Once arrived at 5.6.7.8, we reverse the steps outlined above. And with the help of checksums (a computation to confirm that no packets are missing or tampered with), the packets we sent are collected and reassembled on our friend's computer.

From a technical perspective, the data contained within (i.e., the email or picture) is very much the same. For those that are philosophically inclined, is the reassembled email really the same as what you sent?

In a future post, I would like to explore the OSI/TCP-IP model in more detail to explore topics such as security and performance to help us become better coders.

How should you secure your API token?

KyleJB — Tue, 18 Aug 2020 01:34:17 +0000

Welcome to my first blog post! I’d like to kick things off with a discussion on an important topic and propose an easy-to-implement solution to enable us to get started on what matters — our projects — while protecting ourselves on the internet.

This post will contextualize API key management on the presumption that you write in Ruby. However, the concepts herein should be applicable to any language.

Why should I care?
‘dotenv’ to the rescue
Implementation/TL;DR
Citations

1. Why should I care?

We’re ready to move from “Hello World!” to our first project, but how do we start? Learning how to program is a daunting task. Take it from me; I started this journey three weeks ago and I thought I had — at least — the basic best practices committed to memory when I jumped into building my first project: The Commuter (interfaces with NYC’S MTA API via CLI). Unexpectedly, the biggest obstacles that I have faced to date pertain to everything but programming.

If your first foray into this world was anything like mine, coding best practices were easily forgotten in the face of obstacles. In my situation, I was wrestling with tokens and how to pass their value to the server in order to gain access to their data. I resigned to hardcoding the tokens in my code in order to distill the problem.

Did you happen to instinctually bristle when I admitted to hardcoding my token in my application file? Why? Maybe it was because we were taught dynamic code is better than static code? Or, maybe what I did goes against common sense when dealing with private information — you wouldn’t write your username and password to your email address on a homework assignment after all, right? Regardless of your reason, haven’t we all found ourselves in this situation — hardcoding some variable to help solve a complex problem?

Although there may be a better way (do let me know), I would think this is a reasonable approach to take provided that we refactor our code after testing is complete. However, are you making commits on git (e.g., git add ., git commit -m “yay, api works")? Perhaps, you are also pushing that repository onto GitHub for your portfolio or to collaborate with others? Are you completely sure that you did not include those secret tokens within one the many commits or pushes to GitHub?

…hundreds of thousands of API and cryptographic keys leaked at a rate of thousands per day.¹

Researchers at North Carolina State University (NCSU) — Michael Meli, Matthew R. McNiece, Bradley Reaves — discovered that “even if commit histories are rewritten, secrets can still be recovered.” And, over the course of their study, many repositories publicly expose their key — like I almost did. And thanks to search indexing by companies like Google, it would have taken — on average — 20 seconds for my key to be discoverable through a search query that these researchers utilized.¹

While we cannot say from this analysis alone why cryptographic keys are leaked, it is clear that the poor practice of embedding secrets in code is a major root cause.¹

Because deleting those branches, files, or editing that line of code now would be too late, we need to set up our project folder correctly. And, on a brief tangent, I also recommend you take a look at Daniel Hahm’s Beginner’s Look at Git if you want to git better.

2. `dotenv` to the rescue

There are dozens of ways to handle the process. If you’re new to programming and are learning Ruby, I recommend the gem ‘dotenv’; this is easiest to implement and gets the job done.

Other programming languages have similar libraries that go by different names, but these all expect our file structure to incorporate a file (not folder) called .env that stores our secret environment variables, which we can then invoke in our code base as a variable. But, before proceeding further, add .env to your list in .gitignore. This will ensure that git will never add, commit, and/or push your .env file, thereby preventing public API exposure as long as you only keep the secret values hardcoded to the .envfile.

3. Walkthrough — from setup to implementation

Step 1 — install the ‘dotenv’ gem:

Add gem "dotenv"into your Gemfile and don’t forget to run bundle installafter doing so.

Step 2 — create your .envfile:

While your terminal is in your project directory, touch .envto create the file. If you’re using VSCode like me, the file will appear in root of your project:

.env is known as a “global file” to the dotenv gem and expects to find in the main folder of your project.

This is the only file where you should be writing your API key values and setting them equal to a CONSTANT (in Ruby, capitalized variables are constants — not global). Here’s an example of what this should look like:

Don’t worry… this isn’t my real API token. :)

You can define as many environment variables and values as you wish here. You can access the value of your key like so: ENV["YOUR_VAR_NAME"]. For example, if I wanted to use my API key, as depicted in the example above, I would write ENV["MTA_KEY"]in another file. But, none of this will work until we complete step 3: requiring the gem and making sure the gem loads so that it can access the locally defined environment variable we created here elsewhere in our project folder.

Step 3— file configurations:

:: **MOST IMPORTANT → create or update your .gitignorefile and add .envto the list like so:**

Note .env on line 15; this ensures that git commands will never add, commit, or push this file with your secret keys to the public domain.

:: SECONDARY CONFIGURATIONS → making dotenv accessible within our project directory:

require 'dotenv'
Dotenv.load

In my app, class MtaRunner is the only model that requires access to my MTA API key, so this would suffice.

If you’ve built a custom class (learn more about classes here by Michael Horowitz) for your API calls, you may add the aforementioned lines above your class definition as depicted on the left. Alternatively, you may also add the aforementioned lines of code into your environment.rb file provided that your project file is linked up to all your necessary folders/files properly; the benefit of adding the two lines to your environment.rb file is you can access your key in all your models without needing to write require 'dotenv'on each file.

If you want the ability to use dotenv when running rake consoleto debug or test your API, I wrote this bit of code in my Rakefile:

The change was done on line 3 and line 7. For any task(s) that may require dotenv, you can follow a similar pattern to ensure it runs concurrently with that desired task.²

Citations

[1]: Michael Meli, Matthew R. McNiece, and Bradley Reaves. (February 2019). How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories

[2]: Rubydoc. dotenv Documentation. https://www.rubydoc.info/gems/dotenv/2.0.0#sinatra-or-plain-ol-ruby