Blog
Whilst working on client projects we often find useful bits of information out. Where possible we blog about that information to pass on our knowledge. Below are some of our most recent entries.
Keep your requests thin
When creating websites or web apps we give due care and attention to making sure pages load fast enough. We minimise our CSS, JS and compress images as much as reasonable to make sure page load times are kept to a minimum. How often though do we think about the impact of what's going on during a server response? Sometimes it can be a simple contact form submission which sends an email, sometimes it can be way more complex making large DB updates, image processing and calls to external APIs. These tasks need to be done, but do they need to be done there and then, or can they be off-loaded?
Image Processing Example
If we look at the simple example of a user uploading an profile image for some new fancy social site. The image probably needs to be processed into different sizes for later use. The thing to consider is if it's actually important that the processing happens right at that very second, during the postback process, or if it can be done via a background task. Does the user really need to wait while the postback completes processing the image into 4 or more different sizes? In reality they don't and so a task like this should be done in the background. Sure the postback needs to handle the file upload and the user has to expect to wait for that, but nothing more than this.
Bulk emails Example
In Incentive Maker, when a user creates a new game for their team the code sends out individual emails to each game player, to inform them of the new game. Depending on the size of the team playing the game this can be a large number of emails. It's important that this part of the game creation process doesn't slow anything up, so the email sending is done as a background task. This speeds up the process dramatically as the postback isn't waiting for a successfully sent message for each email. If an email fails to be sent the background task will attempt to send the email again.
External APIs
As more and more of the things we build are reliant on external API's we really do need to give more thought to off-loading the work done by a request to a background job. Sure there will be times where this can't be done as it's an important part of the process, but something like posting a message on a users Facebook page, or sending out a Tweet etc then it can be done separately.
A benefit of off-loading is that the user doesn't receive an "something went" wrong error message. So for example if Twitter is having a few issues, there is often no benefit to stopping the user on our site in their tracks and saying, "hey, Twitter is broken, please try again later". Move the Twitter api work into the background and let the user move on, oblivious to what's going on with the Twitter API. The background job can attempt to hit the Twitter API later if necessary.
Background job does not mean delaying things
Just because a task gets moved to the background, it doesn't necessarily get done later, it can be done asynchronously once registered. It just means those longer tasks are not holding up our users as they use our website or web app.
What should be done as a Background job
That's completely up to the developer. Sure, some stuff just has to be done as part of the request, but there is always parts that can be done separately. So basically, if the next part of the app is reliant on the tasks within the current request, then leave it there, if not, consider moving it into a Background job, and let the user have a better experience.
TweetRead more entries
Keep up to date
Want to find out more?
If we have piqued your interest then we'd love to hear from you.