Forem: Shemona Singh

Junior Developers vs Senior Developers

Shemona Singh — Sun, 13 Mar 2022 17:19:43 +0000

Sometime last year, I came across Julie Zhou's article on Junior Designers vs Senior Designers. I love it - she does a fantastic job of highlighting the thought process behind different levels of a role. And with the understanding I've gathered in my blossoming career, today I'd like to do the same for developers.

I've had the privilege of working with exceptionally talented and thoughtful professionals since the start of my career. This might have intimidated me at first, but I quickly came to view them as mentors - a source of growth and exciting challenge. Much of my current skillset is influenced by them, but also quality time set aside in my day-to-day that's dedicated to deliberate practice. As I reach a point in my career where I'm steadily being assigned more senior-level tasks, I can't help but look back at my thought processes when I first started off and compare them to today's.

1 - Grasp on Foundational Knowledge

The tapestry of foundational knowledge for senior developers seem to be without a hole. The greater your understanding of how things come together or why something works the way it does, the greater your chances of building an optimal solution. In one of my first React projects, I wasn't sure how to get a component to update based off of a variable changing in another same-level component. I spent more time than I should have going down a rabbit hole of custom hooks, useMemo, useRef, and ended up with a hacky fix with useState. Looking back, it was clear that if I truly understood the component lifecycle and the reasoning behind some common React hooks, I would have known useEffect was built for the very purpose that I was attempting to solve for and I would have been done in just a few lines of code. If my fundamentals were clearer, I would have caught that earlier. Solid foundations are what contributes to razor sharp troubleshooting skills too...which leads me to my next point.

2 - Troubleshooting

I find that when junior devs encounter a bug, they'll attempt to through every bit of knowledge they have in that arena until something sticks (and by sticks I mean until they have a different error). Seniors approach a bug more heuristically, taking the majority of the time to understand what the problem even is before jumping to a solution. They'll ponder on what the missing puzzle piece is. Once that information gap is realized, the understanding naturally leads them to possible solutions they can retrieve from their tight-knit tapestry of previous troubleshooting scenarios.

3 - Knowing When to Break the Rules

A common beginners versus experts trope is the famous Picasso quote: "Learn the rules like a pro, so you can break them like an artist". Oftentimes when you're starting out, you're constantly seeking affirmation if the code you've produced checks off all the boxes. After some time, once you've gained the ability to make that judgement call yourself, you can bring that judgement into the process of coding itself. You know where it's ok to cut corners to postpone a requirement to version 2 because you know how version 1 will meet the expectations of stakeholders in the most important ways. This also ties into the laziness factor. There is a difference between being "efficiently lazy" in creating a speedier process to improve a future need versus being lazy as a conclusion of not understanding what cutting that corner will cost the team.

4 - Approaches to Problem Solving

You might be wondering how this differs from my point on troubleshooting. When I say troubleshooting, I mean that there is a clear error to be unblocked or bug to be fixed. When I refer to understanding a problem, this could mean a project requirement, like build a modal that pops up when you click on button X.

My Operating Systems professor in college once told our class, "if you understand the problem, but you don't know how to solve it, you don't understand the problem." This stuck with me. If I ever came to a point when trying to make something work where it seemed every direction was a dead end, it was a sign for me to step back and refine my approach. Refining my approach always meant going back to my understanding of the problem. It can be tempting for many junior developers to begin coding as soon as they have a quick, abstract grasp of what the problem is asking and then figure out edge cases along the way. Senior folks have mastered understanding what a problem is going to entail, and with speed.

A lovely example of this is when a project I was on involved building a text input with autocomplete ability. Upon seeing this requirement I was unsure of where to even begin. My teammate on the other hand, was able to build it in a few hours. Curious as to how, I asked him to walk me through his thought process:

I need this text input to autocomplete...where else has there been an autocomplete in the company's products? Ah, yes the landing page of product XYZ.
Dissect that autocomplete feature that's already in production. Open up the Network tab on Chrome DevTools and reload the page. What resources is it requesting? Looks like it's using resource ABC.
Use sourcegraph (a tool to universally search through all code in the company) to find instances of components using those resources.
Dissect those instances to see how they've built autocomplete.

While it might take a junior a few steps back into contemplating the problem once they've already dove deep into coding, seniors usually stick with the problem and then start once they fully grasp the scope. This helps them to build more reliable foundations with flexibility in mind, like what data should pass through which components as they have an idea of what else might come up if the direction changes.

5 - Giving Estimates on Deadlines

This ties in with point #4. Chances are, if you understand the problem better you're better equipped to know how long something will take to get done. This is helpful in kickoff meetings for a new project, pointing tickets in sprint planning, or even just any conversation with a stakeholder who's not an engineer. As the builder, heads obviously turn to you when a Product Manager asks, "So how long do we think this project will take?" or "Is end of June a viable target?" I'd always watch my fellow developers who were far senior to me with a look of mesmerization as they gave an answer consisting of the perfect balance between giving exact dates but leaving room for unexpected delays or dependencies. This is a skill that cannot really be "practiced" in a sense of an online course. It's something that comes with more development experience as well as time in the industry.

6 - Understanding Procedures in Software Beyond Coding

This is a jab at the commonly argued differences between studying computer science in an academic sense and applying software engineering in industry. Much of what happens before or after you push your code is not quite discussed in college because you rarely work in environments where what you're developing is directly going to affect someone else's branch - considering you're usually working alone. Let's think about the pipeline. Senior developers have a strong grasp on steps like linting, testing and building. When you're thrown into a new project as a junior developer who's only ever worked on python assignments that require you to build a function for some outdated mathematical function, it can be frustrating to troubleshoot your way through a pipeline failure.

Some of the points I've discussed here are ones I'm still practicing. Many are in your control, like picking up a new skill. But things like robust problem solving ability and confidence in scope understanding need time to develop. This is exactly why experiences like internships, freelancing and volunteering are invaluable assets to sharpen your judgement. Strive to put yourself in situations that challenge you with people that inspire you.

I know all too well this process of growth can feel maddening, like taking 2 steps forward and 3 steps back. Writer Alice Walker penned the discomfort of growth beautifully:

"Some periods of our growth are so confusing that we don’t even recognize that growth is happening. We may feel hostile or angry or weepy and hysterical, or we may feel depressed. It would never occur to us, unless we stumbled on a book or a person who explained to us, that we were in fact in the process of change, of actually becoming larger than we were before. Whenever we grow, we tend to feel it, as a young seed must feel the weight and inertia of the earth as it seeks to break out of its shell on its way to becoming a plant. Often the feeling is anything but pleasant. But what is most unpleasant is the not knowing what is happening. Those long periods when something inside ourselves seems to be waiting, holding its breath, unsure about what the next step should be... for it is in those periods that we realize that we are being prepared for the next phase of our life and that, in all probability, a new level of the personality is about to be revealed."

