Split yaml config file

[harrysun2006]

Hey Alexander,
My team starts to use stubby4j. It's a lightweight mocking tool and we love its simplicity. Thank you for bringing up this wonderful tool.
However, while we keep adding stub endpoints into the yaml config file, it becomes bigger and bigger. I've done some research around, but couldn't find a feature like "import" or "include" to allow us to split the all-in-one yaml config file into a few smaller yaml files.
I'm wondering is there a plan for such features in the future development?
Thanks,
Harry

[azagniotov]

Hi @harrysun2006 ,

Thank you for the kind words!

You are right - there is one main YAML config file. But, there is an option to use the file key under request or/and response sections in order to "include" large stubbed request payloads or response bodies. I wonder if the following can make your lives easier: https://github.com/azagniotov/stubby4j#file and https://github.com/azagniotov/stubby4j#file-1

Please let me know if the above helped.

Cheers,
Alex

[harrysun2006]

Hi Alex,

Thanks for your prompt response. Yes, the file key is helpful and actually we have already split request and response payloads in separate folders and files on per service/endpoint basis. So the stubby component in our project has a structure like:

• stubby.yaml

request:
  url: /api/service1/endpoint1
response:
  status: 200
  file: service1/response1.json
... ...
request:
  url: /api/service1/endpoint2
response:
  status: 200
  file: service1/response2.json

request:
  url: /api/service2/endpoint1
response:
  status: 200
  file: service2/response1.json

and correspondingly, we have service1, service2 folders and response1.json, response2.json in service1 folder etc. etc.

Our application talks with many downstream services, and the stubby.yaml becomes bloated. So I'm thinking if we have something like below in the main stubby.yaml file:

includes:
  - service1.yaml
  - service2.yaml
  - ... ...
  - servicen.yaml

and then we can define stub endpoints for each service in their own service.yaml sub config file, that will make the code more organised.

I'm keen to know your thoughts on it.

Cheers,
Harry

[azagniotov]

Hi Harry,

I see. Another idea that I am thinking about perhaps I can look into making the --data accept a directory where you can have multiple service*.yaml. Upon load, all those files will be merged into one YAML in-memory, as if there was one main YAML provided.

But, looking deeper into the code, I think I want to explore your idea first. Too much in stubby4j works on the premise that there was one main YAML file loaded

[harrysun2006]

Thanks Alex. That would be great!

[azagniotov]

Hello @harrysun2006

Would you be able to sanity check the new behavior for me? I have tested it manually and through automated functional tests and it seems that app behaves as expected. Could you fork the repo and run:

1. ./gradlew clean integrationTest functionalTest build
2. the JAR to run is under build/libs/stubby4j-7.1.1-SNAPSHOT.jar

Pls create a main YAML file which you pass under --data with the following structure (I adopted your idea):

includes:
   - service-1-stubs.yaml
   - service-2-stubs.yaml
   - ...
   - ...
   - service-N-stubs.yaml

Please note: make sure that the included files are in the same directory as the main YAML file

[harrysun2006]

Hi Alex,

I did some test on build and the new structure, all good except a minor test error under java 11 (no errors when building under java 8):

io.github.azagniotov.stubby4j.AdminPortalTest > shouldMakeSuccessfulGetRequestToStatusPage FAILED
    value of: getStatusCode()
    expected: 200
    but was : 500
        at io.github.azagniotov.stubby4j.AdminPortalTest.shouldMakeSuccessfulGetRequestToStatusPage(AdminPortalTest.java:111)

The project is running well and now the config files are much cleaner.

Great job!

Thanks,
Harry

[azagniotov]

Harry, thank you! I will release the new JAR then soon. Also, thanks for picking up java 11 issue. Will address it separately

[harrysun2006]

Thank you, Alex. Much appreciated!

[azagniotov]

@harrysun2006 pls wait for v7.1.1 to become available on Maven Central in a few hours. Also, I have updated the docs: https://github.com/azagniotov/stubby4j#supplying-stubbed-endpoints-to-stubby

[azagniotov]

Also, @harrysun2006 I am not sure if running in Docker is relevant to your eco system, but just as FYI - there are stubby Docker images in DockerHub: https://hub.docker.com/r/azagniotov/stubby4j

[harrysun2006]

Thanks Alex. We build the stubby4j docker image based on openjdk:11-jre-slim.

[azagniotov]

Got it. I just published another stubby4j image to DockerHub, which is based on zulu-openjdk-alpine-11.0.7-jre (I resolved the failures in tests you observed on JDK 11)