search

cognitect-labs / vase

Data driven microservices
Eclipse Public License 1.0
374 stars 40 forks source link

Consider change to descriptor files #42

Open mtnygard opened 7 years ago

mtnygard commented 7 years ago

Description

Right now, the top level of descriptor files has the keys :activated-apis, :datomic-uri, and :descriptor. Two of these are much more like environment-specific configuration, specifically :activated-apis and :datomic-uri.

Also, I've found it challenging to get the Datomic URI from the descriptor file to use in any other non-Vase interceptors in my application. (The Vase template doesn't offer any place to get access to the connection that's created for the standard DB interceptor.)

Proposal

This proposal has three parts:

  1. Restrict the descriptor file to just the contents that are currently under the top-level :descriptor key.
  2. Adjust the Vase template to look for a separate config.edn file for the system configuration.
  3. Adjust the top-level API functions vase/routes and vase/descriptor-facts to just take what is now the contents of the :descriptor key. vase/routes should take one new parameter with a map for configuration.

Considerations

As a library, Vase should be silent on the issue of how applications will load their config. It should make no assumptions about whether config comes from a file, environment variables, ZooKeeper, or anything else. When config is needed, Vase functions should just accept a maplike value.

This is a breaking change, so it would be better to do this before we cut release 1.0.

ohpauleez commented 7 years ago

The top-level vase functions accept multiple descriptors to be passed in, allowing someone to define services (via :descriptor) and then use different "descriptor chunks" per environment, which specify DB info, activated apis, etc. This approach is more or less the combination of your (2) item and "Considerations" section (since the top-level Vase API is all value-oriented).

You point out one problem I've been thinking about for some time now - seeing/accessing descriptor values, from within application pieces (action literals, interceptors, etc). I think this needs to be addressed and I have some ideas.