For all the junior developers out there: May the pressure to perform be lifted. I hope this article will help you to see there are key areas you can productively focus your energy. As for the rest, time will tell.

Shoutout to ShutMeLoud for the hilarious gif on the cover. Be sure to check out the video for the full clip.

Animated Progress Bar With Only SVGs

Shemona Singh — Sun, 06 Jun 2021 20:33:41 +0000

Have you ever wondered how to make one of those neat little progress bars you see in so many loading interfaces?

A little while back I talked about how we can build the other category of loading animations, a spinner. Today, I want to show how you can use the power of SVGs yet again to create the simplest progress bar you've ever seen to date. No double layered divs filling, no glitches. Plain ol' React and scss.

What would be needed for something like this? Much like the loading spinner we need some data to wait on. I'll fake that part for tutorial purposes. While we're waiting, we can launch a keyframe animation to fill the svg bar. Is the waiting done? Put a 'completed!' message of your choosing.

Ok, so what does this look like in code speak. For the structure we have:

import React, { useState, useEffect } from 'react';

export const Progress = () => {
  const [loading, hasLoaded] = useState(false);

  useEffect(() => {
    const timer = setTimeout(() => {
      fetch('https://jsonplaceholder.typicode.com/posts')
        .then((response) => response.json())
        .then((json) => {
          hasLoaded(true);
        });
    }, 1550);

    return () => clearTimeout(timer);
  }, []);

  return (
    <div className={`progress ${loading ? "progress-success" : "progress-failure"}`}>
      {loading ? (
        <p className="ending-msg">Loaded!</p>
      ) : (
        <svg role="alert" aria-live="assertive">
          <rect x="1" y="1" className="border" rx="15" ry="15" />
          <rect x="1" y="1" className="filling" rx="15" ry="15" />
        </svg>
      )}
    </div>
  );
};

Brief overview of what's happening:

We create a state called loading to check whether we are waiting for data or the waiting has ended. This only need be a boolean, because either the progress bar is loading or not. It initially starts off as false, because we haven't requested any data yet.
useEffect is where we can check the loading state and show our progress bar animation if the loading state is true. The sample fetch request is just there to illustrate this point, as you will likely be waiting on some event when using a progress bar. The setTimeout is just to mock the waiting time, in reality you would not need this since the program would naturally be waiting on whatever it is you need the bar for.
If you do end up using the setTimeout, you might be wondering why I choose 1550 milliseconds. This number depends on however long the fillBar animation is running for, which we will see in the styles. Basically, it needs to be at least 50 milliseconds longer than the fillBar animation. You can update this or remove the setTimeout entirely.
In terms of what we end up rendering, we have one div that holds everything. Inside, we have a conditional for our two states: If the content has loaded already, print an ending message. If the content has not yet loaded, then keep the progress bar animation going.
The bar is split into two rectangle svgs, one defining its outline and the other defining its border. We also set the radius to make it a little more curved and define attributes like height and width. Everything else will be handled in the styles.

Speaking of which, let's make the magic happen:

.progress-success {
  .ending-msg {
    color: green;
  }
}

.progress-failure {
  .ending-msg {
    color: red;
  }
}

.progress {
  .border {
    width: 200px;
    height: 30px;
    stroke-width: 2px;
    stroke: blue;
    fill: transparent;
  }

  .filling {
    width: 200px;
    height: 30px;
    fill: blue;
    animation: fillBar 1.5s ease-in-out 0s normal 1 forwards;
  }

  @keyframes fillBar {
    0% {
      width: 0;
    }
    30% {
      width: 80px;
    }
    70% {
      width: 120px;
    }
    100% {
      width: 200px;
    }
  }
}

Here we are doing a good amount of setting colors, border widths, etc. But what's actually making the animation run is the fillBar keyframe we have running on the svg with the className of .filling. In fillBar, we define the progression of how we want to fill the progress bar by simply increasing the width of the svg, which by being inside of the svg with a class name of .border gives the illusion that it's filling the bar. The actual speed and transition is defined by the way we call the keyframe, seen in the animation property.

Now let's see it completed. Click on the 'rerun' button on the bottom right to see it again.

Now you know how to make a smooth progress bar with just a bit of smart svg manipulation. Play around with timings and styles to really jazz up your animation!

How to make the Firebase Realtime Database Rules Secure for a Blog

Shemona Singh — Sat, 13 Mar 2021 14:21:29 +0000

Last year I revamped my blog with a new design and a Firebase Realtime Database. It was a fairly smooth ride with some minor complications along the way. As for setting up the database, I found some awesome tutorials that eventually helped me filter it all down to some pretty simple steps.

The blog was running as planned, until one day I received an email from the Firebase team telling me the rules I had set for my database were insecure.

I was confused, so I did what I usually do when I try to get to the bottom of things:

I read through a bunch of articles.
Played trial and error with variations of rules.
Posted on the Firebase community chat.
Went back and forth with the lovely Firebase support team.

Finally, after weeks of those daily emails, they stopped. Let's take a look at what database setup and rules finally secured them.

The only information my database stores is in regards to the posts. It looks like this:

If you've looked through the documentation for Firebase's security rules, you may be familiar with the read / write set up. My website is a public blog, with no authentication or collecting data from the user of any kind. So, I only needed read requests to be allowed, but any write requests would be denied as I maintain the adding of new blog posts via uploading a new json file in the console.

So, my rules look like this:

Obviously, my auth.uid is greyed out. You might be wondering where I got that id from. I opened up my project on the Firebase console, clicked on 'Authentication' on the left menu and set up one user - myself. Under the 'User UID' column you will find the auth.uid. However, as I mentioned I don't have authentication set up for my website, so you may be able to get by without doing this step. If you read on, you'll see the biggest security step was not this auth.uid, but the addition of posts in my rules. Try out both and see what happens.

It's important to note I then also had to change the way I requested data from the database in my useEffect() hook. All I had to do was add the word 'posts' after the / when requesting the slug:

useEffect(() => {
  db.ref()
    .child(`/posts/${slug}`)
    // ...rest of code
}, []);

If you'd like to see the rest of my useEffect() hook and how it all works together to retrieve and place data, check out my post on Reading and Writing from a Database with React.

Previously, I was doing .child('/${slug}'). When speaking to the Firebase support team, I was informed that requesting from the root node of my database is what was causing the security vulnerability. So, adding another node called 'posts' between the root level and the posts secured it. Before, I didn't have the posts node in the rules or database and it went straight to all the posts objects.

And that's all! Now my rules are secure. 🎉 I feel better about not contributing to security leaks but better yet I no longer get those worrisome emails.

Note: If you have authentication set up or require extensive database layering and security rules, this is a good blog post to refer to.

The Easiest Way to Animate a Loading Spinner

Shemona Singh — Sun, 28 Feb 2021 15:52:01 +0000

