-
Notifications
You must be signed in to change notification settings - Fork 32
What is the best approach for bootstrapping mock data #4
Description
First off, love the project. I was sitting down to take a crack at something like this when I ran across your project. Thank you.
Second, I'm having trouble using the mock server with a readonly API. I thought the way it would work was the routes would be picked by automagically and data from the swagger model "example" object would be returned. After digging through the code, I see you explicitly register mock data in a file you load from disk. That's fine, but it breaks consistency with the swagger definition and means I need to manually code a server.js file for every new API. Ideally, I'd like to be able to write my spec and kick the API without having to make the spec authors code. Do you have thoughts on the best way to approach this? Some thoughts I had were:
- Use an order of precedence to load the data from the mock file and use that in place of the swagger example definition when present. If no mock file data exists, then use the swagger example data.
- Add a RandomMockDataStore that would create randomized mock objects on demand. This could be specified as an option when starting the server.
- Add a feature in the UI to generate a sample data set from the swagger definition that would be persisted and saved on disk. This would enabled consistent responses after the mock server is restarted.
I realize these are not general problems, but is does speak to the usability of the mock server early on when developing an API. I'm happy to contribute and issue a pull request. I'd like to hear your ideas on how to approach this problem.