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

Per-endpoint configuration #109

Merged
merged 28 commits into from
Jan 17, 2019
Merged

Per-endpoint configuration #109

merged 28 commits into from
Jan 17, 2019

Conversation

tirr-c
Copy link
Collaborator

@tirr-c tirr-c commented Dec 14, 2018

Description

This PR adds per-endpoint configuration mechanism.

Each configuration item is represented as a value of its own type. Items can be applied to endpoints and (sub)routers, and child configuration inherits from that of parent. The point when config is called does not matter; when the router setup ends, all configuration items of the router are applied to the children (except overridden).

The first three commits implements the feature with serde and toml. The other commits use a minimal, custom typemap for configuration.

Motivation and Context

Resolves #5.

Currently we don't provide any way to configure middleware, extractors etc. Using configuration, we can adjust various aspects of how components of Tide work, like limiting request body size.

How Has This Been Tested?

  • An example application (examples/configuration.rs). Tested with HTTPie and works as expected.
  • New unit test, some for Configuration itself and some for Router.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
    • Some function signatures have changed.

Checklist:

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Copy link
Contributor

@bIgBV bIgBV left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome! I have left a few questions asking for some more clarification, but you basically answered all the questions I had regarding how to go about sharing this state across this App. I can't stress on the fact that PR taught me a bunch of new things around the Rust type system :)

I can already see how to integrate the logger into this.

examples/configuration.rs Show resolved Hide resolved
src/configuration.rs Outdated Show resolved Hide resolved
src/middleware/mod.rs Outdated Show resolved Hide resolved
@bIgBV
Copy link
Contributor

bIgBV commented Dec 15, 2018

Looks good to me! I'd like to build on top of this to get a default config set up. @tirr-c do you think I should create a branch off of your branch, or wait until the PR is merged after @aturon can have a chance to look at it?

@tirr-c
Copy link
Collaborator Author

tirr-c commented Dec 16, 2018

@bIgBV Go ahead! It would be really helpful if I can get some feedback about the API design.

* This is because the Confiugration type is a App global sharable
TypeMap which is avaiable across both middleware and endpoints.
Therefore, this can be used to store arbitrary types and not only
configuartion.
* Tis commit renames all occurrances of Configuration to Store and
updates the parameters and struct field names appropriately.
* Have simple hook into the App by the way of the `setup_configuration`
method. This is pretty basic rightn now, but can be the point of entry
for hooking in custom configuration.
//! Types for managing and extracting configuration.

use std::any::{Any, TypeId};
use std::collections::HashMap;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A possible performance improvement here would be to use the hashbrown crate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that currently being evaluated to be used as the default HashMap implementation in the std? If that's the case then do you think it's a good idea to replace it right now? (Though to be fair, it might be at least a few releases away..)

Copy link
Collaborator Author

@tirr-c tirr-c Jan 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I heard that hashbrown is used only in rustc, not libstd.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I missed this. But yeah, it's landing in libstd; people made a PR during RustFest Rome for this!

src/configuration.rs Outdated Show resolved Hide resolved
Copy link
Member

@yoshuawuyts yoshuawuyts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really good! It's very thorough, and I think we might be able to merge this as-is. Keen to try this out!

edit: also wanted to mention I definitely learned some new things reading this code. Thanks for putting in the work @tirr-c!

@tirr-c
Copy link
Collaborator Author

tirr-c commented Jan 9, 2019

There is a PR targeting my branch, tirr-c#1, that @bIgBV have worked on renaming things and adding app configuration as a configuration item. I've approved the PR but I haven't merged that since I was busy. I'll merge it and add some docs. Can you please review this again then, @yoshuawuyts?

@yoshuawuyts
Copy link
Member

@tirr-c done! -- I think that patch looks pretty good! Don't have any blockers; green light from me! ✨

@bIgBV
Copy link
Contributor

bIgBV commented Jan 9, 2019

The build is failing on a couple of fairly trivial clippy lints, I can make the changes, but I'm not sure if I can and/or which branch to change.

@tirr-c
Copy link
Collaborator Author

tirr-c commented Jan 9, 2019

@bIgBV No worries, I'll handle those!

src/app.rs Outdated Show resolved Hide resolved
@yoshuawuyts yoshuawuyts added the feature A feature that's ready for implementation label Jan 9, 2019
@bIgBV bIgBV mentioned this pull request Jan 9, 2019
src/configuration/mod.rs Outdated Show resolved Hide resolved
@yoshuawuyts
Copy link
Member

Builds are failing because nightly can't be installed rust-lang/rust#57488. I think we should be good to merge once we can get tests to pass!

@petejodo
Copy link
Collaborator

I love this but I have some issues with it that I can't quite put my finger on exactly yet. I guess one issue is the naming of some things e.g. ExtractConfiguration seems odd since other types that implement Extract don't have Extract- prepended. For example, Path isn't named ExtractPath. Now I don't have any thing better to suggest myself since there's already the Configuration type. I'll probably play around with this once it's merged to see what I can come up with.

@bIgBV
Copy link
Contributor

bIgBV commented Jan 13, 2019

So looks like travis was failing on installing nightly in the container. I just restarted the build and looks like whatever issue was occurring a couple of days ago is now solved.

Are there any other blockers for this PR as I want to get another PR open for a default config file and the related supporting code open. Plus once the discussion in #8 reaches some consensus, I'm sure this will help a lot for that as well.

EDIT: Looks like I spoke too soon :( Looks like the build is failing on formatting a dependency. Is that expected?

@yoshuawuyts
Copy link
Member

Travis is passing again, and from the comments there seem to be no blockers. I propose we merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A feature that's ready for implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add configuration (for extractors and middleware)
4 participants