Project roadmap

Please note that this roadmap is subject to change at any time, as the needs and priorities of the project may evolve over time.

2024 year

Playground in-place config editor

Playground in-place config editor allows users to quickly and easily play with mock service configuration while testing and debugging their API endpoints.

Users will be able to make changes to the configuration directly from the Playground interface, without the need to commit changes into the git repository. This can save time and improve the efficiency of the testing and debugging process.

All actions should be available to be done directly in the playground:

• Edit a mock config
• Edit a request
• Execute a request against provided mock config
• Receive and inspect the resulting response

Url shortener

The need of URL shorteners is to work around the DNS label length limit, which is 63 bytes. Domain name is divided into different labels that are separated by dots. Each label is limited to 63 bytes, which may be less than a combined length of owner, repo, instanceName and ref,

# owner: mockqa
# repo: demo
# instanceName: counter
#
# produces the valid URL

https://counter→demo→mockqa.grpc.qa

# if we add a git branch:
# ref: feature/releaseName/teamName/issue123456
#
# produces the wrong URL: length limit exceeds

https://feature→releaseName→teamName→issue123456→counter→demo→mockqa.grpc.qa

# to be converted into

https://3a4c67ba7c.grpc.qa

Response delays

API calls made over a network can experience delays due to various factors such as network congestion or high server load. To ensure that an application can handle these delays and maintain its functionality, it must be designed to handle such variability and tested under various conditions. It is important to verify that timeouts are properly configured and that the user experience is not negatively affected.

• Fixed delay
• Random delay
• Incremental delay

Stateful scenarios reset API

Stateful scenarios reset API allows you to reset the state of your mock server between test runs. When you configure a mock server for stateful scenarios, the server will retain information about previous interactions with the server, such as the requests that were made and the responses that were received. This can be useful for testing scenarios where the state of the server affects the behavior of the application, but it can also make it difficult to reset the server to a known state for subsequent test runs.

• HTTP DELETE /__admin/scenarios/reset

HTTP/3 support

Support for HTTP/3 in a mock service can be useful for testing and development purposes. HTTP/3 is the latest version of the HTTP protocol, and it introduces several significant changes and improvements over previous versions. For example, HTTP/3 introduces support for the QUIC transport protocol, which is designed to improve performance and security by reducing latency and eliminating the need for separate TCP and TLS connections. HTTP/3 also supports multiplexing and bidirectional streams, which can improve the efficiency of HTTP communication.

Custom state for stateful scenarios

Enabling custom state persistence between method calls will make it possible to handle complex scenarios and make the development of stateful scenarios easier. It will also remove any limits on the use of these scenarios. Overall, this feature will greatly improve the flexibility and usability of the mock service.

Definition:

scenario:
    name: <string>
    requiredState: <string>
    newState: <string>

    # new properties:                        
    initData: <scalar | sequence | mapping> # initial value of a custom state
    newData: <scalar | sequence | mapping> # new value of a custom state
    # scenario data to be accessible using expressions:
    # {{ scenario.data }}
    # {{ scenario.newData }}

Examples:

# unary call
- method: demo.Counter/IncrementCount
  scenario:
    name: counter
    requiredState: started
    initData:
      counter: 0
    newData:
      counter: "{{ scenario.data.counter + 1 }}"
  response:
    body:
      count: "{{ scenario.newData.counter }}"
    status: OK

# client streaming call
- method: demo.Counter/AccumulateCount
  scenario:
    name: counter
    requiredState: started
    initData:
      counter: 0
    newData:
      counter: "{{ scenario.data.counter + (request.stream | sum count) }}"
  response:
    body:
      count: "{{ scenario.newData.counter }}"
    status: OK

# server streaming call
- method: demo.Counter/Countdown
  scenario:
    name: counter
    requiredState: started
    initData:
      counter: 0
  response:
    stream:
      repeat:
        count: "{{ scenario.data.counter }}"
        item:
          count: "{{ scenario.data.counter - repeat.no }}"