Learning Web Development All Over Again

If I were to start my software engineering career from scratch, I would approach web development quite differently.

Start in the Middle

I’d begin with a simple project focusing on a web API. A web API (Application Programming Interface) typically acts as a bridge between the frontend of an application and its database or other backend services. Whenever a user performs an action in the frontend, like adding a comment to a blog post or updating their password, the request is sent to a web API. This API listens for, accepts, and processes HTTP requests from the frontend and makes calls to the database to perform the desired action.

But what kind of app is best for learning how to build a web API? I’d recommend a blog app. I recently built a personal blog engine over at Thunder Island and found the architecture and implementation of the project to be fairly complex, affording me the opportunity to learn new concepts and skills in web development. Although the creation of a full API is challenging, if you focus on one core concept at a time, a blog API is a fantastic way to learn web development. Here’s why:

• CRUD Operations: You’ll implement Create, Read, Update, and Delete operations for blog posts, comments, and users—core components of most web APIs.

• Authentication and Authorization: You’ll tackle user authentication (login and registration) and authorization (user roles and permissions), key security aspects in API development.

• RESTful Design: Designing a RESTful API helps you understand structuring endpoints, using HTTP methods (GET, POST, PUT, DELETE), and handling request/response formats.

• Database Interaction: You’ll learn to interact with a database to persist data, including setting up schemas, writing queries, and handling data migrations.

• Middleware and Error Handling: Implementing middleware for tasks like logging and error handling is crucial for building robust APIs.

• Testing: Writing unit and integration tests for your API endpoints ensures your application’s reliability and correctness.

By focusing on one of these concepts at a time, you’ll quickly have a functional API for your blog that you can interact with over the web.

Build a Monolith

These days, everyone seems to want to start web software projects with microservices. LinkedIn is filled with job ads requiring years of experience building and scaling microservices. The architecture itself is tempting buy into because its central idea is to organize each service into clearly separated domains of knowledge. The login and registration is a separate domain from editing a blog article; editing a blog article is separate domain from managing a profile page; managing a profile page is a separate domain from searching and viewing blog articles; the list of domains goes on an on.

Avoid Microservices… at First

A beginner might think this would make it easier to develop a web app. They would be wrong. I have a strong opinion on this subject: you should never start building a web application as a collection of microservices. There are much better alternatives to start that can evolve into a microservice when the time comes.

Microservices are powerful for scaling applications, especially when specific features become heavily used disproportionate to others. In the case of a blog application, suppose the API is organized into three features: blog editor, blog reader, and blog comments. If the blog reader endpoints receive 100,000 requests per week while the blog editor and comments endpoints see only 100 and 1,000 requests respectively, it might be time to reorganize these features into individual microservices to handle the growing scale.

However, this transition has significant downsides. For an individual developer, the biggest issue is manageability. The application is no longer a single codebase but is effectively split into multiple applications across different codebases. This introduces new infrastructure challenges, such as designing a reliable communication system for microservices (a service bus) and setting up deployment infrastructure to build, test, and publish each microservice, which requires careful planning.

Organize Your Code Into a Monolith

For a developer just starting in web software, I’d recommend sticking with a monolith. Keep all your endpoints for the blog application in one API and build it from there. As your application grows, you can break out the endpoints for various features into their own modules, following a modular monolith pattern. If your application becomes wildly successful, you can more easily migrate each module into its own microservice, one at a time.

This approach reduces complexity significantly. Ultimately, it allows a single developer—even a beginner—to build a simple API without the distractions that come with microservices.

Beyond Code: Scrum

The previous points highlight engineering-specific concepts for starting in web development, but there’s more to software engineering than technical skills.

Reflecting on my past roles in web development, desktop, and mobile, I’ve noticed they all revolve around product development methodologies, frameworks, and processes. The most common of these is Scrum.

Scrum is a product development framework that helps teams effectively develop, scale, and maintain a product. It’s based on empirical processes and Lean thinking. In Scrum, the product is developed in a large feedback loop containing many smaller feedback loops. The team builds a small product feature, they let stakeholders use it, and then adapt the feature based on the feedback.

If I were to start again, I’d dedicate significant effort to learning Scrum’s core concepts. I’d attend training sessions and talk to Scrum Masters to get different perspectives on how Scrum is applied across the field.

To put Scrum into practice, I would take my web API project and form a team to develop it into a full web application as a Scrum team.

Be Smart About AI

I’ve been writing software in some form since high school, but I only really started to develop full-scale software that resemble something a professional might produce somewhere around 2014 when I was teaching myself Python. In the mid- to late-2000’s, I could do a search through some forums dedicated to a specific language or framework to gain knowledge and get answers. By 2014 there was Stack Overflow, which offered all that knowledge in one relatively convenient place.

I’m not sure how popular Stack Overflow is now. There’s some data out there to suggest its usage is heavily in decline since around 2019. I see a lot of students and junior software engineers gravitating towards AI tools like ChatGPT and GitHub Copilot, rather than manually searching Stack Overflow.

Having even one of these AI tools when I was first starting out would have helped in ways that are probably immeasurable. However, I can say that I’ve learned a lot and improved the quality of my code by using these tools in my professional career. I often write some code and ask GitHub Copilot to suggest 2 - 3 others ways it could be written more concisely, more efficiently, or for better readability. Reflecting on the results has really helped me write code better on my own.

Approaching things from a different angle, I’ve also used ChatGPT to assist me in learning new programming languages and technologies. I’ve recently been interested learning Ruby on Rails to build my next web app, but there are some places I’ve stumbled on concepts and mechanics of the Rails technology and the Ruby language. ChatGPT has been fantastic for helping me breakdown these stumbling blocks and move forward with learning.

Beginners should absolutely use AI in this way. It’s a great tool for helping software engineers learn.

Where I’ve seen people end up doing more harm to themselves than good is when they ask an AI agent to write code to make parts of a full piece of software of which they conceptually have a tenuous grasp. They skip the phase of asking the AI agent to help them learn about how this component should work from a high level. Instead, they copy and paste whatever the AI agent outputs as a response. This doesn’t help a software engineer learn.

Wrapping up

In no part of this article did I mention a specific programming language I would start with. I have some opinions on which programming languages I would learn as a beginner, but that’s a separate topic for another time. Most programming languages have some type of web framework that can be leveraged to build a web API in that specific language. Whatever programming language you’re learning right now, do some searching about the ways in which you can use the language to build a web API; many languages have multiples ways to approach web development.

Don’t start with the most complex architecture for a project. Start with simple monolith. If your project grows to the point that it needs to be organized into micro services to support all the users, then change the architecture when that need arises.

Put in the effort to learn learn non-technical areas of the field. Specifically, learn Scrum to better understand how most teams build software from a product development standpoint.

Leverage AI tools to help you learn how things work. Don’t use them to shortcut learning.

If you or anyone you know wants to share their experience applying for jobs in the current job market, inside or outside software engineering, we encourage you to respond in an email to this newsletter! You may be featured in our next article.

Thank you for reading and we will see you in our next article as we continue our voyage.

Code on,
Matt, Editor and Software Engineer