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
    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!
    Tomer Rozen
    @TomerRZN
    Hey guys!
    I tried to use hmt to build a openapi spec from my http recordings (jsonl)
    I wonder if maybe i made a mistake with the creation of the jsonl file
    The error is AttributeError at hmt.build.paths._dumb_match_to_path
    Does that sounds familiar to anyone?
    Mike Solomon
    @mikesol
    Hi Tomer! Would you be comfortable sending an anonymized version of the error to this chat? That may provide more context. Anonymized jsonl would be even better if possible. Thanks!
    Tomer Rozen
    @TomerRZN
    I've created an issue with anonymized version of the traceback here:
    meeshkan/hmt#212
    Tomer Rozen
    @TomerRZN
    This might be a problem with my jsonl since it did work for me with the pokeapi.jsonl example
    I will anonymize it and send here thx!
    Tomer Rozen
    @TomerRZN
    full_flow.jsonl
    Mike Solomon
    @mikesol
    Thanks! Our team will look at it and let you know what we find
    Tomer Rozen
    @TomerRZN
    Thanks Mike!
    Much appreciated.