DEV Community: Jay Koontz

Senior Software Eng (web) looking to take on apprentice

Jay Koontz — Wed, 29 Sep 2021 20:03:51 +0000

Hi everyone. This isn't the first time I've opened the doors to taking on an apprentice, and I find it to be the most rewarding part of my career. Watching one-by-one as my students got their first job was one of the most thrilling things to see happen in both their lives and mine, and after really figuring out what it takes to get someone job-ready from nothing, I know exactly how to get you there as well.

In my opinion, everything you need to get a job is out there on the internet. That doesn't make it easy to become a web developer, though. It's just the start.

Programming is famously difficult to learn. I partly blame how our education system forces us into this "oh no, I'm wrong!" mentality, and that there's some magic "right answer" out there that only "smart" people know and that's why only "smart" people "get it" and you don't.

That mentality helps no one. Truth is, though, it's difficult to learn even with the right mentality. It's death-by-a-thousand-choices out there when it comes to learning anything. It's also a lot of uncertainty. How do you know if you're doing anything right, or even useful?

Well I've seen a pizza boy with no college degree grow into a competent developer with a job by sheer force of will and a light touch of guidance, and I can show you how to do the exact same thing.

To do this, I'm going to host a small group video chat and Q&A session. Everyone from any background and a desire to get a job in programming is welcome to attend.

You'll walk away from it knowing exactly what you need to do next to get closer to a job as a web developer. For some of you, that might mean joining my apprenticeship group (and I'll tell you what the group is like during the call). For others, it might mean joining my discord group where we work on small projects to nail the foundations of HTML, CSS, and JS in preparation for professional web app development.

If you want to join, just reach out to me on either Discord at jk#8880, LinkedIn, or Reddit with your current history with learning programming and any questions you'd want answered during the group video call. I'll record it, so don't worry if you can't make it.

I hope to bring to you my full experience of getting people their first job in this field. If that's what you're looking for, I'm excited to take you there myself.

How to turn any design into HTML & CSS

Jay Koontz — Tue, 28 Sep 2021 19:48:52 +0000

Online courses hide the most important part of web dev: what to do when it’s just you, an idea, and your IDE. Todo-list-sized projects are fine, but anything more complicated? It can be overwhelming.

One of the surprisingly hardest parts is HTML. Not the syntax of it, but how to effectively create a UI for your idea.

I learned a technique early on that will take a design and turn it into a near-perfect HTML skeleton for your app.

Pen and paper to the rescue

The approach is very visual. I use pen and paper in real life, but use an iPad here to record the screen:

How can we use this approach for our own apps when we don't have a design?

Feel free to reach out to me if you get stuck on this part.

To come up with a prototype design, list out the features you want for your app. Then, scratch out a design with pen and paper until all the features are covered by your prototype.

Once you have it down, use the same method shown in the video to come up with the HTML skeleton.

...but it doesn't look pretty?

Steal the aesthetics! Don’t use it for commercial gain, but find a design you like and just borrow it. Discord has a nice dark-theme design, AirBnB makes great use of white space for a professional feel, search Dribbble for user-submitted design inspiration, Bootstrap released some nice themes, and maybe even look into Tailwind.

Aesthetic can be a big draw, but the most important part when building out practice projects is nailing the functionality. Design skills slowly seep in over time. Thankfully, design ain't our job anyways!

Which projects to build to get a web development job

Jay Koontz — Thu, 09 Sep 2021 14:47:17 +0000

Employers want to see that you’ve been-there, done-that with web development. However, most people dive into this journey by having their hand held through an online course.

When it comes time to actually create something of their own, their head draws a blank, their keyboard stay silent, and they begin to wonder what those courses even taught.

I’m going to show you which projects will not only get you a job, but teach you how to do web development in the first place.

Why listen to me?

I had to claw my way into this field. I didn't have a computer science degree, so instead of getting interviews the easy way, I built projects to show I had what it takes. These projects took me to Silicon Valley and San Francisco's tech scene, starting from very little and eventually reaching Senior.

Since that time, I’ve mentored people into getting their first job in web development using the exact same path I took. The ones who made it did so while holding down full-time jobs or whose background topped out at "pizza delivery driver".

I had them build projects that got them interviews. Not a degree, not some certificate from LinkedIn, and not even a fancy portfolio website. Just building projects.

So which projects get you the job?

That’s a trick question. If you’re asking it, I need to walk you through a mindset shift: projects are the main way you should be learning. It’s not just about showing off your skills, it’s also about building your skills up in the first place.

Think of things this way: the projects you take on should guide you through the learning process.

Your first project or two won’t be some super impressive AirBnB clone or fully-featured social network. They will, however, teach you the fundamentals necessary to build such projects.

Once built, you move on to the harder projects.

Here’s a better question to ask:

What kind of projects turn you into a web developer?

Much better. For this, we start small and work our way up.

Once you’re familiar with (not an expert in!) HTML, CSS, and JavaScript, you need a project that covers following:

Building a UI that will call an API
Building a server to provide an API for this UI
Building a database for your server
Deploying it all on Heroku or AWS

That’s it for your first project. Then:

Repeat the process with a frontend framework
Repeat again, but with user authentication
Repeat again, but for real-world usage through friends or freelancing

No one is ever fully “ready” for building a project when starting out. You're going to hit a number of walls. Thing is, if you don't hit a wall at least a few times a day, you're playing it too safe.

Venture out, Google what you don't know, and don't judge your coding abilities until you've actually built a few projects.

Once you’ve worked all the way up to building a real-world app with authentication on a tech stack that companies hire for, you’ve proven to the world that you’re a web developer. Employers will interview you with the right 4 projects under your belt. The plan is simple, but the process is hard.

So where do I learn how to do this?

I mean it: dive right into making a project. Now. Get confused along the way? Google, Google, Google.

These resources are helpful as well:

The Odin Project has a wonderful foundations overview if JavaScript, HTML, or CSS syntax is an issue.
Udemy has courses on sale for ~$14, find the highest-rated ones that cover your current needs. Use Google to fill in the holes.
YouTube has highly-rated, highly-watched videos that cover building servers or databases or whatever you’re stuck on. Just be sure to only take them because you’ve hit a wall while coding your project.
If you're stuck on syntax, javascript.info typically has a thorough explanation for you
Seriously, Google. 7 years in and Google is my most-used tool

Heads up: there’s no one way to write code either, so code until it works. You’ll learn how to clean things up later.

Don't want to do this alone?

I’ve set up a free Discord group for this process. I take my members through a series of challenges that guides you through each of these topics. I also live stream weekly Q&A sessions on Twitch to help along the way. Join the Discord here to get started

Have any questions about becoming a developer? Really, what else is there to know? Jump into building a project. Hop on that live stream if you have deeper questions.

But wait, what are some good project ideas?

The important part here is covering the topics lightly at first and more thoroughly the next time around. Here are some examples:

1st project:

Go through each of these challenges to build a UI from scratch, build a server, and connect it to a database
Try out a simple, non-realtime chat app with anonymous users (as in, no login)

2nd project:

Rebuild the UI for the prior project in React
Build an app that can store and search through your favorite movies, restaurants, or music

3rd project:

Create a message board with user login
AirBnB for X. Get silly, like AirBnB for yachts or space ships or puppies. Focus as much energy on the user experience for uploading space ships as you do searching for space ships.

4th project:

Message board for your friends
Trip planner for groups (and plan a real trip with it!)
Have a job? Find out if you can build a project to help your team.

Your real-world project will set you apart from others in your job search. It’ll also be your hardest project. The real world is difficult.

Building projects is difficult in general--you don’t have to do it alone. Find a group or reach out if you need some help. Good luck!

Learn how web apps work by building one in lightning speed

Jay Koontz — Thu, 02 Sep 2021 17:36:02 +0000

There’s a lot to be gained by deeply studying javascript syntax, how HTML & CSS works, etc, but at the end of the day--we’re here to build. You might not need as much JavaScript as you think to hit the ground running. In fact, you can learn as you go along, just like developers do in the real world.

We’re going to go all-out here and build a simple non-realtime chat app in native JavaScript with a REST API for the backend using Express.js. We’ll even build a quick database for it in PostgreSQL. By the end of this, you’ll see how everything comes together. You might not understand it perfectly, but that’s okay. Instead of getting stuck in tutorial hell, you’re going to use what you don’t understand to fuel your studies.

We’re not here to build a beautiful UI, or even a beautiful codebase. Just a simple UI and a quick backend to show off the concepts.

At the very end, I’ll tie in what you’ve done to how webapp development works in the real world.

I recommend using VS Code to browse and edit the codebase.

Warning: you’re about to be thrown in the deep end.

Don’t give up! In fact, move on if you’ve hit too big of a wall. But also, if you haven’t even touched HTML or JavaScript yet, check out The Odin Project’s foundations course.

How quickly can we build a server?

Very. Building the foundation for a server is usually done once, so we have some tools that can generate a good one for us. My personal favorite is provided by the Express team itself: https://expressjs.com/en/starter/generator.html.

Create a folder for your project, open your terminal or command line to it, and run the following:

npx express-generator --no-view

Type in y if prompted to install.

Then, run npm i to install the packages that allow the server to run.

The terminal will tell you the command to run the app. Copy/paste it to run the server.
Should look something like this: DEBUG=your-project:* npm start

That’s it. Does it say Listening on port 3000? Whatever port it’s listening on, visit your browser at localhost:3000 (or your specific port).

Do you see the page? Welcome to Express!

But what’s going on inside? Where did that page come from?

Check your app.js file in VS Code. There’s a line that looks like this, go ahead and find it:

app.use(express.static(path.join(__dirname, 'public')));

This makes Express serve the /public folder in your codebase. You could’ve named it anything so long as it matched with a real directory in your codebase.

/public contains the HTML, CSS, and (soon!) the JavaScript for your app.

Go ahead and check out /public/index.html. It’s fairly straightforward:

<html>
    <head>
         <title>Express</title>
         <link rel="stylesheet" href="/stylesheets/style.css">
    </head>
    <body>
         <h1>Express</h1>
         <p>Welcome to Express</p>
    </body>
</html>

That’s where the page came from. This index.html file is the basis of your UI. You can change it into whatever you want.

Let’s turn it into a chat app!

Building a form that submits chats to the server

Keep it simple--we’re going fast here! We’ll use id’s so JS has something to work with:

<form id="chatbox">
   <label>Message
       <input type="text" id="message"/>
   </label>
   <button type="submit">Send</button>
</form>

So how can JS work with it? Create an index.js file in the /javascripts folder and put the following code in it--annotated in case you need to dive more deeply into the syntax:

function setEventListeners() {
 document
   // querySelector uses CSS selectors to get elements. # is for ID's
   .querySelector("#chatbox")
   // #chatbox is a form, we listen to its "submit" event here
   // Google "addEventListener js" if you'd like to learn more
   .addEventListener("submit", function (event) {
     event.preventDefault(); // keeps the page from refreshing

     // "value" is a property all inputs have in a form. for "text" inputs, it's the text
     const message = document.querySelector("#message").value;

     // learn about fetch() here: https://javascript.info/fetch
     fetch("/chats", {  // we'll have to create a /chats route in the server
       headers: new Headers({'content-type': 'application/json'}), // important!! we want to send things as JSON
       method: "post", // Google 'HTTP verbs' for more, you'll see it in the server
       body: JSON.stringify({ message }), // turns the JSON into a string for the server to parse
     })
       // fetch creates a promise. We chain .then after it for when the fetch is finished
       // Google "promises js" to learn more
       .then(function () {
         // clear it after using that same value property!
         document.querySelector("#message").value = "";
       });
   });
}

// the HTML needs to load before we can grab any element by ID!
// this will call the setEventListeners function above when DOMContentLoaded occurs
document.addEventListener("DOMContentLoaded", setEventListeners);

If anything in that JS file doesn’t make sense after reading the comments, Google it or use javascript.info to learn more.

We can’t forget to include this script in our index.html file.
Here’s how your <head> section in index.html should look for this to work:

<head>
    <title>Express</title>
    <link rel="stylesheet" href="/stylesheets/style.css">
    <script src="javascripts/index.js"></script>
</head>

What do we do with the server?

We need a way to receive POST requests at the /chats route to match with our fetch call. The body will have a JSON object { message: ‘this is the chat’ }, so we need to take that message and store it. Ideally, we want to do this inside 15 minutes. We’re just storing a message! Nothing fancy at all.

Real quick--what’s a route?

Routes handle the GETs, POSTs, and basically any incoming communication to the server.
Take a look at that /routes folder. We’ve been given index.js and users.js, but if we check out the route in users.js...it’s not that different from index.js:

/routes/users.js

/* GET users listing. */
router.get('/', function(req, res, next) {
 res.send('respond with a resource');
});

