Skip to content

Conversation

@serranoio
Copy link
Contributor

@serranoio serranoio commented Feb 10, 2025

Changes:

  • mockMode & hardValidation are introduced for individual paths as mockModeList & hardValidationList
  • added ui/assets into .gitignore

Motive:

  • We want to gradually roll out compliant APIs so we want to validate only specified endpoints.
  • We want up-to-date mock data based on the OpenAPI spec, and it is only possible to mock compliant endpoints.

The documentation needs to be updated now. I don't think the docs are open source. Is there anyway I could change it?

Please feel free to nitpick the entire MR! I genuinely want to see the best. Even if they are small nitpicks that don't really matter, I genuinely appreciate every perspective 🙏

@serranoio
Copy link
Contributor Author

serranoio commented Feb 10, 2025

simply add this line in your config for mock mode to be enabled for /v1/enshittification

mockModeList:
    - /v1/enshittification

@akash4393
Copy link
Contributor

akash4393 commented Feb 11, 2025

Can we code it such that mockMode is a boolean property defined for each path definition inside the paths section. So something like

paths:
  /v1/enshittification:
    mockMode: true

@serranoio
Copy link
Contributor Author

serranoio commented Feb 11, 2025

Can we code it such that mockMode is a boolean property defined for each path definition inside the paths section. So something like

paths:
  /v1/enshittification:
    mockMode: true

I agree that this would be ideal, the problem is that I tried creating a test as such ^, and it wouldn't work. My assumption was that the paths section was made for pathRewrites. Any other configuration for paths go under their own configuration section like pathDelays or ignoreRedirects

@daveshanley
Copy link
Member

Can we code it such that mockMode is a boolean property defined for each path definition inside the paths section. So something like

paths:
  /v1/enshittification:
    mockMode: true

I agree that this would be ideal, the problem is that I tried creating a test as such ^, and it wouldn't work. My assumption was that the paths section was made for pathRewrites. Any other configuration for paths go under their own configuration section like pathDelays or ignoreRedirects

I designed it so we don't overload configurations with configurations and we end up with a DSL for a config. I think keeping this as a separate configuration is the right design, it makes the config more verbose, but it keeps it clean.

Copy link
Member

@daveshanley daveshanley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any comments or feedback. Sorry, PR is clean and it does exactly what is required of the feature and it follows all the existing designs in place.

@daveshanley
Copy link
Member

There is a test failure, it could be due to an out of date libopenapi-validator or libopenapi dep.

The description n in the https://api.pb33f.io/wiretap/giftshop-openapi.yaml changed from `A t-shirt with the pb33f logo on it`-> `A t-shirt with the pb33f logo on the front`
@serranoio
Copy link
Contributor Author

There is a test failure, it could be due to an out of date libopenapi-validator or libopenapi dep.

It was due to an update in the https://api.pb33f.io/wiretap/giftshop-openapi.yaml spec. I did still bump the deps tho 👍 ⚡

@daveshanley
Copy link
Member

docs updated. good to go!

@daveshanley daveshanley merged commit 8d89429 into pb33f:main Feb 12, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants