From initial spikes on this, it's not as straightforward as I'd hoped. Support for vscode just working when requesting to load a git:// url depends on an extension the user may not have - and there are authentication questions on top of that. Similar authentication issues are likely to affect using an https:// url to define the definitions file assuming it's in a private repo and we're trying to use the https://.../raw/... url of the git host. Not to mention, this pushes more responsibility into the IDE which would lead to conflicting experiences in different IDEs in the future.

An alternative approach that I'm considering which might make a lot of sense, is to include the definitions file in a package and distribute it to other 'services'/'repos' via the native package management tools of the programming languages in question.

Consider a bounded context Demo which has three repos:

demo-common
demo-service-a
demo-service-b

As demo-common contains all the common code for the bounded context (possibly some entity definitions? or other domain-specific logic that needs sharing with other services as a library), it actually makes sense that that would be the owner of the definitions.yml file, and that the definitions.yml file should be versioned along-side that code.

If we ensure that the definitions.yml file is included in the published package from demo-common then when demo-service-a and demo-service-b retrieve demo-common via their package distribution tools (e.g. go get, nuget, npm, gem) the definitions.yml file will come down with it.

demo-service-a and demo-service-b could have a vscode workspace settings file that sets the contextive.path setting to point at the package manager's copy of the definitions.yml file.

The challenge with this approach is differences in the way package management tools store the downloaded packages. There are three common options, not exhaustive, but to illustrate the breadth of possibilities:

store directly in the working folder (e.g. npm in node_modules)
1. this is easy - contextive.path can just be set to node_modules/demo-common/.contextive/definitions.yml
store in a global package cache, but copy assets from the package into the binaries folder on build (e.g. dotnet)
1. this is also easy, contextive.path can be set to Demo.ServiceA/bin/Debug/.contextive/definitions.yml (assuming Demo.Common package is setup to include the definitions.yml file correctly by including it in the lib folder)
store in a global package cache, and don't copy assets into the local folder (e.g. go get, python, java).
1. this is a bit trickier, as the location could vary on dev machine to dev machine depending on local configuration, so a workspace vscode setting isn't great. Individuals could setup user-level settings to override, but that is an extra level of friction I'd like to avoid.

A proposal for resolving scenario 3:

Contextive will shell out and echo %contextive.path% and use the result as the file location.

As an example, with go:

In demo-service-a and demo-service-b, set contextive.path to:

$(go list -m -f '{{.Dir}}' org.git.domain/org/demo-common)/.contextive/definitions.yml

Contextive will execute:

echo "$(go list -m -f '{{.Dir}}' org.git.domain/org/demo-common)/.contextive/definitions.yml"

Which on both linux and windows will return the exact path of the file in the package manager's cache.

I'll need to check, but I suspect it will be possible to find similar shell commands for other package managers that will help identify the local path of the package, and thus the location of the definitions file.

Pros

With this approach, a common contextive.path setting could be stored in the workspace, and once the extension is installed, and the common package is setup correctly, Contextive should just work for all developers.
Leverages existing package distribution tools including hosting and authentication (e.g. should work with private package hosts and any source control system).

Cons

Are there security risks of having Contextive execute arbitrary scripts via the echo $() mechanism? Contextive does not run privileged, and it will only be executing scripts that are stored in a trusted and reviewed repository, so perhaps it's ok?
Having to publish a new common package, just to update some contextive definitions.
Harder to update definitions if you identify a need to update them while working in service-a.
May be more challenging when working in a polyglot environment, as service-b may not be in the same language as demo-common and thus wouldn't depend on it via the package management system. As there are no real users with this use case yet, I'm deferring consideration of this scenario until I can get more details of a real-world situation.

Next Steps

I'm proceeding with a spikes to verify the feasibility of this approach, but thought I'd throw it out here for feedback - any thoughts?

Support for shared definitions #36

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions