Allow integrations with pluggable services

While working at REDACTED, I reported the following issue.

It’s quite stressing to bounce from one broken integration server to the next.

• I started developing against the official OpenShift integration server, then against some machine directly managed by the supervisor of the Back end engineer with whom I was working, then against this engineer’s own machine, and then changing from one to the other as the wind blowed.
• Each time, except during short periods of less than a day, a problem arose. Now a required service is not running, now there are no data to show, now the current user does not have needed permissions, now you have to pass groupName to the endpoint instead of name, and on and on.

There are many important features that a sane integration server should have.

• minimize deployment time of any service to a bunch of seconds
• maximize server’s robustness by allowing access to all necessary services
• offer both real and mocked responses (given that Back end knows when to use the former or fall back on the latter)
  • mocked responses would have a special header listing mocked endpoints used
    • example: Mocked = ['ENDPOINT-1 ID-X', 'ENDPOINT-2 ID-Y', ...]
      • Why the IDs? Because they would allow mocked workflows. (see below)
  • requests would always allow a special header to get specific mocked responses back; mocked responses would be documented elsewhere by Back end, and their ID would allow the Front end to mock flows
    • example: Mocked = ['ENDPOINT-3 ID-Z']
      • Use case: it’s possible to mock a search / results / details workflow with the following two mocked requests:
        1. Request: Mocked = ['bookResults forAuthor_JKR'] to run after the user clicks a Search button;
        2. Request: Mocked = ['bookDetails forBook_HP1'] to run after the user clicks a book title.
  • thus:
    • a request with a mocked header would always get a mocked response with at least as many mocked services as requested.
    • a request without a mocked header could always get a mocked response, according to services’ availability.

Each Back end programmer should never program locally but against a virtual private server. He would be able to

• generate a new clean instance of a server from a preconfigured official image,
• push to it the service he is developing and its changes, as many times a day as needed,
• connect his server to the load balancer hub without any time consuming tasks,
• setup autoreboot after a crash, also using a previous version as a fall back.

That setup would allow Back end programmers AND Front end programmers to smoothly do their job. By making the Back end a virtual API, since the inception of a service, by means of mocked responses, both teams of programmers can work independently from each other because the virtual API keeps running even when real services are being developed, fixed, or maintained.