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

feat(components): components introduction #52

Closed
wants to merge 1 commit into from
Closed

feat(components): components introduction #52

wants to merge 1 commit into from

Conversation

pbrzostowski
Copy link
Contributor

@pbrzostowski pbrzostowski commented Oct 31, 2018

So, basically we have dropped missy file and changed our service configuration implementation, but still it really looks odd to me and somehow not convenient. I think that really we should just be just using an environment variables as a configuration part for our services. On the other hand I heard about missy controller that needs to get information about those configurations...

This is my proposition how we can achieve similar functionality with easy testing (Environment is an interface) and very convenient components introduction and usage.

New flow will looks:

  1. Any new component should have init() function (for consistent should be in a component.go file). There it should register a component and set any default configuration variables. I have drop ped the internal name and info about optional/mandatory because I can't se any needs for that really. Please give a feedback if this is really needed for us (can be introduced). Imo each new component should register default variables in case that os env. var is not set.
    I have added Info func and use it at end of component init() just for a nice print of component info. This way at service start we will have a nice description about components.

Service is a component too. Probably it should be called server and be used as component...

  1. I've also introduce options func and new way for creating service service.NewWithOptions(name string, options ...OptionFunc). This way we are be able to implement any arbitrary option as a func and use it.. It is more extensible this way.

I really want to improve our work with a missy and it's configuration. I know that components and it's configurations (env. variables really) are needed for our missy controller that is not implemented yet. I can not have a full spectrum of it, so this implementation will be lack of important stuff. If so, please give a feedback for me.

Any feedback and discussion is appreciated. Please @microdevs/core let's have a talk and improve missy. It is our core component in our services. We should try to implement it in right way.

@levrik levrik requested review from slot and a team November 5, 2018 12:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant