Specific delays per example

[Apoorva64]

In a front-end application, requests to the same API endpoint may exhibit different processing times.

Depending on the duration of these requests, a dynamic display of a spinner or direct rendering of the content is determined.

To facilitate testing and development, a mocked API endpoint is needed, providing responses with varying response times.

We already have an implementation of "Delays" in Microcks but it is per "endpoint+verb".
To add this feature we could add to the "Response" object a delay that is specific to it.
To import the data we could add "OpenAPI Extensions" such as "x-microcks-example" which would be placed at the exemple level and contain the "delay" in the form of a variable.

                examples:
                  laurent_cars:
                    value:
                      [
                          {"name": "307", "model": "Peugeot 307", "year": 2003},
                          {"name": "jean-pierre", "model": "Peugeot Traveler", "year": 2017}
                      ]
                    x-microcks-example:
                      delay: 1000

• when a delay is found in the example level use that delay (x-microcks-example)
• else use the delay found at the verb/operation level (x-microcks-operation)
• else don't use a delay and make the request as fast as possible

[Apoorva64]

An example of the implementation has already been developped here

[Apoorva64]

---
  openapi: 3.0.0
  info:
    title: OpenAPI Car API
    description: Sample OpenAPI API using cars
    contact:
      name: Laurent Broudoux
      url: https://github.com/lbroudoux
      email: laurent.broudoux@gmail.com
    license:
      name: MIT License
      url: https://opensource.org/licenses/MIT
    version: 1.0.0
  paths:
    /owner/{owner}/car:
      get:
        summary: List all cars of owner
        description: List all cars of owner description
        operationId: getCarsOp
        parameters:
        - name: owner
          in: path
          description: Result page wanted
          required: true
          schema:
            type: integer
          examples:
            laurent_cars:
              value: 0
            maxime_cars:
              value: 1
            tom_cars:
              value: 2
        responses:
          200:
            description: Success
            content:
              application/json:
                schema:
                  type: array
                  items:
                    $ref: '#/components/schemas/Car'
                examples:
                  laurent_cars:
                    value:
                      [
                          {"name": "307", "model": "Peugeot 307", "year": 2003},
                          {"name": "jean-pierre", "model": "Peugeot Traveler", "year": 2017}
                      ]
                    x-microcks-example:
                      delay: 1000
                  maxime_cars:
                    $ref: "#/components/examples/maxime_cars"
                  tom_cars:
                    value:
                      [
                        {"name": "Car 1", "model": "Bmw", "year": 2003},
                      ]
  components:
    schemas:
      Car:
        required:
        - name
        properties:
          name:
            description: Name of the car
            type: string
          year:
            description: Build year
            type: integer
          model:
            description: Model of the car
            type: string
    examples:
      maxime_cars:
        value:
          [
              {"name": "123", "model": "Pewpew Moblie", "year": 2000}
          ]
        x-microcks-example:
            delay: 5000

[Apoorva64]

@lbroudoux could you comment on this?

[lbroudoux]

Sure, sorry for the long delay.

I'm concerned about this topic as I'm curious if we're not going too far...

Over these last months, we got requests regarding features usually handled at gateway levels. So if we start implementing more stuff related to delay, performance or something related, we will end up with even more requests for implementing fuzzy response time, chaos monkey features, simulating faults, ... Without a doubt, this will lead us to a more clunky model and feature sprawling that also drive us away from our core concerns.

I'd like to have some other people jumping on the conversation to share ideas and their point regarding such features : what should/shouldn't be handled by Microcks? What should be handled by a gateway user would put in front of Microcks to get more advanced chaos engineering features? I'd really like to get the community input on this...

[Apoorva64]

@lbroudoux i didn't understand the concept of handling the "delays" at gateway levels. Could you elaborate on this>?
To get the community input we could try making a poll on discord.

[lbroudoux]

I was talking about "API gateway" like Kong, Traefik, Gloo that typically offer some kind of chaos engineering features allowing you to declare fault and delay policies on endpoint. We heard about users in the community that put Microcks behind such gateways to offer these features on Microcks endpoints. And it looks as a smart idea to me as it offers best of both worlds (API policies + mocks).

[Apoorva64]

This would mean that we would have external configuration for mocks that is handled by another actor.
To do what is done in this discussion with an API gateway would be to add a specific rule on the url (microcks-url/rest/API_NAME/API_VERSION/THING) and add a specific delay.
Which means that if we change "THING" by using other params the mock won't work as intended. This problem could be easly fixed by using regexes in the API gateways but we would be recoping the OpenApi in the gateway config.

[Apoorva64]

@lbroudoux ?