Author: DeanBlackborough

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

How we expose Open Source REST API usage within our app

The Costs to Expect App is not an Open Source product; we intend to create a viable service; for now, we are keeping our secret sauce secret.

The App is built upon the Costs to Expect API, the API is Open Source and technically, anything we can do with the API, you can too. We aren’t gatekeeping your data; you can access your data through our App with the UI/UX we are creating, or, you can use other tools to fetch the data directly from the API.

To this end, we expose all GET, HEAD and OPTIONS requests, we hide POST, PUT, and PATCH requests as you can’t review them after the fact without unnecessary data being cached.

At the bottom of every page within the App, there is a table showing the required API requests. The table shows the request URI, the request METHOD, the response time, as well as was the request asynchronous or did we fetch it from our cache.

I appreciate that to the majority of users this data is redundant, yes there will be a visibility toggle; however, for the minority of users that are interested, I think the extra effort will be appreciated.

API requests table for the Costs to Expect App