Posts

Posted on

Connect multiple Docker compose apps

Much of the time I’m working on the Costs to Expect App and Website I code against the live Costs to Expect API. I’m reading data, so it makes sense to read live data, in my case the expenses for our children.

This approach isn’t suitable when I’m working on editing, creation, and deletion tasks; I don’t want lots of test data appearing on the API, and I don’t want to modify or remove live data.

In this instance, I want a local version of my Apps to use my local development instance of the API; this is simple to set up with docker networks.

I use Docker for development, the App, Website and API development environments are all Docker compose.

To connect two or more, compose apps, you need to create a shared network and then update each docker-compose file to use the newly created network.

To create a network, in your CLI enter.

docker network create <network-name>

Now, update your docker-compose files, we need to add a networks section.

  networks: 
    default: 
      external: 
        name: <network-name>

Now, when you bring your apps up, they will be able to communicate. Assuming your apps connect over HTTP, your apps can talk to each other using this format, http://:. In my case, my Website and App connect to the API using http://api:.

Posted on

Website caching, simple now, later, dependant caches.

Two weeks ago, I quickly added caching to the Costs to Expect Website. My goal was to reduce the number of unnecessary API requests the Website made to the Costs to Expect API, mission accomplished.

The problem, I did a quick job, improvements needed.

The Costs to Expect Website is a long term social experiment, my wife and I are tracking the total cost of raising humans; we want to know how far off the £250,000 per child figure we will be when our sons reach the age of 18.

Back to the caching, issue one, I added caching to the top four or five pages; the rest of the Website needs some love. Issue two, for some unknown reason, I decided 15 mins was a sensible cache lifetime.

Solution one

I hacked in the caching; I added a simplified version of the much more featureful caching in the Costs to Expect App. I need to refactor the ‘request’ code and add caching for all requests.

Solution two

I set the cache lifetime at 15 minutes, why I don’t know. The content on the Website changes at most daily and additionally there is no need for the data to be live; people are not going to ‘throw a fit’ if they can’t see the latest expense we have added for Jack or Niall.

I am going to set the cache lifetime to four hours.

Four hours you say, why not 24? Well, I figured it is a sensible limit to ensure there isn’t too much of a mismatch between cached data while still dramatically reducing API requests.

Imagine a scenario whereby a user browses to the site and visits the summary page; the results are cached; they never, however, make it to the lists for that summary. If a second user comes along three hours later and views the listings, there is a good chance the data will mostly match the cached summary. If I set the cache lifetime at 24 hours, a value that initially seems reasonable, I am increasing the chance of the summaries and data mismatching.

There is a solution to the inconsistent data problem, dependant caches.

I need to add support for linking cached data, for example, a summary and the related lists, and more importantly, controlling the maximum period allowable between dependant cache item creation.

With the current implementation, there can be a difference of up to four hours between summary and list cache creation, realistically, the limit for dependant data should be closer to five minutes.

I will eventually update the caching system for the Costs to Expect App and at some point, trickle the implementation down to the Costs to Expect Website.