3 ways to connect your front-end web code to the back-end

This is the blog post I wished for when I was first learning to code.

I’d learned some front end JavaScript, and some back end JavaScript (NodeJS). I’d got the basics of HTML and CSS down, and I was ready to build some full-stack projects.

And then I panicked.

I knew how to do a few bits on the client-side. And some basic stuff on the server-side. But how could I connect the two?

I had no idea!

And for a few days, I searched for answers and tried to get my head around it all. And to be honest, I struggled. I felt stupid. I think I even considered giving up on coding.

If you’re struggling with the same question, here are three ways you can connect your front end to your back end (code).

1. On The Server

The first way to connect your front and back is to keep them together. If you use WordPress or Drupal, this is kind of how that works. You can have this same setup with NodeJS and other servers.

The server provides everything - front and back.

If someone visits your website, the server listens for URL requests and responds with the HTML (or CSS, or another file type) that has been requested.

The server will also have things that should never go back to the browser, like user information, secrets, admin information, and other private data.

For example, say I visit www.yourwebsite.com/user.

The server might need to check if the user is logged in, and if they are, it will grab the HTML for that page, add the user info, and respond with the file.

If the user is not logged in, the server might show a different page, or redirect to the login page.

But even if you use this method, there will probably be times you need to use the next option (API requests). For example, if a visitor signs up to your mailing list, or adds a comment.

2. API Requests

This is my favourite way to connect code from the front end to the back. It’s pretty popular because you can separate your client-side.

API stands for Application Programming Interface. Simply put, the client sends a request, and the server responds.

Your front end code no longer needs to be kept on your server. Instead, it will request information from your server (or servers). This is an API request.

Instead of your server responding with HTML pages like in the first example, it just responds with the specific information you need. This is an API response.

Now your front end code can be hosted separately.

This means your HTML, CSS, JS and images can be hosted somewhere else. Like a static hosting provider.

All of your public content is kept separate from the things that you need to keep secret, or that need to be generated depending on the user. That stays on your server.

Then your client-side code can send a request like, “Hey, server, I need this info”, and the server will respond with “Here you go, here’s the data you need!”.

Let’s say you have a blog. You need to display the same article to every user.

If your website mostly serves the same front end files to every user, it’s faster (and cheaper) to serve them as static files on a content delivery network (CDN).

I use (and love ❤️) Netlify, but there are plenty of static hosting providers to choose from.

But what if you have some dynamic content for a blog article, like the number of likes, comments, or the comments themselves.

This is when you need to make an API call.

You can display the article immediately, meaning no delay for your users to get reading what they want to know. And the client can ask the server for the information it needs.

fetch('http://www.yourdomain.com/api/comments/id')
  .then(response => response.json())
  .then(count => {
    // do something with the data
  });

In this example, the client is asking the server how many comments a post has had.

On your server, you could have an endpoint that checks for the number of comments, and returns the number.

app.get('/comments/:id', (req, res) => {
  let count = getCommentsCount(req.params.id);
  res.send(count);
});

While the browser waits for the information to be returned, you could show a loading indicator or some other placeholder.

3. Serverless

You might not even need to run a server yourself, and that’s where serverless functions come in.

This is kind of like API requests, but instead of those requests going to a URL on your server, they might go to a serverless function instead.

This could be a back end function you write and upload to AWS, Netlify Functions, or another serverless platform.

Or it could be an external service, like Firebase, or MongoDB Realm.

Static hosting providers and frameworks like NextJS have made serverless extremely popular in recent years.

Serverless functions still run on servers, but the benefit is you don’t have to set up and run the server yourself. It can be cheaper than running a server all the time if you only need to call the back end occasionally.

You're still going to use API requests to get the data you need, but the endpoints will be to serverless functions instead.