/routes/index.js

/* GET home page. */
router.get('/', function(req, res, next) {
 res.render('index', { title: 'Express' });
});

Ignore the res.render vs res.send. We see router.get(‘/’ …) for both of them. Wouldn’t they route to the same thing? Shouldn’t the Users route at least say ‘/users’?

Check out how these routes are actually hooked up to the server in /app.js:

var indexRouter = require('./routes/index');
var usersRouter = require('./routes/users');

.
.
.

app.use('/', indexRouter);
app.use('/users', usersRouter);

There we go. They’re imported using require and then app.use sets the root path for the route. usersRouter gets ‘/users’, and so any fetch made to the ‘/users’ path goes through it.

Our server needs a ‘/chats’ route, so let’s set that up.

Route setup

First, we need a /routes/chats.js route file. Add that under the routes folder and add this to it:

var express = require("express");
var router = express.Router();

router.post("/", function (req, res, next) {
 // destructuring used here, it's the same as req.body.message
 // Google the concept, it's convenient!
 const { message } = req.body;
 console.log(message);
 res.sendStatus(200);
});

module.exports = router;

Router.post? Yep. I’ll explain POST vs GET in more depth soon. In the meantime, notice how our fetch call in the index.js file used a “post” method. These must match for the server to know what to do.

Once the route is reached, we grab the message from the request body using destructuring (check out javascript.info for more on destructuring).

res.sendStatus(200) will send an HTTP 200 status code back to our original fetch request once it’s complete. That means everything turned out fine. You may have heard of the “404” error by now--it means a resource wasn’t found. There are other errors like 500--which means the server is broken. Status messages help the client know whether a request failed, worked just fine, didn’t exist, and more.

But wait, the route isn’t ready to use yet!

Let's hook up this route first. In app.js, import this file the same way we imported the other routes. I’ll add it to that area so you see what I mean:

var indexRouter = require('./routes/index');
var usersRouter = require('./routes/users');
var chatsRouter = require('./routes/chats');
.
.
.
app.use('/', indexRouter);
app.use('/users', usersRouter);
app.use('/chats', chatsRouter);

Now we can use that form and see that the route works. Refresh your server (turn it off and then on again with ctrl+c and then the start command!) and send a message.

You should see this on the terminal:

[the chat message you sent]
POST /chats 200 3.424 ms - 2

See that 200? Same status that we sent. If the message shows up too, you’re all set. Great work. We’ll send something back to the client once we’ve stored data in our database.

So how do we store this message?

Setting up a PostgreSQL database isn’t that much work, and it’s one of those things that takes no prior knowledge to do. The hardest part is usually trying to remember your admin account’s username and password, so write it down somewhere--it’s just for personal use anyways.

A little bit of context to help:
The server connects to the database. It doesn’t run the database itself. We’re setting up something that runs entirely outside of Express.

Install PostgreSQL here: https://www.postgresql.org/download/

It will come with a program called pgAdmin, which provides a UI to manage your databases. It’s very handy, so open it up once it’s all ready.

You’ll need to create a database using the UI. Here’s a screenshot of what to click on:

Give the database a useful name like “chat-app” and hit save:

And boom--your first database. Not so bad, right?

Now let’s hook it up to our Express app.

Sequelize and storing our database password somewhere safe

First off, Express needs credentials to connect to the database. We don’t want those to go public, so we put them in their own file and ensure that file never leaves our computer.

At the root of your server folder, add a .env file. That’s right, just the extension .env. It’s short for environment, and it’s where we set our environment variables. Database credentials are perfect for this.

Add the following lines to the .env file:

DATABASE=chat-app
DATABASE_USER=[your username, probably postgres]
DATABASE_PASSWORD=[the password you used for the admin account]

Now we need to install a few packages for Express to work with our .env file and our database.

Connect to Postgres with Sequelize

We need to install a few packages that help us use our .env file and connect to the database. Run npm i --save dotenv sequelize pg

Once installed, we’re ready to hook up the database to our Express app. This part isn’t hard from a syntax perspective--it’s just hard to know why we’re doing it and where to put things.

We have this library called Sequelize that acts as a middleman between Express and our Postgres database. With it, we can connect to the database, create tables, insert and edit data, etc., all with JavaScript syntax.

I’ll walk you through the setup.

At the root of your project, create a /models folder and add a db.js file to it. This file will be used to initialize a Sequelize object that can connect to our database. Here’s the contents:

var Sequelize = require('sequelize')

const sequelize = new Sequelize(
   process.env.DATABASE,
   process.env.DATABASE_USER,
   process.env.DATABASE_PASSWORD,
   {
       dialect: 'postgres',
   }
)

module.exports = { sequelize, Sequelize }

Now for some fancy configuration. Go to your /bin/www file. It’s a weird one, but we need to instantiate our env variables and connect to the database here.

Add the dotenv and db import lines here above the app declaration:

/**
* Module dependencies.
*/
var dotenv = require('dotenv')
dotenv.config()

var db = require('../models/db')
var app = require('../app');

In that same file, we need to use our db import to sync the database before starting our server!
So find the lines in /bin/www that look like this:

/**
* Listen on provided port, on all network interfaces.
*/

server.listen(port);
server.on('error', onError);
server.on('listening', onListening);

And wrap them like so:
db.sequelize.sync().then(() => {
 server.listen(port);
 server.on("error", onError);
 server.on("listening", onListening);
});

Okay, can we store chats after all the weird configuration?
Not yet! We actually need a chat model for Sequelize to use. The good news is that we’re basically done with DB setup! And, this model will be super simple. Let’s code it and hook it up to our Sequelize instance.

Creating a Sequelize model

Add a file called ‘chat-model.js’ to the /models folder.
We’re going to define our model in it with just a message:

exports.ChatModel = (sequelize, DataTypes) => {
   const Chat = sequelize.define(
       "chat",
       {
           message: {
               type: DataTypes.STRING,
               field: "message"
           }
       }
   )

   return Chat
}

I highly recommend reading the docs for Sequelize to familiarize yourself with this code: https://sequelize.org/v5/manual/getting-started.html. Don’t worry if it doesn’t all make sense at first. It may take a few readings for the concepts to sink in.

Hooking up our Chat model to our Database

We need to go back to our db.js file, import our Chat model, instantiate it, and export it.

In the end, db.js will look like this:

var Sequelize = require('sequelize')
var ChatModel = require('./chat-model').ChatModel

const sequelize = new Sequelize(
   process.env.DATABASE,
   process.env.DATABASE_USER,
   process.env.DATABASE_PASSWORD,
   {
       dialect: 'postgres',
   }
)

const Chat = ChatModel(sequelize, Sequelize)

module.exports = { sequelize, Sequelize, Chat }

Let’s save those chat messages!

Go right back to your /routes/chats.js file. We’re going to use this Chat export to save our messages.

First, we need to import it with require. Add this line at the top:

var Chat = require('../models/db').Chat

We’re going to add a line that uses Chat to create that message as a row in our chat database:

router.post("/", function (req, res, next) {
 // destructuring used here, it's the same as req.body.message
 // Google the concept, it's convenient!
 const { message } = req.body;
 Chat.create({
     message
 })
 res.sendStatus(200);
});

See Chat.create()? That’s all it takes! Make sure it’s added as an object. The syntax sugar .create({ message }) is the same as writing .create({ message: message }). See this article from javascript.info to learn more.

Ready for the magic?

Alright, reset your server. If you did the setup right, there may have been some extra logs on your terminal during the starting phase. If there was an error instead, read it--it’s very likely related to one of the steps above.

If all is well, send a message through your UI! It will save in the newly-created database table.

You can check by opening pgAdmin, clicking into chat-app, clicking into Schemas -> public -> Tables, and right clicking on the ‘chats’ table. Select View/Edit Data -> All Rows:

Did you see your message come up? Incredible, right? Sequelize also added an id, createdAt and updatedAt column for you and populated it on its own. Very convenient.

Finally, get and display all the chats

This last step makes use of everything we’ve learned so far. We’re going to grab all the chats from the database and display them in our chat app both on load and after everytime we send a chat. You might have noticed that this is not sufficient for a real-time chat app, and you’re right. It’s not. But websockets are super advanced, so we’ll just have to refresh the page or send a message to see any new ones.

Create a route that grabs all the messages

Sequelize has some handy query methods to make this easy for us. Read more about them here if you’d like: https://sequelize.org/v5/manual/getting-started.html#querying
We’re going to use Chat.findAll() for our needs.

Add this route to /routes/chats.js:

router.get('/', async function(req,res,next) {
   const chats = await Chat.findAll()
   res.json({messages: chats})
})

Note the async/await syntax! It’s clean and allows Chat.findAll() to finish before program execution continues. Learn more about it here: https://javascript.info/async-await

Get the data and display it in the UI

We’re here. One last hard part. We need to both call this route from the UI using fetch and dynamically render the results. ..how do we do that?

All in the JavaScript! Open the /public/javascripts/index.js file. We’re going to create a couple functions to make this happen for us.

The first one will use fetch to grab the data from the server.
The next will render the messages.

The syntax is a little funky for grabbing the messages, check it out:

async function getMessages() {
   const fetchResponse = await fetch('/chats', { method: 'get' })
   const response = await fetchResponse.json()
   return response.messages
}

It’s asynchronous, it uses fetch, and looks clean. The hardest part is remembering to call response.json() like we do above, followed by grabbing what we want off the response. You may think the response is just the messages, but it isn’t! There’s extra data in a response, check it out by using console.log on the response.

Alright, so what’s the function to render it?

Well first, let’s add a <ul> to our /public/index.html file with an ID so we can access it easily:

 <ul id="messages"></ul>

I put it right below the form. Put it wherever you like.

Now let’s return to index.js and create a function that renders the messages in that <ul> element:

function renderMessages(messages) {
   const root = document.querySelector("#messages")

   const listItems = messages.map(messageObject => {
       return `<li>${messageObject.message}</li>`
   }).join('')

   root.innerHTML=listItems
}

We used map to loop through all the messages and template literals to cleanly insert the message into the <li> tag. Map returns an array, so we use .join(‘’) to create a single string from the array. Then, we set the innerHTML of the <ul> to the string we created.

If that sounded Greek to you, I did that on purpose so you would read up on all these topics here:

Using these functions on init and message send

We’ve got all we need, but now we need to do more on initialization than just set some event listeners. For a project of this size, we can store all the necessary steps in an init() function like so:

async function init() {
   setEventListeners()
   const messages = await getMessages()
   renderMessages(messages)
}
// the HTML needs to load before we can grab any element by ID!
// this will call the setEventListeners function above when DOMContentLoaded occurs
document.addEventListener("DOMContentLoaded", init);

Be sure to update the DOMContentLoaded listener to call init instead!

So what should we do on message send? We actually want to grab all the messages from the server and display them. That might sound inefficient, but for this app, we’ll be completely fine.

Remember where we cleared the value of the message input? Turn that function async by adding async before function() and then add the same await getMessages() and renderMessages lines here:

.then(async function () {
  // clear it after using that same value property!
  document.querySelector("#message").value = "";

  const messages = await getMessages();
  renderMessages(messages);
});

The final index.js source

I know it’s hard to follow along and find out where to put all that code. Here’s my final output:

function setEventListeners() {
 document
   // querySelector uses CSS selectors to get elements. # is for ID's
   .querySelector("#chatbox")
   // #chatbox is a form, which has the "submit" listener for when that button is pressed
   // Google "addEventListener js" if you'd like to learn more
   .addEventListener("submit", function (event) {
     event.preventDefault(); // keeps the page from refreshing!

     // "value" is a property all inputs have in a form. for "text" inputs, it's the text
     const message = document.querySelector("#message").value;

     // fetch is a nice upgrade from XMLHTTPRequest. but..what's this /chat route?
     fetch("/chats", {
       // we'll have to create the /chats route before our server knows what to do with this
       method: "post", // Google this!
       headers: new Headers({ "content-type": "application/json" }), // important!! we want to send things as JSON
       body: JSON.stringify({ message }), // turns the JSON into a string for the server to parse
     })
       // fetch creates a promise. We chain .then after it for when the fetch is finished
       // Google "promises js" to learn more
       .then(async function () {
         // clear it after using that same value property!
         document.querySelector("#message").value = "";

         const messages = await getMessages();
         renderMessages(messages);
       });
   });
}

async function getMessages() {
 const fetchResponse = await fetch("/chats", { method: "get" });
 const response = await fetchResponse.json();
 return response.messages;
}

function renderMessages(messages) {
 const root = document.querySelector("#messages");

 const listItems = messages
   .map((message) => {
     return `<li>${message.message}</li>`;
   })
   .join("");

 root.innerHTML = listItems;
}

async function init() {
 setEventListeners();
 const messages = await getMessages();
 renderMessages(messages);
}
// the HTML needs to load before we can grab any element by ID!
// this will call the setEventListeners function above when DOMContentLoaded occurs
document.addEventListener("DOMContentLoaded", init);

You did it!!

That’s a full client/server web app you’ve created! Is the UI pretty? No. Is it the best coding architecture? It’s not. But it works, and you can build off what you’ve learned here to create bigger projects.

...wait, what did I do?

Now that you’ve set up a client and server, let’s fill in the holes.

How client/server architectures work
How HTTP lets use communicate between our UI and our server
How Databases work
“I felt so lost reading this” and why that’s not because you’re dumb
What’s next?

How client/server architectures work & different ways of hosting HTML

The relationship we set up looks like this:
[client <-> server <-> database]
It’s not the only way to do things. We created a Single Page App.

Another way to get around it is to not have the server serve the static assets at all and use something else to serve your HTML.

The server allowed for index.html to be accessed at the root level, localhost:3000.

How HTTP lets use communicate between our UI and our server

It’s in the name: Hyper Text Transfer Protocol. HTTP is just text. It’s used to hold so many things, but it’s all text. Servers and browsers standardized what this text says to make it useful for communicating to each other.

Open up Chrome’s Dev Tools (cmd + option + i for Mac and Shift + CTRL + J for Windows)
Check out the Network tab and refresh the page. You’ll see all the requests made. Clicking into these requests show a whole world of information: header info, payloads & their sizes, server paths, and even diagnostic info like how long a request took.

If you visit localhost:3000/chats, you’ll actually see the JSON response for all the chats you can grab when doing a GET call to /chats. So what’s GET? It’s an HTTP verb.

The browser sends a GET request to that URL every time you use it to visit or refresh a page. We sent one directly with fetch, and the same server route is reached when a browser visits a URL. Browsers send GET requests to any URL you want, it’s how the web works.

There are other HTTP verbs we can use:
POST, generally used to “create” resources on the server
PUT, generally used to update a resource by providing the entire object to replace it with
PATCH, generally used to update a resource by providing the parts of the resource to update
DELETE, generally used to delete resources

GET requests have one major difference with POST aside from its responsibility:
With POST requests, you generally provide the resource in the body as an object, like we did above.
With GET requests, if you need to provide extra variables, you do so in the URL itself. You may have seen URLs like “https://localhost:3000/chats?key=val

These resources dive deeper into this subject:

How databases work

The sheer number of databases you could use would make your head spin. There isn’t a single answer to which database to use for your app, and there are more options every year.

The classics you’ll hear the most about at the beginner level are PostgreSQL, MySQL, and MongoDB. Stick to these and you’ll be fine.

Postgres and MySQL are relational databases which use SQL to interact with, add to, and edit your stored data. MongoDB falls under “NoSQL” and has its own syntax for database interaction.

No matter how much flack any one database gets, they’ve all been used to start and run highly successful companies. MongoDB can be a bit quicker to get started with, but you get a bit more respect from the developer community for understanding SQL, the language used to interact with Postgres, MySQL, and other relational databases. Learn more about these topics here:
Youtube, etc

“I felt so lost reading this” and why that’s not because you’re dumb

You’re looking at how much you know right now and feel like you’re coming up short. Lots of people do this. Everyone’s confidence, absolutely everyone’s, is humbled by how difficult this field is. Here’s the thing: if you judge yourself on how much you know, you’ll always fall short. Instead, judge yourself on being able to figure things out.

The unknowns never end. After 7 years in this field, I use Google constantly. Everyone does. It’s the real skill to learn.

See a topic you want more info on? YouTube it. Google around. Find a relevant online course through Udemy. StackOverflow likely has answers.

This project is meant to throw you in the deep end. I bet if you did it a 2nd time, it’d go a bit smoother. Do it a 3rd time, and you could probably add to it with ease.

Learning never stops in this profession. Ever. The beginning of any project is typically research-oriented. I had to have a small refresher myself to make sure I was using fetch correctly. The concepts will come up again and again, but the concept that reigns supreme is how to find things out with the right Google search query.

What’s next?

It’s time to dive deeper into each of these topics: building a UI, building a server, modeling data for your database. Your knowledge of syntax will solidify along the way.