Developer update week 06 2019
An insight into what sweet things we’ve been cooking up.
So we understand we’ve been super quiet here at Candy HQ and it’s not for lack of progress, we’ve been hard-pressed to our keyboards adding stability changes and improvements to the API & Hub and now we’re at a point where we can deliver a weekly developer update of what we’re up to and what’s new.
So without further ado…
Upgrading to Laravel 5.7
From version 0.2.0 we are now supporting Laravel 5.7
We want GetCandy to always be available on the most recent version of Laravel, it’s that simple. So we will actively take steps to ensure that you can upgrade GetCandy when you update your own applications, or you can install it with minimal fuss on the latest versions.
We will always tag a minimum MINOR version when we do so.
Cutting the load with internal requests
A common set up when consuming an API in your app is to have a proxy between your frontend and the API. If you have your API on a separate instance to your frontend, this is great as you have distributed the load.
The problem comes when everything is on the same instance, you’re going to be making wasteful HTTP requests to your API, for example…
Say we have a basket page, on this page we hit the controller and we use the PHP client to fetch a few different things we need, such as:
- The current basket
- Any recommended or related products
- The current user (if there is one)
- Estimated shipping
And that’s just for the basket, you might even have a call to the API to fetch the categories, for example (although would likely be cached)
So for one user, there is a potential of 5 HTTP requests per visit to this one page. If you have 100 people looking at their basket, that’s 500 requests, way too many for such little traffic. So how do internal requests solve this??
Internal requests to the rescue
Using internal requests we can route all the client calls internally through Laravel’s container, meaning no actual HTTP requests get called, it’s all handled…internally.
So now our 5 requests become just 1, one request to the proxy controller. So with 100 people you only need to make 100 HTTP requests. Soooo much better, your server will love you for it.
Okay cool, how do you utilise this? Well if you’re using the PHP client then all you need to do is add this env variable:
And that’s it, now all calls through the client will go through the container.
That about wraps up this weeks update, next week I’ll cover how we recently improved Elasticsearch to ensure zero downtime and zero conflict indexing, using aliases.
If you’re interested in any particular topics then feel free to leave and comment and I’ll see what I can do.