Nikola Perišić for Dev.to Rater Organization

Posted on Feb 14 • Edited on Feb 17

The biggest backend mistakes you can do

#webdev #programming #backend #javascript

Hello, fellow devs! Welcome to the second part of our series how to become a better developer. You really liked the first part (The biggest frontend mistakes) sooo, voila!

Today we will learn about common backend mistakes. I'll highlight some of these mistakes and show you how to avoid them.

1. Missing security

I intentionally set this as the first point. As a backend developer, you build the system.

Of course, that system need to be secured. I can’t believe how many people still neglect security features like CORS or Rate Limiting in their applications, but sadly, it happens. These topics are crucial for protecting your system against vulnerability attacks. Below, I’ve made a checklist of essential topics to test your system with.

Security Checklist:

Category	Security Measures
Network Security	Enable HSTS
	Use SSL
	Check SSL Version, Algorithms, Key length
Authentication & Session	Use Secure cookies
	Implement SHA256 encryption for passwords
Authorization & Access Control	Implement CSRF
	Test for bypassing authorization schema on forms
Input & Data Validation	Test for HTML and SQL Injection
	Test file extensions handling
Client-Side Security	Check for sensitive data in client-side code
	Use reCAPTCHA whenever you can

2. Poor Database Design

Lack of Proper Indexing: Developers sometimes forget to add indexes or add too many. Neither is good. You should find the right balance. Without indexes, queries become slow as the database scans entire tables. On the other hand, excessive indexing increases storage use and slows down write operations. So be careful.

Our tip: Add indexes only for columns that are queried frequently.

Ignoring Scalability and Future Growth in the beggining: Many developers design databases based on current needs without considering future growth. This leads to issues like lack of partitioning, poor choice of data types, and difficulty in handling high traffic loads later on.

Our tip: You might think that spending a lot of time on database design is unnecessary, but it's not. Database planning requires you to think about current needs and for future growth. As in a previous example, here also, you need to strike for the right balance. We suggest using this formula:

currentNeeds = 10GB // For example

myDatabase = currentNeeds x 0.20 // So add 20%

Practical Explanation:

This formula helps you plan your database by accounting for not just your current needs, but also future growth.

currentNeeds -> This is how much space or how many resources your database currently requires. Think of it as the size of your existing data or the capacity you need for your current operations.
myDatabase -> This is the final size or capacity of your database, which is the combination of your current needs and the additional buffer (20%).

So, instead of just allocating 10GB for your database, you plan for 12GB. This 20% extra space accounts for growth, ensuring your database won't run out of space as you add more data or features over time.

Additional Considerations:

Column Choices: Use appropriate data types. For example, instead of using a VARCHAR(255) for a field that will never exceed 100 characters, use VARCHAR(100) to save space.
Growth Monitoring: Continuously monitor your database's growth. You can set up alerts based on disk usage, table size, and the number of rows. More about database alerts you can find here.

By thinking ahead and allocating 20% more space for growth, you're avoiding potential problems related to database performance and the need for frequent redesigns.

3. Not Considering Caching

Caching is an essential aspect of backend development, yet it's often overlooked.

Why it’s important:

Without caching, your system might become slow as more users access your app. Every time a request is made to the server, the system has to process the request fully, which can lead to latency and performance issues and surely you don't want that.

Our tip: Use in-memory data stores like Redis or Mem****cached to cache frequently accessed data (like product details or user sessions). Also remember to set expiration times and cache invalidation strategies to ensure that the cache is refreshed with the latest data.

4. Hardcoding Values

Hardcoding values such as database connection strings, API keys, and other configuration parameters directly in your code is a common and BIG mistake.

Why it’s bad:

It makes the code harder to maintain.
Exposing sensitive information, like API keys, in code can lead to security issues.
If you need to change a configuration value, you’ll have to search through the entire codebase and update it everywhere.

Bad ❌

public class UserService
{
    public void ConnectToDatabase()
    {
        // Hardcoded connection string, making it difficult to change or secure
        string connectionString = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;";
        // Code to establish a connection...
    }
}

Good ✅

public class UserService
{
    public void ConnectToDatabase()
    {
        // Use environment variable to get the connection string securely
        string connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION_STRING");

        if (string.IsNullOrEmpty(connectionString))
        {
            throw new Exception("Database connection string not found.");
        }

        // Code to establish a connection...
    }
}

5. Not Using Version Control Properly

If you write commit messages like this:

git commit -m "fix"
git commit -m "fix v1.2"
git commit -m "fix something"
git commit -m "fix bug"
git commit -m "change"
git commit -m "optimization"

Don't push.

Why it’s bad:

Other developers don't know what you've done in that commit without checking the changed files which requires time.
By doing this you can easily have a lot of commits with same/similar message.
When you need to revert to the old commit, and by seeing commit log like the above one, you cannot know to which one to reset.
In the future you will not know for which part of the application was fix commit, for example.

Good ✅

git commit -m "chore: modify README.md file"
git commit -m "fix: user validation not working"
git commit -m "feat: user validation of create form"
git commit -m "docs: add our team page"
git commit -m "ui: add image swiper on the home page"

Bonus tip: Always write commit messages in Present Tense. So instead of changed write change. You can learn about Conventional Commits here.

6. Not Separating Business Logic, Infrastructure, and Other Concerns

One of the common mistakes backend developers make is not properly separating concerns in their codebase. Specifically, mixing business logic, infrastructure code, data access, and API routes into a single class or module.

Why it’s bad:

Tight coupling: When business logic is tightly coupled with infrastructure code (such as database operations, third-party service integrations, etc.), it becomes difficult to test and maintain. A small change in the infrastructure may break your business logic.
Hard to scale: As your codebase grows, the lack of separation leads to more complexity, making it harder to scale the application and develop new features without breaking existing functionality.

Our tip: Separate these concerns into different layers or components. This follows the Separation of Concerns (SoC) principle and improves readability, scalability, and maintainability.

Examples: Clean Architecture, Hexagonal Architecture, Layered Architecture, Microservices Architecture, CQRS, Event-Driven Architecture, Domain-Driven Architecture

Conclusion

Keep these tips in mind as you continue your development journey, and remember: testing, optimizing, and following best practices will always pay off in the long run!

If I forgot something or you liked the article, please leave a comment down below 💬

Thanks for the reading :)