clingen-data-model / curator

0 stars 0 forks source link

Parameterize the genegraph endpoints, defaulting to localhost #4

Closed theferrit32 closed 3 years ago

theferrit32 commented 3 years ago

This ticket is being updated.

Current strategy is to use Firebase RemoteConfig functionality to set the proper value for a particular environment. The issue is that this becomes a chicken/egg situation and the app cannot read the proper value for the environment without knowing which Firebase environment it is in. So another file will be added that contains Firebase environment configurations, and which one is selected will be based on the :closure-defines parameter in shadow-cljs.edn called curator.FIREBASE_CONFIG_NAME.

Example:

                :dev {:closure-defines {curator.BACKEND_USE_FIREBASE_CONFIG false
                                        curator.BACKEND_HOST "localhost:8888"
                                        curator.FIREBASE_CONFIG_NAME "clingen-dev"}}

The above will set the backend server API to localhost:8888, and connect to the firebase environment clingen-dev (for authentication or other configurations it may want to look up).

To tell it to use the backend API specified in the clingen-dev remote config, use the following:

                :dev {:closure-defines {curator.BACKEND_USE_FIREBASE_CONFIG true
                                        curator.BACKEND_HOST "localhost:8888"
                                        curator.FIREBASE_CONFIG_NAME "clingen-dev"}}

With curator.BACKEND_USE_FIREBASE_CONFIG set to true, at startup curator.cljs/init will look up the RemoteConfig for the backend host name to use from Firebase RemoteConfig named BACKEND_HOST, and will ignore any curator.BACKEND_HOST specified in the :closure-defines dictionary.

theferrit32 commented 3 years ago

Using this method to tell it which firebase project to communicate but only allows for two options.

shadow-cljs automatically uses the :dev values when shadow-cljs compile or shadow-cljs watch are used, and the :release values when shadow-cljs release is used. I don't see a way to tell it which or specify a 3rd or more options like leiningen profiles allow for. What I am using now is mapping dev->clingen-dev (never deployable to using ci/cd that invokes shadow-cljs release) and release->clingen-stage. For production an explicit :closure-defines override can be made with:

shadow-cljs release app --config-merge '{:closure-defines {your.app/DEBUG true}}'

https://shadow-cljs.github.io/docs/UsersGuide.html#config-merge

We could instead of using :dev and :release in the build, just specify additional builds, like :app, :app-stage, :app-production.

larrybabb commented 3 years ago

@theferrit32 I think you've finished this. is that right?

If not could you tell me where this stands? Feel free to move it to Done or In Progress if appropriate. Any additional updates on it's status would be helpful.

theferrit32 commented 3 years ago

This is done. Most recent change in pull #22

larrybabb commented 3 years ago

@theferrit32 i think it makes sense for you to put all completed items into the "Done" state and I will "Close" them later just so that I can stay on top of all closed issues.

theferrit32 commented 3 years ago

@larrybabb 👍