by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jon Stockdill
    @jon077_twitter
    Totally understood. Enjoying a cup of coffee and glad to lend a helping hand.
    Carolyn
    @carolstran

    Oh oops merged one before I saw that you’re planning to close and combine. I’ll wait 😇

    I’m also drinking coffee and doing some relaxed coding today ☕️

    Jon Stockdill
    @jon077_twitter
    No worries, I will update. Thanks for letting me know.
    Jon Stockdill
    @jon077_twitter
    Ok, all set now.. meeshkan/hmt#210 my MD editor confused me when it updated the Table of Contents automatically.
    Now, time to try out hmt ;)
    Jon Stockdill
    @jon077_twitter
    Hey friends, I have been digging into OpenAPI v3 and my goal is to specify mocks in the spec. I liked the idea of prism, but digging in I find a flaw. The examples are for schema objects (parameters, request, response, etc), there is no MOCK!
    I wonder what you think of that and the concerns. I know hmt is designed to collect, build, mock and you chose to keep the jsonl and spec separate
    My thought was to add an "x-mocks" schema object to the PathItem Object in the OAS spec, and then keep a list of http-types under that...
    https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md#specificationExtensions
    and
    https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md#path-item-object
    Then I can have the spec and mock examples in the same file.
    A good reason to keep them separate is it could ballon the size of the spec file and confuse it....
    Maybe an alternate approach is to look to a IDE that helps create the mocks using the spec as a linter...
    Do you know of any products that do that?
    Jon Stockdill
    @jon077_twitter
    Good morning, everyone.
    Carolyn
    @carolstran
    Hello! Stuck in some meetings, but let me dig into this after. Sorry for the delay 😁
    Carolyn
    @carolstran
    I'm also going to ping @mikesol because he has a lot of knowledge in this area (esp comparing different tools) and opinions on the various approaches.
    Mike Solomon
    @mikesol
    Hi @jon077_twitter ! Adding mocks to the spec is a great idea. OpenAPI has an example object for this sort of thing if you want a simple mock. For more complex stuff, I'd recommend leaving it out of the spec.
    Not because it'd get too big, but because the representation would require logic that itself would need a DSL, and this is tough to represent in a universal/shareable manner.
    Jon Stockdill
    @jon077_twitter
    @mikesol - Thanks for chiming in. I am coming around to that opinion. I like the schema of http-types over the other structured ways of representing HTTP. I considered documented using the protocol, but will try to mock a large system to see how it feels.
    Does Meeshkan have any tools/plans to validate http-types using a schema?
    I don't like the OpenAPI example object, it is under the request/response, so you can give an example for one side of the API, but not the "pairs" http-types and hoverfly pairs (https://docs.hoverfly.io/en/latest/pages/keyconcepts/simulations/pairs.html) offer
    Mike Solomon
    @mikesol
    @jon077_twitter could you describe the use case a bit more? Would the idea be to validate that an http-types req/res pair conforms to an openapi schema? Would this need to be done in-memory or from a cli?
    Jon Stockdill
    @jon077_twitter
    @mikesol - Apologies for not getting back to you.

    Would the idea be to validate that an http-types req/res pair conforms to an openapi schema?

    Yes. Precisely.

    Would this need to be done in-memory or from a cli?

    It should be done whenever the http-types are read to be used.

    Let me know if I can help or you have any questions. I am continuing my investigation by generating a server using openapi generators, then looking at how I can develop tools to build a virtualized server quickly.
    Mike Solomon
    @mikesol
    What is the use case when they're read/used?
    (meaning when the http-types objects)
    Jon Stockdill
    @jon077_twitter
    For me, I want to iterate in the API design phase, building a mock server to create working prototypes
    that can be early-stage testable products
    and perhaps as service virtualization for clients
    Mike Solomon
    @mikesol
    Just so I understand, is the flow that you are iterating, recording the traffic while iterating, and you'd like that traffic to be incorporated into the mock of the server so that the mock seems more realistic?
    Jon Stockdill
    @jon077_twitter
    For my use case, I was looking for more of writing the requests / responses rather than recording. I leaned away from HMT, as it's primary use case is for recording/ mocking
    But I did really like HTTP types as a spec
    I don't like how openAPI only has examples of req/resp, and no "pairs" like http-types offers
    Mike Solomon
    @mikesol
    Got it.
    I would recommend using the json lines format. That is what hmt does internally, and the output of hmt is just a jsonl file of http-types.
    Jon Stockdill
    @jon077_twitter
    100%
    I like that as well.
    All the projects are well-designed, I appreciate all the work. Meeshkan has a great vision,.
    Mike Solomon
    @mikesol
    Then, to create a spec for your mock server, you can use: hmt build --input-file path/to/recordings.jsonl --mode gen
    https://github.com/meeshkan/hmt#building-modes
    This will produce an openapi spec that can be used by hmt mock or any mocking tool that accepts openapi (ie prism).
    Thanks for the kind words about the project! It's great to know that it's useful for your work.
    Jon Stockdill
    @jon077_twitter
    Totally. The vision is soo spot on. Record the traffic, mock the dependencies, then use AI to exercise a large percentage of the code base.
    It just makes sense. I have a friend who was really into this area. I shared it with him
    I have to run now. Cheers and have a good day!
    Mike Solomon
    @mikesol
    Same to you!