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.
Join the DZone community and get the full member experience.Join For Free
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.
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 .
Published at DZone with permission of Paul Hammant. See the original article here.
Opinions expressed by DZone contributors are their own.