Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow libraries to define their own facilities #59

Open
benhalstead opened this issue Jul 2, 2020 · 0 comments
Open

Allow libraries to define their own facilities #59

benhalstead opened this issue Jul 2, 2020 · 0 comments

Comments

@benhalstead
Copy link
Member

Summary

Allow third-party library developers to create facilities that will behave in similar way to Granitic's
built-in facilities:

  • Default configuration and component definitions burnt into the application executable
  • Earlier access to the IOC container
  • Enabled and disabled via the Facilities.FaciltyName config path
  • Dependencies on other facilities can be declared

Background

Third party libraries for Granitic applications can provide code and component definitions which are linked to the application during the grnc-bind phase of the build process via a command line argument giving the absolute path to the
library code. This quickly gets unwieldy with more than a couple of dependencies and has a number of other problems:

  • Build scripts need to know absolute paths of libraries on disk (even if the library was downloaded via a go.mod file)
  • Default configuration cannot be included in the complied executable (must all be provided at run time)
  • Components do not have programmatic access to the container

The solution to this problem is to allow libraries to declare themselves as defining one or more facilities. grnc-bind will then scan all first-order dependencies in an application's go.mod file to see if they contain facilities and include those facilities (code and default configuration) in the generated binding file.

Implementation

A library will have a folder facility at the top level. If this folder contains a file facilities.json (or .yml) the library will be considered to have one or more facilities.

The default configuration for the facilities will be expected to be in either facility/config.json or facility/config/*json (or YAML equivalents)

The component definition for the facilities will be expected to be in either facility/comp.json or facility/comp/*json (or YAML equivalents)

The facilities.json file will look like:

{
  "FacilityNameA": {
    "FacilityBuilder": "package/type",
    "DependsOn": ["other", "facilities"],
    "Enabled": true
  },
  "FacilityNameB": {
    "FacilityBuilder": "package/othertype",
    "DependsOn": ["other", "facilities"],
    "Enabled": false
  },
}

For example:

{
  "RequestProfiler": {
    "FacilityBuilder": "profiling/FacilityBuilder",
    "DependsOn": ["HTTPServer"],
    'Enabled": false
  }
}

Where

  • FacilityBuilder is a type in the library that implements (TBD)
  • DependsOn is an array of the names of the other facilities (internal or third party) that must be enabled in order to use this facility
  • Enabled is whether the facility defaults to enabled or disabled

Compatibility

  • Requires major version number change: No
  • Requires specific Go version: No
  • Requires rebuild of grnc-tools: Yes
  • Requires reference documentation update: Yes
benhalstead added a commit that referenced this issue Sep 14, 2020

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
benhalstead added a commit that referenced this issue Jan 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant