Top 7 things you need to know when programming for the web
Over fifteen years of developing for the web, I've learned some lessons the hard way. There are some things they don't teach you in books and tutorials.
If you build it they will come
That is, if you build a form on a website, spammers and hackers will come to your site.
No matter how small and insignificant your website is, they will try and use it to send you spam, show spam on your website, or hack into your website so they can either show spam or get personal details.
You need to protected your website from every possible form of spam or hacking. Spammers and hackers can be very smart (some SQL injection techniques I have seen are really quite amazing), so you need to be smarter.
Your database is your bottleneck
In a complex database-driven website the database is the usual cause of performance issues.
If you are dealing with a website that handles a reasonable amount of users, then from the outset you need to ensure:
1. Your queries are as efficient as they can be.
2. Your database is indexed well.
3. You cache often used data that doesn't change frequently.
4. You use transactions only when necessary.
Error Notifications
I personally want to know about every 500 Internal Server Error, and I would suggest that you have every error emailed and/or logged (see don't rely on email below).
It can be a bit draining on a high volume website to see every error, but you may well find some problems that you didn't pick up in testing, some controls that may need validation, and probably plenty of hacking attempts.
Although you might not want to know about every 404 Page Not Found error, it's good to know about any 404 error where there referrer was also a local page. ie. you want to know about broken internal links.
Don't rely on email
Email isn't always reliable so it's never a good idea to solely rely on email for important information. I had an ecommerce website where some server settings changed and email from the website stopped working. Before I found out, every message that was sent through the contact form never made it through and was lost forever.
You should store everything that you send by email in a database table or at least a log file of some sort.
What time is it?
If you are storing dates and times in a database then you should store the universal time (UTC) rather than a local date/time. Even if it is a web site that is only for a specific country, think about the consequences if you were to move to hosting in a different region where the server time zone might be different, or what happens when daylight savings ends as the time goes back an hour and the last record in the database has a datestamp 1 hour before the previous record.
Keep a history
In many simple applications the developer will often choose just to overwrite information in the database when something changes.
For example, on an ecommerce website, if a price changes you might just update the same database row with the new price. But what if you need to know what price was being offered on a past date?
Or, in a content management system, what if someone accidentally updated the wrong page? They may have lost some valuable information if the database row has been updated.
For reasons like these, it's almost always good practice to implement some sort of history or version control system and insert a new row when data changes rather than overwrite the same row.
There are various ways of doing this. For example, you may keep multiple versions in the same table or create a separate history table.
Validate all user input
It is essential to protect the user against submitting information that your application won't accept.
Examples include text that is too long to fit in your database, negative numbers when only a positive number is acceptable, date and time, and uploading of files.
If you don't validate all input then the user may receive a server error and have no idea what they did wrong.
If you develop in ASP.NET then see also my Things you need to know when programming in ASP.NET Web Forms post.
If you build it they will come
That is, if you build a form on a website, spammers and hackers will come to your site.
No matter how small and insignificant your website is, they will try and use it to send you spam, show spam on your website, or hack into your website so they can either show spam or get personal details.
You need to protected your website from every possible form of spam or hacking. Spammers and hackers can be very smart (some SQL injection techniques I have seen are really quite amazing), so you need to be smarter.
Your database is your bottleneck
In a complex database-driven website the database is the usual cause of performance issues.
If you are dealing with a website that handles a reasonable amount of users, then from the outset you need to ensure:
1. Your queries are as efficient as they can be.
2. Your database is indexed well.
3. You cache often used data that doesn't change frequently.
4. You use transactions only when necessary.
Error Notifications
I personally want to know about every 500 Internal Server Error, and I would suggest that you have every error emailed and/or logged (see don't rely on email below).
It can be a bit draining on a high volume website to see every error, but you may well find some problems that you didn't pick up in testing, some controls that may need validation, and probably plenty of hacking attempts.
Although you might not want to know about every 404 Page Not Found error, it's good to know about any 404 error where there referrer was also a local page. ie. you want to know about broken internal links.
Don't rely on email
Email isn't always reliable so it's never a good idea to solely rely on email for important information. I had an ecommerce website where some server settings changed and email from the website stopped working. Before I found out, every message that was sent through the contact form never made it through and was lost forever.
You should store everything that you send by email in a database table or at least a log file of some sort.
What time is it?
If you are storing dates and times in a database then you should store the universal time (UTC) rather than a local date/time. Even if it is a web site that is only for a specific country, think about the consequences if you were to move to hosting in a different region where the server time zone might be different, or what happens when daylight savings ends as the time goes back an hour and the last record in the database has a datestamp 1 hour before the previous record.
Keep a history
In many simple applications the developer will often choose just to overwrite information in the database when something changes.
For example, on an ecommerce website, if a price changes you might just update the same database row with the new price. But what if you need to know what price was being offered on a past date?
Or, in a content management system, what if someone accidentally updated the wrong page? They may have lost some valuable information if the database row has been updated.
For reasons like these, it's almost always good practice to implement some sort of history or version control system and insert a new row when data changes rather than overwrite the same row.
There are various ways of doing this. For example, you may keep multiple versions in the same table or create a separate history table.
Validate all user input
It is essential to protect the user against submitting information that your application won't accept.
Examples include text that is too long to fit in your database, negative numbers when only a positive number is acceptable, date and time, and uploading of files.
If you don't validate all input then the user may receive a server error and have no idea what they did wrong.
If you develop in ASP.NET then see also my Things you need to know when programming in ASP.NET Web Forms post.
Related Posts
Converting dBase IV programs to run in the browser
by johna | September 13, 2024
Some pointless entertainment trying to get some old dBase programs running in the browser.
How to set up a debugging using the Turnkey Linux LAMP stack and VS Code
by johna | December 19, 2023
The second part in my guide to setting up a website and database using the Turnkey Linux LAMP stack.
How to set up a website and database using the Turnkey Linux LAMP stack
by johna | November 18, 2023
If you need to host your own website for the purposes of web development, Turnkey Linux LAMP Stack is an easy to install all-in-one solution that you can set up on a spare computer or a VM (Virtual Machine).
Comments
There are no comments yet. Be the first to leave a comment!