Over a million developers have joined DZone.

Using Mountebank to Detatch Frontend and Backend Development

DZone's Guide to

Using Mountebank to Detatch Frontend and Backend Development

An example of how Mountebank can mock out depended-on services where TCP/IP separates you from that service, which allow front-end and back-end teams to work at a high pace together.

· DevOps Zone ·
Free Resource

Discover how you can reduce your Kubernetes installation from 22 steps to 1.

While any self-respecting Agile (eXtreme Programming or similar, preferably) team will do “thin vertical slices” of functionality with a top-down approach for development, sometimes stacks can become unwieldy.

Mountebank is a few years old now, and quite a solid tool, despite being pitched at hipsters. It allows you to mock out depended-on services where TCP/IP separates you from that service. There is a neat way to use such tools to allow front-end and back-end teams to work at a high pace without being tied to a full-stack build.

Technology Compatibility Kits

This isn’t an invention of anything, just a description of something that’s been done occasionally for a number of years.

You should have two repos – one from frontend stuff, and one for backend. If you’re doing the Google or Facebook style mega-trunk, then that would be two directories in the same repo/trunk. The front-end team can program at full speed without always bringing up the backend. Similarly the back-end team can work at full speed without ever kicking off the front-end team’s build. Note, this is detatch rather than decouple.

Mountebank as a mocked/stubbed backend facilitates the front-end team’s full speed. Integration tests, that are part of the front-end team’s repo (above the red line), are part of the backend team’s toolchain to prove that what they are making fits the expectations of the front-end team. Running those integration tests against the mountebank mocks is a proof that everyone is on the same track.

So, I show four permutations above, because there are four pieces of news that a CI build loop should publish. That could be four CI configurations, but it could as easily be one larger one, with a pipeline. Granted that is not so easy when there’s two repos involved in the checkout. WebDriver may play too – comprehensive and really fast for the frontend with mountebank, and much much shorter or “happy path” for the full stack CI build loop.

Really this fits development that uses JavaScript micro-frameworks more than it does “web 1.0” technologies. But it is still possible there, if there’s a set of service calls from the Rails, Django or Servlet tier to layer below it.

There are small complexities with Mountebank too – you have to bring up a server process for Mountebank itself, before running the test suite, and then tear that down at the end of the build. Some googling will help you overcome that.

Also, don’t forget the gold standard of Agile development, though: thin vertical slices all the way through the stack, and small stories.

Download the Kubernetes cheatsheet to learn more about how easy it is to run Kubernetes on any infrastructure with Mesosphere DC/OS

devops ,agile ,front-end ,back-end ,tcp/ip

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}