loading...

Top Mistakes That Back End Developers Make

aumayeung profile image John Au-Yeung ・3 min read

Subscribe to my email list now at http://jauyeung.net/subscribe/

Follow me on Twitter at https://twitter.com/AuMayeung

Many more articles at https://medium.com/@hohanga

Even more articles at http://thewebdev.info/

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.

In this article, we’ll look at mistakes that back end developers make.

Deploy on a Friday

If we don’t want to fix problems on the weekend, then we shouldn’t deploy on Friday.

Any deployment is risky and we should always think twice before doing if it’s not an emergency.

Things never go the way that we expect. And we definitely don’t want to ignore anything bad that comes up on the weekend and have angry customers to deal with on Monday.

Bad Input Validation

Server-side input validation is important. They serve 2 purposes. We need them to ensure security and also to prevent corrupt data from being saved.

We have to prevent SQL injection issues so that attackers can’t run malicious code to do whatever they want in our databases.

Also, we should validate input data to make sure that the data is in the proper format that we’re looking for.

If we don’t, then we’ll probably run into problems in some other places.

Most back end frameworks should be able to do both out of the box so that we don’t have to write all the code from scratch to do all that validation.

Authentication and Authorization

Authentication and authorization are 2 different things. People may not be aware of that.

Authentication is just checking for the ability to be able to log into a system with valid credentials. Authorization is the privileges that we give users.

We should make sure that users aren’t authorized to do more than they should.

For instance, if they’re a regular user, then they shouldn’t be able to view other user’s private profile. That’s an authorization.

Authentication is just making sure that a username and password or anything else that we have to enter is valid so that we can log into a system.

Ignoring Performance and Scaling

Performance and scaling are always important things to consider in the back end. We don’t want our systems to time out when we’re dealing with too much data.

Therefore, we should consider caching, doing long-running jobs in the background, pagination, etc. These are things that’ll help us prevent overloading our servers.

It’s bad if our app is overloaded since it’ll fail before it can do what customers want.

Not Running Resource-Intensive Processes in the Background

Resource intensive jobs like report generation, sending mass emails, etc. should all be done in the background. They’re all resource-intensive and it’s hard to do them synchronously without holding up our app for a long time.

Users will be frustrated if they’re left waiting for a long time when we have jobs running in the foreground and keeping users waiting.

Therefore, we should create background jobs for these resource-intensive tasks and batch them so that they won’t overload our servers.

Also, we should move these tasks to run on their own servers so it won’t overwhelm the main app.

Not Optimizing Bandwidth Usage

We should minimize bandwidth usage in all communications. For instance, we may be sending large chunks of data or images between multiple remote servers.

To make the transfer process more efficient, we should compress everything before sending it to save bandwidth. Then they can be decompressed on the receiving server.

Using RESTful Anti-Patterns

REST API should follow some basic best practices. For instance, the HTTP verbs to match the database operations that they’re doing.

GET should retrieve data, POST should create data, PUT and PATCH should update data, and DELETE should delete data.

This way, no one will be confused as to what our code is doing.

Also, our endpoints have to send the right HTTP status codes. 200 series is for successful operations. 400 series for errors coming from client-side and 500 series errors for errors occurring on the server-side.

For instance, 401 is for unauthorized, 403 means that we’re forbidden to access a resource because of a lack of privileges, 404 for not found, 502 for timeout errors.

Conclusion

We should stop ourselves before committing these mistakes if we’re doing back end development.

We should think about performance, scaling, validating inputs, and returning errors with the right status code.

Posted on by:

aumayeung profile

John Au-Yeung

@aumayeung

I'm web developer interested in JavaScript stuff.

Discussion

markdown guide
 

Those are all good points, but in my opinion deploying on a Friday is NOT a mistake.

If you are scared of deploying on a Friday, than you are not confident enough with your deploys and you should invest in your CI/CD pipeline, all kinds of tests (unit, integration, e2e) and blue/green deploys.

 

I think absolute statements are often incorrect. I agree with this comment in principle (if you're not confident in your deployment process then that's a smell that should be addressed), but to say "you should feel comfortable deploying at any time" is a goal to strive towards that not everyone is in a position to do.

For example: say you have a very large complex legacy application. Currently deployments of that system are risky. Sure you should absolutely strive to address that, but that process doesn't happen overnight, so in the interim a policy of "no deploys the day before the weekend" is a pretty reasonable compromise until your CI/CD pipeline (if that's even possible for your business) is sophisticated/robust enough to ensure that breakages are infrequent on releases.

 

I agree with you on all points! I know that my absolute statement ("always deploy") is something only a few companies can successfully pull off, but I wanted to counter the "never deploy on Fridays". Because what happens, if it takes more than 1 day to resolve an incident following a deployment? Don't deploy on Thursdays and Fridays! And the list goes on and on until there is a release day once a month/quarter when the stars align perfectly :D

 

Having an automatic pipeline for deploy and rollbacks definitely reduce the risk a lot.

 
 
 

Big Commit before you go on vacation. And better version of it is when you cannot revert it.