Here at we strive to use our own tools to make our lives easier. As the Lead UI Engineer, this translates directly into making the review process for any upcoming changes to the application as painless as possible. As we iterate on the next set of changes for the UI, we like to have our designers and product owners see the progress without having to maintain multiple development environments. Using, we are able to create updated Docker images and have the designers and product owners test them with minimal command line knowledge. In fact, they only need to leverage a single docker-compose command. Let’s take a look at the process.

Getting Started in a Galaxy Far, Far Away

We will be using a somewhat less complex application than for this exercise, a single page displaying a list of Star Wars characters. Then we will make some changes that we want reviewed without needing a development server or overwriting any other work being done by other developers. For this exercise we will be using two services that exist on DockerHub, graphql-swapi and ui-swapi.

First, we will need to get the relevant services for our application. With built in DockerHub support, this is as simple as searching for the correct services and dragging them onto the canvas within the modeler. Then a quick drag to couple our dependencies, some port mapping to expose the correct ports for our services to interact, and application setup is done. All without editing a single line of YAML.


With the application model saved, I let the design team know that they can open it and download a compose file that maps to the application in its stable form. They download the file, run a docker-compose up against the compose file and are greeted with this beautiful UI when browsing to http://localhost:3000.


UI Re-release

The UI team is thrilled, however the lead designer was talking to a friend at the local coffee house and they totally agreed that the application needed to have a Tatoonie theme, and asked for the colors to be more reminiscent of the desert planet. Oh and the product owner has some new requirements, primarily the addition of home-world data for each character. Naturally we agree as these changes are easy enough.

For our part, we create a branch to contain these changes in our codebase, make the expected tweaks and submit a pull request. As part of our pull request review process we need the design team and product owner to sign off on the changes. The developer pushes up a newly tagged version of the UI, forks the existing application model, and updates the fork to contain the tagged version of the UI. Our designer and product owner then simply go to, choose the forked version of the application that contains the updated UI, and save the application.


After downloading the compose file they both run a docker-compose pull and up commands and, voila, they see an updated version of the UI.


Rebels Always Win

Naturally everyone was super excited about the design changes and the Pull Request was approved with no more changes. For our part on the development team, we simply merged the PR then rebuilt the production tagged UI image. On our next deployment to production, the changes were pushed and the world could see our character list in all it’s glory.

Although simplified somewhat in application scope and number of services, this is the exact process the team uses when developing the application.

Interested in learning more about Sign up for free to see how can help your team streamline their development process.