What is backend development?

May 06, 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.1

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, 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. I falsely believed that databases required you to learn algorithms and sharding and new languages, but they’re really simple and beautifully designed for beginners to work with.

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?

Obviously, you use your backend development skills 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 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.

Backend development concepts

Understanding the following two concepts gave me my biggest breakthroughs in backend development:

The roundtrip

Have you ever wondered how the Internet works? 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 HTML from our ‘/posts’ template:

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

Then it sends the finished HTML to the user.

  <li>Backend development for frontend developers</li>
  <li>My mechanical keyboard review</li>
  <li>What I learned from General Iroh</li>

This is what’s happening on most of the websites that you visit every day. Basically, backends retrieve data, assemble it, and send 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 redirect the user to the post index:

function createPost() {
  create the new post
  redirect the user to example.com/posts

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.

These concepts control the modern world. 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. It all relies on backend development.

Okay, so what backend framework should I use?

For context, I was a React engineer before I made the transition to backend development. I was also self-taught, to give you some context.

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 it was extremely easy to build with.2 Ruby on Rails enables me to spin up an entire application in a weekend, which means I can create products faster. I also love the beauty of its underlying language, Ruby – it’s like poetry.

Even though I was a React engineer, I shied away from JavaScript frameworks because they required a little too much assembly. Rails was very much “batteries included,” which I preferred as a beginner. Now that I know Rails, I feel that I’d have a much easier time learning a different framework.

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.

How can I teach myself backend development?

Everyone learns in different ways. Reading books feels like a slog to me, so my favorite way to learn is by building things – I’ll choose something simple (like a blog) and try to build it. For instance, this is what I did to learn Ruby on Rails:

  1. To practice, I decided I would build a simple blog. It would have a homepage that listed all the posts, and you could click on a post to read it. Blog posts would have titles and bodies – nothing else.
  2. I found and followed a short YouTube video on how to build a blog with Rails.
  3. Then, I tried to do it again without following the video.
  4. I decided I wanted to add user accounts. I searched for a blog post on how to add user accounts to Rails, and I followed it.
  5. Then, I tried to create a blog with user accounts from scratch.
  6. Once that was done, I decided that I wanted to learn a little more, but “I didn’t know what I didn’t know.” I found a popular Rails book (the Hartl one) and skimmed the first few chapters until I got bored.
  7. I kept building things that sounded fun, until eventually, I got good at Rails.

I didn’t do this in one sitting – it happened over the course of a few days.

I like to think of this as “previewing” a language. Worst case scenario, I spend a few days learning a language that I won’t use – but I still learn new things in the process. Best case scenario, I learn something that I love to use, and it helps me build awesome things. It’s a lopsided bet that’s heavily weighted towards the this-will-be-a-good-decision camp.


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.

And if you choose a backend framework that’s easy to learn, you can always extrapolate your skillset to learn others. Do some experimentation – you’ll find that the backend is much less scary to work with than you think.

  1. This might as well be the Rockwell Retro Encabulator↩︎

  2. …well, for the first few weeks, I felt like a kindergartner trying to perform rocket surgery. But it was great after that! ↩︎