Skip to content
This repository was archived by the owner on Apr 11, 2018. It is now read-only.

What is the best approach for bootstrapping mock data #4

@deardooley

Description

@deardooley

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions