Over a million developers have joined DZone.

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

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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.

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

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

Published at DZone with permission of Paul Hammant. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}