respect directory structure about drakov HOT 7 CLOSED

Hey @kosmotaur that actually sounds like a really useful feature 👍

How about including it as an extra option/argument, in addition to the -f option.

from drakov.

Just been discussing this and we are thinking carefully about how this effects our policy of respect the spec files.

I'm starting to think this would bring some confusing behaviour to Drakov and would endanger the simplicity of just obeying what is in the specs.

There is currently nothing stopping you from breaking up your spec files into separate directories as the --file or -f argument takes a glob expression that can load files nested inside a directory/folder structure.

ping @SiCurious

from drakov.

The key reason we cannot use the -f option is that we are not running the Drakov server locally, it is hosted on a company-wide accessible server.
We have a CI pipeline around the blueprints themselves, so that whenever we agree on a change to the APIs, they get deployed automatically. All of them are accessible to the whole company. We cannot at a given point in time just use a glob to now run v1 or anything along these lines. We need all blueprints accessible at all times, so that different clients can be developed and automatically tested against them.
As to the "respect the spec files" policy, that's why this would be an option, so by default you keep your policy, but also allow for flexibility in a larger, industry scale use case.

@SiCurious and @kosmotaur

from drakov.

Are the actual endpoints the same in each version?

Would it possible to run multiple servers?

from drakov.

We could work on a drakov-cluster module, which could spin up multiple instances of Drakov, do the pre-routing and proxy the requests into the respective instance.
Quite a bit of overhead though, so we'll need to consider this vs. forking Drakov if it's a no-go for you.

from drakov.

The drakov-cluster idea is intriguing.

A recent PR that I did added support for using a config file, this will make it easier to load multiple configurations if needed.

This idea appeals to me as it would allow us to keep the basic functionality of drakov the same.

If that is the solution for you guys, I'm happy to work on that for the next release.

from drakov.

@SiCurious @kosmotaur see #72

I'm happy to discuss this in more detail in the new issue that I have created.

from drakov.