It is not an unusual occurrence for me to join a project that is already underway. In most of the projects I work on there are one or more network accessible services and one or more front ends. Each of the services and front ends are often the responsibility of a separate team or individual programmer. Before writing a line of code I ask for the technical specification and any API documentation that is available. Usually the documentation is not perfect, and especially around the edges there are places where programmers can make assumptions. These assumptions are often not checked or added to the documentation and can lead to a breakdown in communication between the front end and back end teams as well as a breakdown in the API design.

When doing systems integration work, I find that my job is often to mend the breakdowns both in the API and among the teams. To do this I use a tool I call Moxie.

What is Moxie?

Moxie is a combination of two fairly common servers rolled into one. Moxie acts as a mock server to the front end team, and it acts as a proxy server for the back end team. It therefore sits between the front end and back end spontaneously generating traffic, modifying traffic as it passes through, and/or logging traffic and the issues that arise in communication between the front end and back end.

Moxie Architecture

A Moxie server gives the systems integrator a good level of visibility into the communication protocols as they are actually implemented. This can help diagnose protocol implementation errors. Simple errors can even be corrected on the fly by rewriting the communication stream. The systems integrator can also begin to document behavior which is undocumented in the protocol specification based on the traffic seen by the Moxie server.

A Moxie server can also help decouple dependencies between the front end and back end team. If the front end needs a new API service right away, it can be mocked up in the Moxie server until the back end team has a chance to write the full implementation. Similarly the Moxie server can begin sending test queries on a new API to the back end server before the front end is ready to support the new API feature.

Characteristics of a Moxie Server

The primary characteristic of a Moxie server is to be very lightweight and easy to change.

Other characteristics are:

  • A Moxie server can act as a mock server for the client side.
  • A Moxie server can act as a proxy for client/server communication.
  • A Moxie server can provide detailed communication logs.
  • A Moxie server can act as a unit testing client for the server side.
  • A Moxie server can inject errors and delays in the client/server communication for testing.

I use python, the bottle microframework, and requests to build Moxie servers quickly, often in a day or less. I also tend to use a python unit testing framework to add a test harness so I can validate the back end at any time. I make the log information and unit testing information accessible via a simple web site to maintain a transparent process for both the front end and back end teams.

A Moxie server is not meant to be resilient to heavy loads. It's a tool for analysis during development and putting in the effort to make it production ready is likely not a good investment. It is also not meant as a replacement for back end services. Although it may contain the initial mock service, putting effort into implementing the entire service is petter spent on the production back end. If you feel you should connect to the back end database with your Moxie server, then you are probably building out the mock service a little too much.

Resistance to Moxie

I have encountered a certain amount of resistance to using Moxie servers, which is part of the reason I have written this article. Some managers feel like it is a waste of resources to create a server which will be removed for production. I compare the Moxie server to scaffolding around a construction site. Of course it wont be there in the end, but it will be a lot harder to build your product if you don't build up scaffolding first.

I've also known developers who felt like the Moxie server reflected negatively on their skills as a front end or back end developer. I think most projects could benefit from a Moxie server, and although it might not be formalized in the same way, many projects do use the components of a Moxie server already. Mock servers are quite common for front end developers, and many back end developers use unit testing on their protocols. The Moxie server just formalizes these tools and adds a proxy for traffic analysis.

Where do I Find a Moxie Server?

Moxie servers have to be built to fit the project at hand. If you are interested in improving the efficiency of your front end and back end development by using a Moxie server for your projects, please contact me. I would be happy to work with you and your team.

i