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 http://www.dieselapps.com to create a project or checkout the embeddable OSS at github.
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.
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 www.dieselapps.com.
Stay lean!
What's under the hood? The more infrastructure you have, the less work you do, so here we have:
Other ways to create a runnable microservice mock, are traditional coding adventures:
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 and Postman, which are quite decent for mocks, but you can't add more than just simple mocks there - with diesel, you can incrementally grow complex logic via rules. 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. Diesel is a mocking framework for microservices that actually work...