I’ve seen the backend of quite a few websites written from scratch and quite a few of the challenges that arise as a result. I’m going to share a few suggestions I have for you due to some of the issues that I’ve seen come up.
- Use a config file – A central location for any configuration options is essential. I’ve seen some sites created where the database connection was defined at the beginning of each php file. It was quite an ordeal to make all of the code changes necessary when they needed to move their database to its own server instead of ‘localhost’ Also, you can include options in there for specific environments (i.e. dev, qa, production)
- Don’t ever trust any data sent to your server from web browsers – It doesn’t matter if you validated it with javascript, if you don’t validate your data on the server side and sanitize it before storing it, someone will figure out how to break it. Those ‘someones’ usually don’t have the best of intentions. (see http://xkcd.com/327/ for a humorous example)
- Don’t store plaintext passwords in your database – This goes for any sensitive information. Passwords can be stored and validated with a one-way hash. Other sensitive data should be encrypted prior to storage in the database.
- Don’t store user uploaded files on the webserver – For example, if you allow your users to upload photos. If you store those photos on the webserver, what will happen when you scale and add another webserver, or you add 10 webservers? You’ll have to some how synchronize the files across all of the webservers which is time consuming and error prone. An easier solution is to use a service like Amazon’s S3 to store and serve up files. One additional bonus of using an external service is you don’t have to worry about users filling up the disks on your webservers.
- Isolate your static content – As usage of your site increases, you’ll be looking for ways to make it faster for your user. One of the best things to do is move your static content to a CDN. You don’t need to use a CDN from the beginning, but you can set your site up to make it an easy transition when the time comes. You can initially just use a vhost on your webserver as a pseudo CDN.
- Be very nice to your database – I can’t emphasize this one enough. As you grow, your database will be the most difficult thing to scale. Do your JOINs in your code, don’t make the DB do them. Make sure you’re using indexes properly. Avoid table scans like the plague and eliminate any slow queries that come up during development.
- Plan to scale – I’ve said this before. Have a long term scaling plan drawn out but only execute on it as needed. You don’t want to waste time and resources solving issues that may not exist down the road for you anyway. Without a long-term plan, you can easily paint yourself into a non-scalable corner which will result in poor performance and downtime as you fix things.
Most of these things are already addressed if you use a framework. The ones that aren’t can usually be easily taken care of.
Another advantage of using a framework is that it will force your developers to write code a certain way (which hopefully adheres to the framework’s standard) This will allow you to enlist the help of other developers in the future without requiring them to spend time sifting through what otherwise could be messy code. Code written from the ground up by a single developer is more difficult to learn. And don’t forget, there will be a certain level of support with a framework. If a vulnerability is found in a framework, it will usually get fixed quickly and released so you can use the update.
Be sure to have more than one person review your code and your plan for scaling. If you need help, contact us and we can do both for you.