While on a quest to learn how to build some of the most commonly requested animations by designers, the loading spinner seems like a rite of passage.

This time around, I wanted to see if I could use the awesome power of svgs to draw out a circle then animate that circle. This could be a lot cleaner than attempting to animate borders or place rotating circles on top of other circles in CSS.

We will be building today's spinner here with React. Thinking in terms of states, there are two main ones. We are either:

Waiting for something - show the spinner
That something has happened - no longer show the spinner

To make this feel more realistic, we will have the spinner wait for a response from the Fetch api. There are plenty of open apis for us to request from for the sake of this tutorial.

Take a look at the set up for our component.


import React, { useState, useEffect } from 'react';
import './Loading.scss';

export const Loading = () => {
  const [loading, hasLoaded] = useState(false);

  useEffect(() => {
    const timer = setTimeout(() => {
      fetch('https://jsonplaceholder.typicode.com/posts')
        .then((response) => response.json())
        .then((json) => {
          hasLoaded(true);
        });
    }, 1100);

    return () => clearTimeout(timer);
  }, []);

  return (
    <div className="spinner-container">
      {loading ? (
        <p>Content has loaded!</p>
      ) : (
        <svg className="spinner" role="alert" aria-live="assertive">
          <circle cx="30" cy="30" r="20" className="circle" />
        </svg>
      )}
    </div>
  );
};

Let's walk through what's going on here.

First, we set up the two states I mentioned at the beginning. The only two states the spinner can be in: either we are waiting for something to happen, or it has already happened. A simple boolean does the trick.
The handy useEffect hook is where we can handle what it is that we're waiting for. It's likely you'll be waiting for some data to return, so I've set up a sample fetch request. You may also notice I have it wrapped inside of a setTimeout. This is because the information comes far too fast for us to see the spinner in action, so for the purposes of delaying our response I've added a setTimeout that you're welcome to adjust in order to see the spinner for longer. I have it set to 1100 milliseconds so that we can see the spinner for at least a second. In reality, you might not need a setTimeout since the data you'll be requesting will likely take it's own time.
In the return of the useEffect, I clean up the setTimeout like the responsible developer I am. 😇
Now for the actual component. We have one div that holds everything. Inside, we set our two states: If the content has loaded already, print something that tells us this. If the content has not yet loaded, this is where we render our animated spinner.
The spinner is a simple circle tag wrapped inside of an svg tag. We define some attributes like height and width, as well as those that will make it accessible like aria-live and role.

Ok! We have the skeleton of a spinner. But, there's nothing to see yet. The styles are where the actual magic happens. Let's take a look at them:

.spinner-container {  
  .spinner {
    transform: rotate(-90deg);
    width: 60px;
    height: 60px;

    .circle {
      stroke-linecap: round;
      stroke-dasharray: 360;
      stroke-width: 6;
      stroke: blue;
      fill: transparent;
      animation: spin .6s ease-in-out 0s normal infinite;
    }
  }

  @keyframes spin {
    from {
      stroke-dashoffset: 360;
    }
    to {
      stroke-dashoffset: 40;
    }
  }
}

Now, let's walk through the styles.

We have the .spinner-container wrapped around everything. Pretty straightforward.
The svg gets a class of .spinner with height and width specified as well as the rotation that will occur while being animated.
The .circle class is where I first define some stylistic qualities to the actual circle and then the animation property is the key to it's movement. I set it to be the keyframe animation named spin, which is simply pulling the filling of the circle forward.

Here is what it all looks like in action. Be sure to hit the 'rerun' button on the bottom right.

Voila! Just a few lines of scss to make the spinner come to life. Years ago before I knew this handy tactic of manipulating and animating the fill of svgs, I had built a different spinner. It used bulky, confusing styles to make the drawing of the border for a circle div seem fluid.

Makes you question coding patterns you might be unconsciously following now that could be done more efficiently. 🤔

What's Really Going On In A Chrome Extension

Shemona Singh — Sun, 14 Feb 2021 16:36:18 +0000

A few weeks back, I set out to create my own chrome extension with Typescript and React. I had a rough understanding from a talk I had attended at work some years back. So, I approached it assuming it was going to be as simple as getting back in the swing of my previous understanding.

It was in fact pretty simple to get started and even more easy to render visible changes. But there was something else that took up most of the time I spent that day setting up - understanding the anatomy of a chrome extension. That is, there seemed to be a few key files but I wasn't sure which one to change when. I browsed several articles and youtube tutorials but nothing seemed to click. After a while, it was as if my brain had picked a little bit from each tutorial and started to make sense of it all. To further solidify my understanding, I begin to draw out a representation of the anatomy. This diagram would be updated upon testing if the assumptions I had made were in fact correct.

Turns out they were, and this diagram is what I'd like to break down today.

The file names I'm using come from a typescript chrome extension template I started with. When attempting to build an extension, do yourself a favor and don't start from scratch. Start with this, or a different template of your choosing. Most of my annoyances involved setting up the precious manifest.json file, but starting from a template helps to avoid all of this. Before proceeding, I recommend having either the template repo up or a chrome extension project you have already started open on your choice of text editor. This is so when I mention a file name it'll be easier to follow along.

If you're on the repo, take a look at the contents of the src and public folders. Identify the files: background.ts, content.ts, index.tsx, and options.tsx. If you're using a different template they might be named differently, but that's a pretty standard naming convention for an extension. (Sometimes index can be named popup). These are the four vital bones of the extension. Let's break down each bone and help grasp what they support.

For the purposes of explaining this diagram, let's create an example to work with. Let's say you want to make a chrome extension that makes it rain images of coffee cups every time someone is on the Starbucks website. Let's dissect the diagram with this example in mind:

The labels in green are for the 4 files I mentioned earlier.
The labels in black are for what each webpage represents.
The webpage on the top left I labeled as 'specified in manifest.json' would be the Starbucks homepage. We would specify the url of Starbucks in the manifest.json.
The webpage on the bottom left represents all the webpages that are not the Starbucks webpage. We don't have to specify these urls anywhere, it's just important to note what file you would have to edit if you want your extension to do something no matter what webpage you are on.

Note that putting something into each of these 4 files is optional. Say you set up your falling coffee cups script on content.js, that will trigger on the Starbucks page. If that's all you want to do and don't want anything to happen on webpages that are not Starbucks, feel free to leave background.ts empty.

The realization of each file's purpose and knowing what to change when was the single biggest factor in continuing the successful development of an extension. It's hard to get something to trigger properly when you're not sure which file it belongs in. My hope is that you come across this diagram in your journey of chrome extension tutorials, and everything will finally click the way it did for me.

Should learning be a means to an end?

Shemona Singh — Fri, 29 Jan 2021 20:23:59 +0000

For a few months now, when it came to adding a new skill to my technical tool belt I was under the school of thought that the best way to do so was with a project.

Well maybe I shouldn't say best, but at least I was highly biased towards that line of reasoning. I went down a whirlwind of learning via the deliberate practice strategy but without a clear goal. Eventually I reached a point where I didn't feel any sense of progress. With any habit, you want to make some noticeable move to the needle. After all, with no project how would I even work through the pile of information there is to learn and find what interests me? Why pick up a new technical skill for the unknown sake of it when I could build something that excited me and learn as a natural side effect?

The Problem

My bias ended when that thought process didn't work so well in a project. A few months ago I had an idea for an app that would solve a recurring problem of mine. I had a long term vision, but to prevent my vision getting in the way of an MVP I decided on some key features that absolutely needed to be there to get the point across. I came up with 3 main screens, each of which had 1 or 2 core functionalities. As someone with a background in web development (like that made a difference), this seemed attainable in at least under a month. Right?

Well, turns out it was attainable in about 2 weeks. But like all projects, unpredictable obstacles arose. All of which I was able to debug my way through just fine. Except for one. One that opened my eyes to further nightmares of mobile development.

Thanks to fellow techie friends I started off with the knowledge that learning mobile development might start off feeling like working with an angry dragon. I acknowledged this and continued working. Once I reached 3 screens, I felt like I had conquered the dragon. It wasn't until I needed to implement the next feature that I realized I had just been playing with the tail of the dragon and in fact the dragon was yet to be woken. Being in the weeds of the errors gave me the confidence to recognize the size of the dragon.

This led me to question my aforementioned approach in learning something new. If I had just dabbled in mobile development for the sake of it, could I have foreseen this bug occurring? When picking up a new skill in the field of software, is it better to approach it with some conclusive means? Or does one learn better when there is no conclusion in sight, and rather for the pure joy of being immersed in the knowledge?

This naturally led me to brainstorm some pros and cons for each:

Learning with an end goal in mind

Pros:

End with something to show for your work
Motivation might be higher? With the understandable clarity
Some structure to your learning, you know what trees to traverse in the forest of knowledge for that field

Cons:

You can get caught up in the product, not the learning (build something small article about side projects)
If you don't reach the goal, it's easy to adapt the negative mentality that failure of the product is failure in the field

Learning just for the sake of learning

Pros:

No pressure, no expectations
Helps you connect what your learning to other things you've learning because by nature learning is the art of connection

Cons:

Can easily forget what you've learned if you don't revisit it for some time
Might be confusing where to start
Can fall into the habit of passive consumption without active implementation - the phase where you actually learn

Discuss

I recently came across Paul Graham's What You'll Wish You'd Known. In it, he had a fantastic quote about recognizing the scope of where your learning can take you:

Writing novels is hard. Reading novels isn't. Hard means worry: if you're not worrying that something you're making will come out badly, or that you won't be able to understand something you're studying, then it isn't hard enough. There has to be suspense.

I suppose then, the answer is not that you should enroll in either of the schools of thought, but rather that learning in general should strain you in the best way possible. If that's not happening, whether you're building something or taking an online class, it's unlikely you're learning.

When you want to dive into a new field of tech, are you more likely to follow one of these schools of thought? Maybe you approach each scenario as a standalone battle, that requires a mixture of both schools? That seems to be where I'm leaning at the moment.

Reading and Writing from a Database with React (simplified)

Shemona Singh — Fri, 15 Jan 2021 15:31:08 +0000

The ability to make read and write commands from a database is one of the most standard, necessary skill for any backend developer. So naturally, when I began to venture into the world of building dynamic websites it was one of the first requirements that came up. When I attempt to picture logistically the flow of what reading and writing from a database must be, it feels simple. My only hope is that it's as simple in practice.

It is.

Well, I should clarify - I'm using Firebase. Why? It has one of the more generous free plans amongst the database land, and as a tinkerer who is never quite sure what restrictions some of the spaces I'm working in have, it made sense that I choose Firebase. I went through several awesome tutorials (two of my favorites linked at the bottom of this post), and many of which had some step that either did not work for me or were missing some vital feature. This tutorial is going to be the most barebones version of my collection of steps that ended up working.

Any frustrations I had from the wonderful tutorials performing similar tasks stemmed from not being embarrassingly simple to do. Most of them had an end-UI goal in mind, which the building out of added fluff to the parts of the tutorial I was really trying to get at. Therefore in this post, we're not building anything. We are simply learning to send some data to a database and then retrieve that data.

1 - Set up your account

If you go to the Firebase console and you don't see an option to add a project:

Then that means you aren't yet set up with an account. Pretty hard to go on without doing this part. So, let's get you an account.

Sign up with an existing Google account
Now you should be led to your console. Click the "Add project" button (from the above image) and follow through with the default settings it provides.

2 - Save your configuration details

In order for you to talk to your database, you need to get some special configuration details that the database can then authorize your attempted connection with. On approval of these details, the database can then spill the details you request.

Click on the project you just made. You should be seeing a dashboard of sorts that provides all kinds of insights. On the left, you'll see a menu. Under 'Build', click on 'Realtime Database'.
When you scroll down, you'll see a white box that says 'There are no apps in your project'. Click on the </>.
Name the app what you'd like. Leave the hosting option unchecked and click on 'Register app'. Follow the default prompts.
You're going to get some HTML with a variable called 'firebaseConfig'. These are your config details. In your code editor of choice, open your project (or create a new React project to follow along with this tutorial) and create a file called config.js (or whatever you'd like to name your config details). Paste the following into that file:

import Firebase from 'firebase';

const config = {
  apiKey: '',
  authDomain: '',
  databaseURL: '',
  projectId: '',
  storageBucket: '',
  messagingSenderId: '',
  appId: '',
  measurementId: '',
};

const app = Firebase.initializeApp(config);
const db = app.database();
export default db;

Go back to that HTML that Firebase gave you. If you can't find it, it's in your project settings. Fill out the empty strings in the config object you just made with the corresponding details from the firebaseConfig object.

3 - Make a call to the database

Now that you have what you need to be authorized, you can set up a connection to your database so it knows you want to be heard. But, you need a package to help you do this. So first install the firebase package with the following command: npm install firebase.

4 - Now I want to...send some data

Since our database is empty, it makes sense that we first want to put something into it. Firebase works with json files, so you can just make a json file containing the data you'd like and upload it to your database with the 'import json' button. You can find this button by clicking on 'Realtime Database' on the left menu and selecting the 3 vertical dots on the top right of your database.

But, that's no fun. Also, it's not how you would work with a database in actuality. So, let's pretend some event just occurred and we want to let Firebase know to store a piece of information resulting from it. I've outlined below how this would be done. To make sense of it, follow the code in the order of the steps provided:

import React, { useState } from 'react'
// 1 - Import your db config
import { db } from '/config.js'

// 2 - Let's start building our component, we're giving it
// the name SendData
export const SendData = () => {
// 3 - We'll set up two states, the values of which will 
// be sent to the database
  const [ text, setText ] = useState('');
  const [ num, setNum ] = useState(0);

// 5 - This is where the magic happens. When the 'Send to
// Database' button is clicked, we tell the database we 
// imported in step #1 as db to push to its root (/) whatever 
// values we have in our 'text' and 'num' states. You might be 
// wondering what 'number' and 'words' are - they are the 
// names of the keys that will be paired with the values from 
// our state. You can change them to what you'd like  
  const send = () => {
    db.ref('/').push({ 
      number: num,
      words: text,
     });
  }

  return (
// 4 - A simple form (yes I know it's not accessible, bare 
// with me) that will store the value of the number and any 
// words you input into the states we setup in step #3. The 
// button runs the 'send' function (see step #5) when it's clicked
    <form>
      <input type="number" onChange={getNum => setNum(getNum)} placeholder='Enter a number' />
      <input type="text" value={text} onChange={getText => setText(getText)} placeholder='Enter some text' />
      <button onClick={send}>
        Send to Database
      </button>
    </form>
  );
}

Try playing around with this component, sending different keys and values. Maybe make different state types altogether.

Assuming you followed steps #1-4 with success, upon clicking that 'Send to Database' button the data you enter will now show up in your Firebase console under 'Realtime Database'. Try entering and submitting more values and see how your database fills up! If you don't see anything, be sure to refresh the Firebase page.

5 - Now I want to....get some data

Now we have a filled database - yay! How about if we wanted to see all the values in this database? Let's add another component that does just that. This time, we'll use the useEffect hook to establish a connection to the database once the component mounts, and let Firebase know what we want within there:

// 1 - Import the usual statements 
import React, { useState, useEffect } from 'react';
import { db } from '../../config.js';

// 2 - Now we're building a component that gets the data, so 
// we'll call it GetData
export const GetData = () => {
// 3 - Set up a state that will hold the data we receive from 
// the database in useEffect(). This will make it easy for us 
// to just read from this state. It's going to give us back an 
// object, so we'll initialize the state as an empty object 
  const [ data, setData ] = useState({});

// 4 - Here, we're saying at the root (/) of the database, get 
// a snapshot of all the values you see. Set the result of
// this attempt into a variable named 'info'. Since 'info' is 
// an object, we'll use the spread operator to pass all of 
// it's values to a variable called 'allInfo', and then update 
// our state to be the value of 'allInfo'
  useEffect(() => {
    db.ref('/').on('value', (querySnapShot:any) => {
      let info = querySnapShot.val() ? querySnapShot.val() : {};
      let allInfo = {...info};
      setData(allInfo)
    });
  }, [])

  return (
// 5 - We potentially have something inside of our 'data' 
// state. I say 'potentially', because something could go 
// wrong and we might not be able to read from the database. 
// If this happens, our 'data' state will be empty. So, let's 
// use a [conditional operator](https://reactjs.org/docs/conditional-rendering.html#inline-if-else-with-conditional-operator) to first test if it's empty and give our reader a message. 
      {data === {} ? "no data to show here!" :
// 6 - Now for the 'assuming we have some data' part. Since 
// it's an object, we can use the following syntax to parse 
// through it (much like we can loop through an array with 
// map()) and spit out each value of the keys we set earlier 
// in step #4, 'number' and 'words'.
        {Object.values(data).map((value) => 
          <ul>
            <li>{value.number}</li>
            <li>{value.words}</li>
          </ul>
      )}
    }
  );
}

This code will render on the page a list of all of the 'numbers' along with their 'words' that you submitted through the form in step #4. If you skipped step #4 and just uploaded a json file, then it will still work - just be sure that you change 'number' and 'words' to be whatever keys you set in your database.

There are many tiny details throughout this setup that can go haywire, such as the specific values you use in your database, getting your configuration correct, TypeScript-specific issues and much more. It's the reason why I wasn't able to follow just one tutorial. Thus, I've tried many variations of making a simple read and write system and finally boiled it down to the above code. I'm hoping this tutorial helps drown out the noise by filtering down to the absolute basics what it takes to interact with a Firebase database.

If you have specific problems that come up while going through this tutorial, feel free to message me and I'd be happy to help debug. I've probably come across it as well. 😅

Thank you to the following posts that were a part of the journey in making sense of working with Firebase. There were several more, but these brought me the furthest along:

Thanks to Lynda.com for the cover photo.

Learning NodeJS Part 5: Setting up a Node (Express) Development Environment

Shemona Singh — Sun, 03 Jan 2021 21:33:45 +0000

In late fall of 2020, I went on a mission to better understand Node. I wanted to improve the way I use it, how I might be able to use more of its features, and moreover grow my front end knowledge to full stack. This series includes the notes I've compiled from my learnings over at The Odin Project. The lessons also include general web concepts necessary to better work with Node.

Now let's setup a basic Express app and breakdown some of its included files.

Express Application Generator

What is the Express Application Generator?

NPM can be used to globally install the Express Application Generator, a tool that creates skeleton Express web apps that follow MVC.

npm install express-generator -g

How do you create an Express app named "helloworld" with default settings

Navigate to where you want to create it and run express helloworld
It will generate a package.json file for you, with some dependencies. Install all dependencies via cd helloworld and npm install
Run the app! DEBUG=helloworld:* npm start

Navigating Contents of a Node project

What version of Node/Express should you use?

Generally, you should use the most recent and long-term supported release of Node. Always use the latest version of Express.

What is the purpose of a package.json file?

You can manually use NPM to separately fetch each needed package. Typically dependencies are managed using a plain-text definition file named package.json. This file lists all the dependencies for a specific JavaScript "package".

It should contain everything NPM needs to fetch and run your application. If you were writing a reusable library you could use this definition to upload your package to the npm repository and make it available for other users!

What are development dependencies?

If a dependency is only used during development, you should instead save it as a "development dependency" so that your package users don't have to install it in production. For example, to use the popular JavaScript Linting tool eslint you would call NPM as shown:

npm install eslint --save-dev

The following entry would then be added to your application's package.json:

"devDependencies": {
    "eslint": "^7.10.0"
  }

What do named scripts allow us to do?

Named scripts are defined in the package.json and call NPM to execute run-script on whatever it is you've set it to. For example:

"scripts": {
  "lint": "eslint src/js"
}

By adding this, we can now run npm run lint and it would run npm run-script eslint src/js for us.

Middleware

What is the role of middleware?

A middleware is just a plain JavaScript function that Express will call for you between the time it receives a network request and the time it fires off a response (i.e. it’s a function that sits in the middle). For example, you might have an authenticator that checks to see if the user is logged in, or otherwise has permission to access whatever they’re requesting.

Route functions end the HTTP request-response cycle by returning some response to the HTTP client whereas middleware functions typically perform some operation on the request or response and then call the next function in the "stack", which might be more middleware or a route handler.

Let's see what a typical middleware function looks like:

const myLogger = function(req, res, next) {
  console.log("Request IP: " + req.ip);
  console.log("Request Method: " + req.method);
  console.log("Request date: " + new Date());

  next(); // THIS IS IMPORTANT!
}

app.use(myLogger)

req - object with data about incoming request, ex. any parameters in the URL
res - object that represents the response that Express is going to send back to the user. You usually use the information in req to determine what you're going to do with res by calling res.send()
next - very important, tells express to move to the next middleware in the stack, but if you forget to call it then your app will pause and nothing will happen
app.use - is how you load your middleware function into Express so that it knows to use it. It will write these details to the console every time you get a network request

What is the only middleware function that is part of Express that allows us to serve files like images, CSS and JS?

express.static, or static().

How are errors handled?

By one or more special middleware functions that have four arguments, instead of the usual three: (err, req, res, next).

Express comes with a built-in error handler, which takes care of any remaining errors that the app might encounter.

Routes, Views and Controllers

What are routes?

A route is a section of Express code that associates an HTTP verb (GET, POST, PUT, DELETE, etc.), a URL path/pattern, and a function that is called to handle that pattern.

What are template or "view" engines?

Allow you to specify the structure you want the data to be outputted via a template. You can have placeholders for data that will be filled in when a page is generated.

Express supports many template engines.

How would one get started with using a template engine?

Start by installing the package containing your template library, then:

const express = require('express');
const path = require('path');
const app = express();

// 1 - Set directory to contain the templates ('views')
app.set('views', path.join(__dirname, 'views'));

// 2 - Set view engine to use, in this case 'some_template_engine_name'
app.set('view engine', 'some_template_engine_name');

// 3 - The appearance of the template will depend on what engine you use 
// Assuming that you have a template file named 
// "index.<template_extension>" that contains placeholders for data 
// variables named 'title' and "message", you would call 
// Response.render() in a route handler function to create and 
// send the HTML response:
app.get('/', function(req, res) {
  res.render('index', { title: "'About dogs', message: 'Dogs rock!' });"
});

This brings us to the conclusion of foundations in Node and Express. To put all of your new knowledge to the test, I recommend following the Local Library tutorial over at MDN Web Docs. This project will use all the concepts I've mentioned in this 5-part series, and will truly help solidify a holistic view of Express.

Learning NodeJS Part 4: Introduction to Express

Shemona Singh — Sun, 03 Jan 2021 21:33:37 +0000

The purpose of this section is to gain familiarity with what Express is, how it superpowers Node with the functionalities it provides, and the main building blocks of an Express application.

Understanding Express

Why use a web framework?

Common web-development tasks are not directly supported by Node itself. If you want to add specific handling for different HTTP verbs (e.g. GET, POST, DELETE, etc.), handle requests at different URL paths ("routes"), serve static files, or use templates to dynamically create the response, Node won't be of much use on its own. You will either need to write the code yourself, or you can avoid reinventing the wheel and use a web framework.

Explain the general process of how a dynamic web app functions. Where does Express fit into this?

In a traditional data-driven website, a web application waits for HTTP requests from the web browser (or other client). When a request is received the application works out what action is needed based on the URL pattern and associated information contained in POST / GET data. Depending on what is required it may then read or write information from a database or perform other tasks required to satisfy the request. The application will then return a response to the web browser, often dynamically creating an HTML page for the browser to display by inserting the retrieved data into placeholders in an HTML template.

After the request is received, this is when Express can come in handy. From Node's perspective, Express is just another package that you need to install using NPM and then require in your own code.

Express is often described as 'unopinionated', what does that mean?

Unopinionated frameworks have far fewer restrictions on the best way to glue components together to achieve a goal, or even what components should be used. They suggest the best setup is the one you think would work optimally for use case.

Write "Hello World" with Express

const express = require('express'); // import express module
const app = express(); // create an Express application
const port = 3000;

// route definition, callback function that will be invoked whenever
// there is an HTTP GET request with a path relative to the site root
// callback function takes a request and a response object as arguments
// and calls send() on the response to return the string "Hello World!"
app.get('/', (req, res) => {
  res.send('Hello World!')
});

// starts up the server on a specified port ('3000')
// prints a log comment to the console
app.listen(port, () => {
  console.log('Example app listening on port ${port}!')
});

Databases with Express

How do CRUD operations correlate to HTTP methods in Express?

The CRUD operations roughly correlate to the HTTP methods that you can employ in an express app. This definition can be somewhat flexible, but in general create correlates to POST (or app.post() in an express app), read correlates to GET (app.get()), update to PUT (app.put()) and delete to DELETE (app.delete()).

What are two common ways for interacting with a database and the benefits of each?

Using the databases' native query language (e.g. SQL), which results in the best performance
Using an Object Data Model ("ODM") or an Object Relational Model ("ORM"). An ODM/ORM represents the website's data as JavaScript "objects" or "models", which are mapped to the underlying database by the ORM. Some ORMs are tied to a specific database, while others provide a database-agnostic backend. The benefit here is that programmers can continue to think in terms of JavaScript objects rather than database semantics.

When designing your models it makes sense to have separate models for every "object". What are "objects"? If you were thinking of making an app to represent the functionings of a library, what would be some example objects you might have?

Objects are a group of related information. Some obvious candidates for a library project's models are books, book instances, and authors.

You might also want to use models to represent selection-list options (e.g. like a drop-down list of choices), rather than hard-coding the choices into the website itself — this is recommended when all the options aren't known up front or may change.

Once we've decided on our models and fields, we need to think about the relationships between them. How is this planned?

With a UML association diagram.

The multiplicities are the numbers on the diagram showing the numbers (maximum and minimum) of each model that may be present in the relationship. For example, the connecting line between the boxes shows that Book and Genre are related. The numbers close to the Book model show that a Genre must have zero or more Books (as many as you like), while the numbers on the other end of the line next to the Genre show that a book can have zero or more associated Genres.

Let's move onto setting up a working development environment with Express.

Learning NodeJS Part 3: Getting Started

Shemona Singh — Sun, 03 Jan 2021 21:33:28 +0000

Let's look at some common Node jargon, and what it means to develop these features in a Node environment.

Modules

What is a module?

Think of modules as libraries - a set of functions you can choose to include in your app.

How does one create and use modules?

To create your own module, use exports to make properties and methods available outside of the module file. The following returns the current date and time:

exports.myDateTime = function () {
  return Date();
};

Once you've created a module, to actually use the module in a different JS files we utilize the require() function, passing to it the name of the desired module. You also use this for including modules that are built-in:

var myDateTime = require('myDateTime');

Now, let's practice making modules as well as using existing ones.

Creating and Using a Module

Create a square.js module with a method called area(), then include area() in a new file (example.js) to calculate the area of a square with a width of 4.

// square.js 
exports.area = function(width) { return width * width; };

// OR

module.exports = {
  area: function(width) {
    return width * width;
  }
};

// example.js
const square = require('./square'); 
console.log('The area of a square with a width of 4 is ' + square.area(4));

Using the HTTP Module: Set up a basic web server with Node

var http = require('http');

// The function passed into the http.createServer() method
// will be executed when someone tries to access the computer on port 8080
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end('Hello World!');
}).listen(8080);

What's happening here? This code creates a server and says “any time we get a network request, run this callback function”. The function happens to respond with the text Hello World! So if you save this code to a .js file, run it using node name-of-file.js and navigate to http://localhost:8080/ on your browser of choice, you will see Hello World! on your screen.

Using the URL Module: Parse a url address and split it into readable parts

What would this take?

We first need to include the url module.
Then, store in a variable the address we would like to parse along with it's parsed version in a third variable.
You can see what the parsed version gives us in the 3 console.log() statements below.
Lastly, we can query through the last bits of the url to return whatever it is we are looking for.

Let's see this in action:

var url = require('url');
var adr = 'http://localhost:8080/default.htm?year=2017&month=february';
var q = url.parse(adr, true);

console.log(q.host); //returns 'localhost:8080'
console.log(q.pathname); //returns '/default.htm'
console.log(q.search); //returns '?year=2017&month=february'

var qdata = q.query; //returns an object: { year: 2017, month: 'february' }
console.log(qdata.month); //returns 'february'

Now that we know how to parse a url address and in the section before that we learned how to set up a basic webserver in Node, let's combine the two.

Serve a requested file to the client

Let's again break down what these steps would look like:

Create two html files, summer.html and winter.html
Put some basic html into both files, ensuring they both consist of different content
Within that same folder, create a .js file requiring the http, url and fs modules
Using these modules to create a server, parse through the url and open the requested file to the client. (http://localhost:8080/summer.html should render the contents of your summer.html page and http://localhost:8080/winter.html should render the contents of your winter.html page.)
Be sure to throw a 404 error if anything goes wrong

var http = require('http');
var url = require('url');
var fs = require('fs');

http.createServer(function (req, res) {
  var q = url.parse(req.url, true);
  var filename = "." + q.pathname;
  fs.readFile(filename, function(err, data) {
    if (err) {
      res.writeHead(404, {'Content-Type': 'text/html'});
      return res.end("404 Not Found");
    } 
    res.writeHead(200, {'Content-Type': 'text/html'});
    res.write(data);
    return res.end();
  });
}).listen(8080);

CRUD with Node

Now, onto creating, reading, updating and deleting files with Node.

Let's say we wanted our basic server to read from some sample file (say `demofile1.html`) and return to the client (write on the page) whatever is in `demofile1.html`:

var http = require('http');
var fs = require('fs');

http.createServer(function (req, res) {
  fs.readFile('demofile1.html', function(err, data) {
    res.writeHead(200, {'Content-Type': 'text/html'});
    res.write(data);
    return res.end();
  });
}).listen(8080);

Write a program that uses the `appendFile()` method to append 'Hello content!' to a new file named `mynewfile1.txt`.

var fs = require('fs');

fs.appendFile('mynewfile1.txt', 'Hello content!', function (err) {
  if (err) throw err;
  console.log('Saved!');
});

What is the difference between appendFile(), open(), and writeFile()?

appendFile() adds specified content to the end of a file. If the file does not exist, the file will be created.
open() takes a "flag" as the second argument, if the flag is "w" for "writing", the specified file is opened for writing. If the file does not exist, an empty file is created.
writeFile() replaces the specified file with content (if the file exists). If the file does not exist, a new file containing the specified content, will be created.

Write a program that deletes a file, say `mynewfile1.tst`

var fs = require('fs');

fs.unlink('mynewfile2.txt', function (err) {
  if (err) throw err;
  console.log('File deleted!');
});

Packages

What are packages?

NPM packages contain all the files you need for a module. Think of them as add-ons to your project to give it extra abilities or avoid having to write some functionality from scratch.

Wait - what's the difference between modules and packages?

A package is a file or directory that is described typically by a package.json file. A module is any file or directory in the node_modules directory of a project that can be loaded in by Node. Since modules are not required to have a package.json file, not all modules are packages. Only modules that have a package.json file are also packages.

How do you use an NPM package?

NPM is already installed once you install Node
Install package of your choice via npm install name-of-package
Include the package just like you would with any module: var package = require('package-name');

Events

We briefly discussed events in part 1 of this series. To refresh:

Every action on a computer is an event. It could be a network request that triggers something else or someone trying to access a port on a server.

How do we interact with events in Node, i.e. how does one create, fire and listen for events?

Include the Events module - this allows you to create, fire and listen for events: var events = require('events');
All event properties and methods are an instance of an EventEmitter object, so to access them you have to create an EventEmitter object: var eventEmitter = new events.EventEmitter();
Assign event handlers to your own events with the EventEmitter object. To fire an event, use emit()

For example, suppose I wanted a scream event to fire whenever some action occurred:

var events = require('events');
var eventEmitter = new events.EventEmitter();

//Create an event handler:
var myEventHandler = function () {
  console.log('I hear a scream!');
}

//Assign the event handler to an event:
eventEmitter.on('scream', myEventHandler);

//Fire the 'scream' event:
eventEmitter.emit('scream');

Now that we're more familiar with some of Node's powers, let's move on to the way Node is actually used in most scenarios - via a framework.

Learning NodeJS Part 2: Server Side and Dynamic Sites

Shemona Singh — Sun, 03 Jan 2021 21:33:17 +0000

A continuation of fundamentals, I'll now be diving into what Node does for websites and why we would want websites like these in the first place.

Introduction to the server side

What is the difference between client-side code and sever-side code?

Code running in the browser is known as client-side code and is primarily concerned with improving the appearance and behavior of a rendered web page. Server-side web programming involves choosing which content is returned to the browser in response to requests. The server-side code handles tasks like validating submitted data and requests, using databases to store and retrieve data and sending the correct data to the client as required. Node is a server-side web language.

💡 Servers can store and use information about clients to provide a convenient and tailored user experience.

Describe the purpose of a server.

A server is a computer that is connected directly to the internet. The computers we use regularly are called clients because they are connected indirectly to the internet via an ISP. Servers allow you to access information from databases or file storage.

What is HTTP for?

Web browsers communicate with web servers using the HyperText Transfer Protocol. When you click a link on a web page, submit a form, or run a search, an HTTP request is sent from your browser to the target server.

What does a HTTP request contain?

An HTTP request includes:

a URL identifying the affected resource
Method that defines the required action (to get, delete, or post the resource)
May include additional information encoded in URL parameters (the field-value pairs sent via a query string), as POST data (data sent by the HTTP POST method), or in associated cookies.

💡 These GET/POST/HEAD methods cost differently, some are more 'expensive' operations than others

What is an HTTP response?

Web servers wait for client request messages, process them when they arrive, and reply to the web browser with an HTTP response message. The response contains a status line indicating whether or not the request succeeded (e.g. HTTP/1.1 200 OK for success).

The body of a successful response to a request would contain the requested resource. This could be a new HTML page, an image, etc, which could then be displayed by the web browser.

What is a web framework?

Frameworks are collections of functions, objects, rules and other code constructs designed to solve common problems, speed up development, and simplify the different types of tasks faced in a particular development stream. Client-side frameworks are often used to help speed up development of client-side code, but you can also choose to write all the code by hand. In fact writing your code by hand can be quicker and more efficient if you only need a small, simple web site UI.

In contrast, you would almost never consider writing the server-side component of a web app without a framework. Implementing a vital feature like an HTTP server is really hard to do from scratch in say, Python, but Python web frameworks like Django provide one out-of-the-box, along with other very useful tools.

Checkout the section titled A few good web frameworks? to learn more about the advantages of using some of the more popular frameworks out there.

What is AJAX?

AJAX stands for Asynchronous JavaScript and XML. It is not a programming language. It's a technique for accessing web servers from a web page. It was ideated based on the principle of returning data to a web browser so that it can dynamically update its own content.

Dynamic and Static Sites

What do we mean when we categorize sites as dynamic or static?

Static sites return the same hard-coded content from the server whenever a particular resource is requested.

Pressing a button, clicking on a link will result in same style files being requested and expected behavior regardless of who is accessing this site.

Dynamic sites are ones in which some of the responding content is generated only when needed. Dynamic sites can highlight content that is more relevant based on user preferences and habits. It can also make sites easier to use by storing personal preferences and information, like reusing stored credit card details to streamline subsequent payments.

Based on a variety of conditions (being a new user, not logged in, long-time existing user) how you view this site could be drastically different. Different navigation may be available, and clicking on a button like "Show More Recommendations" will load different options for two users.

Why might you need a back-end for a project?

Perhaps the most significant benefit of server-side code is that it allows you to tailor website content for individual users.

When would you not need a back-end for a project?

If you want to build a small, static page, one that requires no information be stored from any interactions and receives the same hard coded content.

Explain some things that Node is commonly used for.

Generating dynamic page content
Creating, opening, reading, writing, deleting and closing files on the server
Collecting form data
Adding, deleting, and modifying data in your database

Onto the next section, where we'll now get to see Node in action.

Learning NodeJS Part 1: Understanding the Essentials

Shemona Singh — Sun, 03 Jan 2021 21:33:09 +0000

In order to pass the potential bumps when learning Node, it's important that some of your web fundamentals are in order. For this section and the next, I'll be revisiting key topics and tying it back to Node. Let's begin!

Understanding what Node really is

Node is an open-source, cross-platform runtime environment that allows developers to create all kinds of server-side tools and applications in JavaScript.

But that's just the textbook definition - let's break down what those words mean.

What's so groundbreaking about Node?

JavaScript was originally designed to run in the browser. This means it was impossible to run it in anything that was not a website. Node brings JS out of the browser-world, so you can accomplish with it most anything other server-side languages can do. This is what is so groundbreaking about Node. It gives JavaScript backend capabilities.

To make this happen Node must have added functionality that original JS did not have, right? Indeed, Node enables JS to have abilities like:

Create http connections
Listen to network requests
Generate dynamic page content
Create/open/read/write/delete/close files on a server
Collect form data
Add/delete/modify data in a database

The term 'V8' comes up alongside Node. What is V8?

JS runtime environments need engines to run. As we discussed, Node is a JS runtime environment so it needs an engine as well. Node's engine is built on Chrome's open source JS engine, V8. V8 is written in C++, and allows you to write your own C++ via hooks that you can make available to JavaScript.

There are other runtime engines like SpiderMonkey by Mozilla and Chakra by Microsoft.

What would “hello world” look like in Node?

Create a file (name it anything) but be sure it has the extension .js.
Put the following in it: console.log("Hello World!");
Open your node terminal, cd into the directory to the folder where the file is saved and run node [name-of-file].js.

Look familiar? Since Node is a runtime environment for JS, you can power it with the JS syntax you know and love.

Key Concepts in Understanding Node

Node is asynchronous and event-driven, let's break down these terms:

Event-driven: every action on a computer is an event. It could be a network request, someone trying to access a port on a server, clicking submit on a button - the possibilities are endless. Events trigger some response to occur, which is what Node helps us to handle.

Synchronous and asynchronous describes two different ways code can be run.

Synchronous: means each operation must complete before the next operation can start.

Asynchronous: means instead of writing code in prediction of when each line will run, you write it as a collection of smaller functions that are called in response to an event.

For example, let’s say you are writing a program and you need it to do the following: It should read some text from a file, print that text to the console, query a database for a list of users and filter the users based on their age.

This is what those steps would look like if they were to be executed synchronously:

Read File
Print File Contents
Query Database
Filter Database Query results

To make these steps execute asynchronously we would instead break up the tasks:

Read File AND THEN Print File Contents
Query Database AND THEN Filter Database Query Results

In this way, Node is not waiting around. While the file is being read, it can query the database. Then depending on which one is complete first (an event!) it will move on to the next task at hand.

This process is almost exactly like the way that you would use addEventListener in front-end JavaScript to wait for a user action such as a mouse-click or keyboard press. The main difference is that the events are going to be things such as network requests and database queries. This functionality is facilitated through the use of callbacks.

What are callbacks?

Callbacks are functions that are passed into another function as an argument:

// this has no callback
// it prints "First" then "Second"
console.log('First');
console.log('Second');

// this has a callback 
// it prints "Second" then "First"
setTimeout(function() {
   console.log('First');
   }, 3000);
console.log('Second');

If you're not careful, this can result in callback hell, which you can reduce with practices like using the async module or Promises.

What about error-first callbacks?

A common convention for Node and Express is to use error-first callbacks. In this convention, the first value in the callback functions is an error value, while subsequent arguments contain success data. This ensures if you get really in the weeds with callbacks, you can be notified when a request is being held up due to a process never going through.

Explain the event loop.

This leads me to the last large concept for this section - the event loop. You can watch this excellent video explanation on the event loop. But it's on the lengthier side, so this section will be summarizing its highlights.

The event loop is the secret behind JavaScript's asynchronous programming. JS executes all operations on a single thread, but using a few smart data structures, it gives us the illusion of multi-threading.

The job of the event loop is to watch for the stack and the task queue. If the stack is empty and the task queue is not, it will push the first item from the queue to the stack, effectively running it. The 'webapis' section is what we get from whatever our environment provides us with, in this case it's the browser providing us with the ability to keep track of the setTimeout.

Ajax requests would be treated the same way - put into the webapi section, because the code for a request does not live in the JS runtime, it lives in the browser webapi.

We have one more section after this that lays down fundamentals. Onto part 2!