The simplest micro-service you ever created Subscribe

What do we call a one-line micro-service? A pico-service? Here's one of the simplest ways to create the minimal "Hello, world" as a REST service:

$mock say.hi (name ?= "Jane") => (greeting = "Hello, " + name)

Pretty self explanatory, methinks: the service say.hi takes as input a name with the default or sample value Jane and will create a greeting with the respective expression. You'll find the URL to call it in the REST tab and, to get different results, you can change the resultMode to one of debug,json,value.

Go on, play with it: Click the "Edit" and change something like the name, greeting or the service name and the page will update and refresh, as the new service becomes available, even without having an account on the website (there is like a 5-10 minute session timeout after which you have to start again, by refreshing the page). If you want to be able to persist your mocks, just create an account at to create a project.

There it is! A little mocker of a service... we can complicate it from here, but we have the minimum to now develop tests, acceptance criteria and other services in our architecture.

Upfront investment or just-in-time evolution?

Do we tie a service to a locked down complex API early in the architecture? Or do we delegate some of the complex API specifications for a little later in the game, when we did flush out all the components, storyboarded most of the scenarios and allocated responsibilities properly etc?

Delivering functionality incrementally is an especially favorable environment for this kind of rudimentary prototyping - sometimes we may not even get to implement some of the components and services envisioned originally, so simple mocks again rule.

I tend to leave the details for later and evolve little functional APIs as needed, for a full mock-up of the entire system or parts of the solution, taking a quite minimalist approach. Proof-of-concepts rule and this one liner JSON inventory mock suffices early on:

$mock inventory.findSubscriber (name ?= "Jane") =>(subscriber={subscriberId : '1234', name : 'Joan', address : '123 Fiddle Way' })

Sure, the contents of the actual subscriber structure will evolve in time, but the subscriber inventory will always need a query by name and return a structure... and a hundred Java classes, to get a JAXB mapping will not help a Node.js client anyhow.

How do you like this so far? ...

In future posts, we'll look into testing and more complex rules and examples. In the meantime, if you're bored and looking for simplicity, checkout the minimally minimalistic version we're working on, at

Stay lean!

What's under the hood? The more infrastructure you have, the less work you do, so here we have:

  • an external DSL parser using scala parser combinators, which turns these mocks and rules into asynchronous execution units
  • a few Akka actors for asynchronous execution, so tests can run in parallel
  • the play framework for requests and visuals
  • mongodb to store the content and the fiddles
  • etc

Mocking cathedrals

Other ways to create a runnable microservice mock, are traditional coding adventures:

  • spend the next hour setting up sbt or maven projects, writing code, firing up development workbenches and create a few dozen classes
  • spend the next hour creating a full node.js dockerized service from scratch
  • use tools such as MuleSoft:

For sure, you would also get a lot of infrastructure already setup for the actual implementation, like project and dependencies and artifacts and such. But we'd also introduce versioning and dependencies issues very early in the development of the other services.

Not only that, but often, many services are 3rd party services we'll expect from someone else. Some will be implemented by other teams, in Ruby or Node... we can't impose our technology on them, so we'd need to dockerize or otherwise pack our different builds for them to run our mocks - or mock theirs, for which, since they will deliver them eventually, there it no point investing much in infrastructure.

There are some online options, such as MuleSoft's API designer with mocks, which are quite a bit faster. There's also a number of API instrumentation websites that allow mocking. One issue there is that they are... well, online.

I don't jump to writing code right away (well, I do, but that's not the point) but instead, I mock things up on paper or in a designer, using Sequence diagrams and such, to make sure things hold together. Only when happy do I start assigning and/or developing the different pieces.

By: Razie | 2017-04-15 .. 2017-05-12 | Tags: post , dsl , microservices , reactive |    

See more in: Cool Scala Subscribe

Viewed 455 times ( | Print ) this page.

You need to log in to post a comment!