What's backend development?

May 6, 2019

When I was learning backend development, I tried to find a blog post that could explain it at a very high level. Sadly, all I could find were posts that used language like:

...an in-memory data structure project implementing a distributed, in-memory key-value database with optional durability.

Seriously. With language like that, they might as well be talking about the Rockwell Retro Encabulator. I'd taught myself frontend development, but backend was a different beast. I needed to learn what I needed to learn before I could teach it to myself. I needed to learn the kinds of problems I could solve with it, and I was looking for something to point me in the right direction. Now that I understand it, I'm writing this post for people who are trying to do the same.

The purpose of backend development

Backend development is all about storing and retrieving data. That's it. Read that sentence again, because that's all you're trying to do.

Of course, you can go into making this storing and retrieving happen faster, or you can make sure you have some checks in place so people don't submit incorrect data, or you can write some code to make your data management systems more reliable, but in the end, you're just processing data.

For the majority of applications, your work will revolve around pulling data from a database, which you can think of like a big text file. Don't worry too much about the specifics of a database for now – they are much easier to work with than you think.

So what can you do with backend development?

Let's say you're building a Facebook clone. You can use frontend development to build a pretty UI that displays a news feed, notification dropdown, and media galleries for the user. But where do you get the data to populate all of this?

You use backend development to pull it from the database and pass it to the frontend. So there's one use case.

But there's more. Backend development lets you control a server – another computer. With backend development, you can make this server do whatever you want, whenever you want. You can send messages to a Slack channel when a new user signs up, or make it crawl a website every night at 1 AM.

So backend handles processing data when users are on your site, but it can also handle it when they're not there.

Most of our websites wouldn't work without backends. We need this infrastructure in place so we can log into our applications, send our reset password emails, get notified when people reply to our comments, and so on.

Now, let's dive deeper and talk about two things that caused my "eureka!" moments while I was learning backend.

Getting to "eureka!"

Understanding the following two concepts gave me my biggest breakthroughs in backend development. I am simplifying them a bit because I think it's good to understand it at a higher level before diving into the details:

The roundtrip

Have you ever wondered what happens when you visit a page on the Internet? Let's break it down with some plain-English-style code. The scenario is: a person visits your posts index on your blog. Here's what happens:

Your backend handles the routing:

when someone arrives at '/posts', run getPosts()

You run the getPosts function, which grabs the posts from the database:

function getPosts() {
  retrieve posts from database
}

And then the backend generates a response for the user (in this example, we'll send back some HTML):

<ul>
  { for each post }
    <li>{ post.title }</li>
  { end }
</ul>

Finally, it sends the response. The user receives:

<ul>
  <li>What's backend development?</li>
  <li>My visit to Leblanc Coffee & Curry</li>
  <li>What I learned from General Iroh</li>
</ul>

This is what's happening on most of the websites that you visit every day. Basically, at its simplest form, a backend retrieves data, assembles it, and passes it down to the user.

Now let's talk about how we add data to the database.

Request methods

Sometimes we want to read a blog post, but other times, we want to post a new one. Your browser helps you accomplish both of these tasks by using request methods. These are some of the most common ones:

GET retrieves a blog post so you can read it.
POST creates a new blog post with the data you send.
PUT updates a blog post with the data you send.
DELETE deletes a blog post.

You may have seen these during frontend development when you used tools like JavaScript's fetch(), axios, or jQuery. The HTML <form> tag actually makes POST requests automatically on submit. Basically, backend development is just opening the door to handle data via these methods. Here's another plain-English example:

Handle a POST request:

when someone makes a POST request to '/new-post', run createPost()

Create the post, and let the user know it was successful:

function createPost() {
  add the new post to the database
  return a success message
}

A lot of your work in backend development will revolve around consuming requests. You'll want to make sure that users can perform a GET request to read a blog post, a POST request to publish a new one, and so on.

And, it's worth mentioning — we interact with backend technologies every day! When you order something on Amazon, you submit your payment form with a POST request, it adds a field to their Orders database, and then their warehouse GETs that data and ships your package to you. Social media posts, online gaming, and banking also operate via this type of back and forth. In other words, many parts of our everyday lives rely on this tech.

Okay, so what backend framework should I use?

The dreaded question.

For context, I was a React engineer before I made the transition to backend development. I wrote a long post about my search for a backend development framework in my post Node vs. Firebase vs. Laravel vs. Rails. I ended up choosing Rails because of its ease of use. (...well, for the first few weeks, I felt like a kindergartner trying to perform rocket surgery. But it was great after that!) Ruby on Rails enables me to spin up an entire application in a weekend, which means I can create products faster. I also think Ruby, the underlying language, is pretty nice to work with.

Even though I was a React engineer, I shied away from JavaScript frameworks because they required a little too much assembly. While frameworks like RedwoodJS are growing in popularity, they have less resources for beginners, and you'll run into more edge cases that established frameworks have already solved. Rails is very much "batteries included", which can be nice when you're trying to get a project off the ground.

Still, I recommend that you try several and make your own choice. Choose something that's easy to learn, because you can always extrapolate that skillset to learn others later. Choosing any backend framework is a step in the right direction!

Conclusion

If you're a frontend developer, backend development can seem intimidating. But at the end of the day, it's just about retrieving data to display on the frontend – or opening the door to add <form> data to the database. Once you know how to do that, the rest of backend development will open up.

As with anything in software, I really encourage you to do some experimentation – you'll find that the backend is much less scary to work with than you think.