A More Robust, Reliable ReciPal
We're always working to improve the service at ReciPal for our nutrition label maker and inventory management product, whether it be features to make the process easier, making the site more reliable as far as uptime, or minimizing errors. Here are a few bigger projects we've worked on to improve page loads, minimize downtime, and improve life in general :)
DNS is kind of the yellow pages the internet - it's a directory that tells you where to look when you type in a particular web address. You have to find where that page and files are hosted before you can load any of the information on the actual screen for a user. But sometimes a DNS provider can have issues, suffer a DDOS attack, or one of a thousand other problems.
For that reason we've set up a DNS backup in case our primary DNS provider has any issues. This keeps the site accessible in case our main DNS provider has issues. The backup has had a remarkable record of uptime, so it's a pretty solid setup and something we wish we'd set up even earlier.
Scaling Web Servers
By default we have a normal amount of servers active to serve your web requests. However, if lots of people are using ReciPal at once or if they're doing things that require more computing power, we can automatically scale these servers up. That way performance doesn't suffer when lots of users are on the site doing lots of things at once. It's simple, flexible, and keeps everyone happy and the site snappy :)
Scaling Background Servers
The same thing applies to requests that occur in the background as opposed to the real time requests mentioned above. For example, when you update a recipe that's a subrecipe, the updating for the subrecipe ingredient occurs in the background because it'd be silly to make you wait for that to happen.
It can be a really quick process, or it can affect many related recipes, their costs, and ingredient lists. So sometimes that cascades down the line to require dozens or hundreds of changes. When it does cascade heavily, or if there are simply a lot of other background jobs to process, we also automatically scale those servers. This makes sure the background jobs are always being handled quickly and not causing a backlog.
Moving Bigger Tasks to the Background
We've also moved some of the larger tasks to the background so that they don't bog down the web servers. Some of these bigger tasks weren't even finishable in a reasonable amount of time to handle immediately, so they were moved to the background. For example, if you're downloading all your recipe costs together, this will happen in the background and you'll be alerted when the process is complete. This keeps the web requests as the prioritized simple, short requests and the longer running requests can be handled in the background.
That about wraps up some of the recent engineering projects we've worked on that aren't related directly to the product and features. Let us know what you think, if you've noticed anything slow, and we'll work on it!