Some people think that because all the information to learn — literally — anything is online and accessible, anyone can learn anything. However, that couldn't be further from the truth. People learn in different ways and through different processes. Some need examples to understand how things work while others need the full theory before they move a finger. Take me for instance, I'm a big visual learner and I need examples to tinker with.
In the case of software development, sometimes a very good resource for someone looking to get started with a new career path is to go through a set of increasingly difficult challenges. Sort of like a path, if you will.
So here is how I would tackle getting into the back-end if I were starting from scratch today.
Start with a CLI application
The objective of your first application is not to be this huge project that takes you 6 months to finish and is something everyone would give their right thumb for a chance of using it. No, quite the opposite actually. Your first project should be something simple that'll show you how to set up a project with the language/framework of choice and then how to add some basic logic inside it.
That is why I think a CLI app would be a perfect first back-end project, you don't have to worry about new concepts such as HTTP, or requests and responses, or sockets for that matter, all you have to worry about is printing something into the terminal window and most likely finding a way to read command line parameters (you know, those that come after the command, like mkdir foldername , the “foldername” part is the command line parameter you'd have to read).
The point of this project is to get familiar with the technology without letting the actual project get in the way of you understanding the concepts around it. For example, assuming you've never done back-end before and you jump blindly into building a REST API with Node.js, you'll be learning Node, yes, but you'll also spend quite a lot of time researching about APIs and probably REST before you feel comfortable enough to write your first line of code.
Don't overthink it, just make sure your app mimics your favorite terminal command like ls (or dir if your a Window native), or maybe mkdir or touch . Those are all simple commands that will challenge you without making everything difficult.
Once you have your basic CLI application ready, it's time to move on to the next challenge: a microservice.
Build a basic API as your second project
Once you've mastered the CLI project, I'm assuming you're comfortable enough with the language so now it's time to learn some basic back-end concepts: microservices, the bread and butter of any back-end developer.
I would split this project into two:
-
First I would try to create an API that handles the basic CRUD operations (I'm talking about Create, Read, Update and Destroy) coupled with Listing as well. But without worrying about a database for the time being. Use your knowledge from your previous project and use the file system as your storage layer. Worry about understanding the basics of HTTP and what an API is supposed to do. A classic example would be to create an API to manage books from a bookstore.
-
Only then, once the first part of this project is ready, go back in and update the code so that it also interacts with a proper database. If this is your first interaction with one, I would recommend going with something like MySQL or Postgre, since those are the classic ones and internet is filled with tutorials around them.
The second half of this project is meant to give you a first brush with concepts around SQL or even high-level patterns such as ORM. Remember though, try to keep the idea behind the API simple, at this stage you don't care about functionality, you care about concepts.
Works on adding some auth to your app
I'm putting this one as a separate project because it has quite the complexity and I don't think that extra difficulty should hinder your progress when first introduced to the concepts around APIs.
But once you're done with them, and the idea of an HTTP request is natural, then it's time to step up your game.
Implementing authentication for an API can be as simple or as complex as you want. This is because there are so many damn options to choose from that it can be overwhelming. For that same reason I would suggest implementing it using the following progression:
-
First go with basic auth. In other words using a plain text username and password. This will introduce you to headers, the state on the server and how best to handle that information.
-
You can then move on to adding something like JSON Web Tokens (JWT), which will help you figure out other concepts around stateless APIs, and powerful auth methods.
-
Finally, if you feel like you're done with JWT you can implement some OAuth or social log-ins using a 3rd party API, such as that of Google or Facebook.
Word of caution: I would only attempt step 3 once I'm sure I don't have anything else to learn about the first two. This is because this step also adds interaction with 3rd party APIs and redirects, which are concepts you've not seen up until now.
By now you should feel quite comfortable around the language you picked and you've most likely created several different modules on your own as well as installed and used quite a few external libraries. Especially so if you're going with the likes of Python or Node.js which highly depend on external libraries.
With that in mind your next project should be another service, most likely an API that pulls data from at least 2 different places and aggregates it before sending back the response to the client.
A weather API with a twist
Internet is filled with weather APIs, so finding one that provides the information you need should not be hard. After that find some other geographical information you'd like to add, such as the size of the population for that city and write some code that will merge the data.
In comparison with the previous two projects this one should be easy to structure. Just provide a single endpoint for the client to specify the city name, then perform both requests (bonus points if you can do them in parallel) and merge both responses in a single JSON response before returning to the client.
This practice should give you an idea of what it's like to query external resources in the form of APIs, as opposed to writing your own ones.
Finally, if you're feeling extra confident by now, you might want to look into adding caching to the API. After all, some of the data you're retrieving is not going to update regularly. Consider using the same database you used before for this, since you'll feel more comfortable with it. However, if you like bonus points, figure out how to add Redis into your project and use it as the caching layer.
And with that, it concludes all the API-related practice you need, at least for the time being. If you feel like you'd like to know more about the world of microservices, check out this list of articles on the subject written by me.
Now, let's look at what else you can do in the back-end world.
Writing a chat server and a chat client
This is quite the jump, I know, but there is a good point for it: chat doesn't work over regular HTTP because with that protocol communication is not efficient.
Through working on these two projects you'll become very familiar with sockets, a very interesting and powerful way of communicating 2 or more services together.
Now, don't be scared, I know the idea of writing a full chat server can seem quite big, however, let me assure you: it's not.
If by any chance you're using Node.js, check out Socket.io to know everything you need to. That page will not only give you all the tools you need, but it'll also give you the examples you can start with and tinker until you understand how they work.
If you're using Python, you can take a look at this tutorial covering sockets with Python 3. And if you're using something different, just do a quick google search for “sockets in
Finally, let's tie it all together
Or as together as possible, after all some of the applications covered here aren't compatible with one another.
But taking as many of the concepts covered until now as we can, let's try to create a hangman-type game. You can make it quite interesting and it can all live in your terminal:
-
Use your CLI experience to create a command-line client that asks for your name, lets you input new letters on your turn and shows you the result of your actions.
-
Use an API to validate the input against the current phrase. You can keep the central logic of the game inside the API and just write a dummy client that sends requests and shows the appropriate response.
That alone should be enough to keep you busy for a while, but if you're feeling confident, you can use sockets to add multiplayer capabilities and share the real-time state of all players by exchanging the game state of each individual player through the broadcasting capabilities provided by the sockets.
Fun, isn't it?
And that's it, if you went through all these example applications you've experienced 90% of what it's like to be a back-end developer. That means you're more than ready to apply for that position and be very comfortable at job interviews.
