-
Notifications
You must be signed in to change notification settings - Fork 428
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
GraphQL - Merge master with HTTP handlers config reworked #3646
GraphQL - Merge master with HTTP handlers config reworked #3646
Conversation
Doing maps:find creates the ok-tuple, which means garbage, and also then needs to match on it. It it more efficient to pattern-match on the map key.
Perf/metrics
Pattern match the map key for more efficiency
It will be handled by mongoose_config_handler.
The goal is better separation between specs and utils
API: - config_spec/0 returns the config section spec for all possible HTTP handlers - get_routes/1 returns Cowboy routes for a list of configured handlers There are two optional callbacks: - config_spec/0 returning config specification for the handler, if it has any options - routes/1 returning Cowboy routes, if different from the default All handlers which have options should be listed in configurable_handler_modules/0
Use maps with defaults in the config spec
Use maps with defaults, include all handlers by default
- Use maps with defaults for options
Expect options in a map
- Use maps with defaults - Include all handlers by default New options: - 'handlers' - to choose specific low-level handlers, - 'docs' - to disable docs.
It will be placed in mongoose_http_handler Also: refactor 'store_trails'
- Use maps with defaults - Add new options - Rework test layout after reworking mongoose_client_api config - Remove the custom logic for comparing handler tuples
- Simplify examples to match the defaults in mongooseim.toml - Document the new options: `handlers` and `docs` - Update the list of available handlers
By now we have a pretty printer in the logger, and creating accumulators is a hot operation, so we can skip this field when it is not needed.
Skip pretty-printing of unused accumulator field
Rework HTTP handler configuration
This PR addresses "There is no easy way to reset cache without making new changes into the code. And sometimes cache breaks, because a committer did something wrong". Proposed changes include: Use CI_CERT_KEY_VERSION env variable to change the key externally. Avoid caching invalid certificate data. It should make fixing bugs with certificates a bit easier.
MAM shaper touches
Upgrade mongoose jid
Add transaction async requests
…handlers-config-rerwork
This comment was marked as outdated.
This comment was marked as outdated.
fc10607
to
06c7216
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Codecov Report
@@ Coverage Diff @@
## feature/graphql #3646 +/- ##
===================================================
+ Coverage 81.78% 81.84% +0.05%
===================================================
Files 479 480 +1
Lines 33369 33342 -27
===================================================
- Hits 27292 27289 -3
+ Misses 6077 6053 -24
Continue to review full report at Codecov.
|
06c7216
to
f786e54
Compare
small_tests_24 / small_tests / f786e54 small_tests_23 / small_tests / f786e54 dynamic_domains_pgsql_mnesia_24 / pgsql_mnesia / f786e54 dynamic_domains_mysql_redis_24 / mysql_redis / f786e54 dynamic_domains_pgsql_mnesia_23 / pgsql_mnesia / f786e54 ldap_mnesia_24 / ldap_mnesia / f786e54 dynamic_domains_mssql_mnesia_24 / odbc_mssql_mnesia / f786e54 ldap_mnesia_23 / ldap_mnesia / f786e54 internal_mnesia_24 / internal_mnesia / f786e54 elasticsearch_and_cassandra_24 / elasticsearch_and_cassandra_mnesia / f786e54 pgsql_mnesia_24 / pgsql_mnesia / f786e54 mysql_redis_24 / mysql_redis / f786e54 pgsql_mnesia_23 / pgsql_mnesia / f786e54 mssql_mnesia_24 / odbc_mssql_mnesia / f786e54 riak_mnesia_24 / riak_mnesia / f786e54 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I only added a few comments about items that can be done in a separate PR.
config_spec() -> | ||
#section{items = #{<<"username">> => #option{type = binary}, | ||
<<"password">> => #option{type = binary}, | ||
<<"schema_endpoint">> => #option{type = binary}}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are only a few options here and we shouldn't allow an arbitrary binary, right? Using enum
looks like a better option to me, because it would be validated. Another question: would it make sense to make the endpoint an atom?
%% mongoose_http_handler callbacks | ||
|
||
-spec config_spec() -> mongoose_config_spec:config_section(). | ||
config_spec() -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will need a test in config_parser_SUITE
for this config spec, see the listen_http_handlers_...
test cases for reference.
This PR adapts GraphQL to follow the latest changes in the HTTP handlers configuration. Also, use lower JID fields everywhere.