From Front to Back

It's really hard to catch up on this stuff after two weeks of really intense learning. I mean, intense - we jumped off the superfun game design canvas wagon to "Hey, this is something completely different!"

And also something I had never seen before really - none of the exercises or courses I had previously done touched the subject of the Backend at all.

Promises, async/await,  and fetch!

But of course you don't just dive into all the things. Now, in retrospect (I'm currently in Week 3 fo Module 2), this all makes a lot more sense to me, and on the other hand: it would make no sense at all to go back to a perspective of not-understanding. So here it goes.

JavaScript works asynchronosly - it never waits for stuff. There are three things that really disrupt JavaScript code:

alert()
prompt()
confirm()

And that's about it. Otherwise when you run code, JavaScript will wait for no one. You can test that by running code with a TimeOut function in it:

console.log("I'm number one!")
console.log("I'm two!")
            
setTimeout( () => {console.log("I'm three!")}, 2000)
            
console.log("I'm four!")

This will yield

I'm number one!
I'm two!
I'm four!
I'm three!

Because the code runs in a single thread and executes whatever can be next. If there is a delay - by a timeout, or because it takes a while to fetch something because we have to wait for a server's response - then that command gets put to the sidelines until a timeslot opens up. And then it gets executed by JavaScript. This is why Three comes after Four.

To get around that, you could throw every subsequent console.log into a callback of the previous console.log - but that gets nested like crazy and is hard to read (the community even calls it "callback hell", and not because it's bright in German.)

What helps here are Promises. They are objects that either resolve or get rejected, depending on their completion. The way we write it is almost prosaic - we create a

new Promise

which either rejects or resolves. If it resolves, the included .then() method gets activated, and .then() we can do this:

.then(dataWhichThisPromiseReturns => do something with this data!)

If it gets rejected (because the server is not responsive or we had a spelling mistake or whatever) we include a .catch(), which gets activated by the rejection and displays an error or something. Important to notice: both .then() and .catch() should get included in the code - the state of the Promise (resolved/rejected) knows where to go with its information. We needn't worry.

Me personally, I really liked the async/await syntactic sugar over the .then() methods - because the parentheses and brackets and arrow functions got a bit confusing to my eyes.

To resolve a Promise, this also works greatly:

async function() {
    const awaitedResponse = await fetch(url.weAreGettingSomethingFrom)
    const dataFromResponse = await awaitedResponse.json()
    
    dataFromResponse.forEach(element => do something with that data!)
}

Clean and concise, and you can already assign the content of whatever gets fetched and processed to variables for later work! Neat!

Node and Express

The next big thing is Node.js. And Express.

It's an enormous thing that doesn't strike anybody as enormous anymore because we are so used to seeing all the tech just work. But when Ryan Dahl presented Node.js in 2009, it was crazyness. Here he can be seen talking about it (in 2011) - and to be honest, from my viewpoint today I can't 100% grasp the hype. I understand completely that running JavaScript outside the browser is a big, big thing - but if you're used to Airdrop and WiFi 6 and whatnot, it seems less of a big deal.

But it is a very big deal. Running JavaScript outside the browser means running JavaScript on a computer - running it not just browser, i.e. client side. But SERVER SIDE.

I'm not gonna pretend that I can speak for the enormity of this invention, but it sure has a big impact on what I'm learning: I can stick to the same programming language to code for frontend AND backend, and that is pretty huge to me. Since those last few months were my deep immersion into coding and I don't have any background in programming or computer science whatsoever, not having to learning multiple programming languages for multiple purposes is a huge deal.

So we got started with Node - how to deploy a web server, how to run JavaScript code in the Terminal and all of that - pretty cool and useful for sure. But following the brisk pace of our bootcamp, we talked about Node briefly and got access to tons of study material, but we pretty quickly moved on - we were still on Node territory (and we will be for a while), but we took another step towards Express.js.

I can ride my bike with no Handlebars

As soon as the study material and our instructors came to us with the nomenclature of using Express on top of Node, referring to the us of a templating engine and just casually dropping the word Handlebars, I couldn't help myself but hear the 2005 song "I can ride my bike with no handlebars" by Flobot in my head (my wife introduced that song to me).

Apart from the song, Handlebars of course refers to the aforementioned templating engine for Express (next to other engines like Mustache.js or Pug), which is basically just a "machine" which manipulates HTML code from the server side. Or in other words: using {{handlebars}} syntax, I can change what is shown on websites in the browser. That alone was very impressive to me - the magic of manipulating webpages with letters and numbers was what drew me to coding in the first place.

So, Express comes with cool stuff, like setting up the whole backend with a bit more - oomph!

Instead of:

const http = require('http');

const server = http.createServer((request, response) => {
        console.log(`Someone has requested ${request.url}`);

        if (request.url === '/') {
                response.write('Hello, world!');
                response.end();
        } else if (request.url === '/about') {
                response.write('My name is ...');
                response.end();
        } else {
                response.statusCode = 404;
                response.write('404 Page');
                response.end();
        }
});

we can write

const express = require('express');
const hbs = require('hbs');

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

app.set('view engine', 'hbs');
app.set('views', path.join(__dirname, 'views'));
app.use(express.static(path.join(__dirname, 'public')));

app.get('/', (req, res, next) => res.render('index'));
app.get('/about', (req, res, next) => {
    
    const dataObject = {
    
     array : [
        { keyOne : valueOne },
        {keyTwo : valueTwo }
        ]
        
    }
    
    res.render('about', dataObject));

Which in English means: instead of creating a http server and attaching some conditions for a potential URL, we .require() a bunch of stuff from Node (like express or hbs - handlebars) and make it more distinct.

Handlebar syntax comes with pretty cool stuff. Aside from the slightly intimidating {{ }} curly bracket chaos (a reason why I prefer async/await over .then() ), it brings us views - the .hbs files that allow us to manipulate HTML. Inside them we can write basic HTML - everything that works in HTML works in an .hbs file. But in addition it comes with helpers, like a tool to loop over arrays and apply HTML tags to the content with {{#each}}; or we can include conditional statements!

Since we can send objects to the rendered page as well (see in the example the dataObject that gets included in the res.render() for the about page), we can work with those objects. the each-helper can only iterate over an array if we send it an array - via the dataObject! We can also include an if-helper - only {{#if}} a certain dataObject is there a certain HTML syntax will be rendered. If that object turns out to be null, or an empty array - nothing is shown. Of course there are a ton of useful things that come with templating engines - the internet is full of resources for them!

So, this is by NO MEANS everthing. Not even close. But it is what I learned in the span of a week, and it's not that you learn it, use it and leave it by the wayside. I'm using this stuff every day, or have until this point. It's dead-useful and there is so much magic in those words, I can't wait to dive into the deeper depths. But other diving has to be done for now, according to schedule.

jmc

In this series of blog post I write about my experience at Ironhack bootcamp. The material is available to anybody and free to use on the internet - I do not work for Ironhack (I paid to participate in a bootcamp, so...). These posts are not supposed to be deep-dive anything, just reflect what I learned about various programming techniques. If anybody finds them while googling, cool. If anybody finds them helpful, even cooler! If nothing happens - also fine.