|
4 | 4 |
|
5 | 5 | = Dropshot
|
6 | 6 |
|
| 7 | +== A fork in the road |
| 8 | + |
7 | 9 | This is a fork of https://github.com/oxidecomputer/dropshot[Oxide Computer's Dropshot crate].
|
8 | 10 |
|
9 | 11 | Oxide's crate is awesome and probably the best rust crate for managing a REST API with automatic OpenAPI generation to date.
|
10 | 12 |
|
11 | 13 | This fork is because I wanted slightly different design decisions than the crew at Oxide went with. The main differences
|
12 | 14 | I added are:
|
13 | 15 |
|
14 |
| -* Allowed routes to overlap, with the more specific route winning over less specific routes(those with path vars). (And |
15 |
| -when both routes are specific then we simply choose the one that was registered first.) |
16 |
| -** Oxide discussion here: https://github.com/oxidecomputer/dropshot. |
17 |
| -** My motivation is because I love keeping everything in a single binary and it just looks better for my frontend |
| 16 | +* Allowed routes to overlap, with the more specific route winning over less specific route(those with path vars). |
| 17 | +** This is similar to https://go.dev/blog/routing-enhancements)[Go's new routing enhancements]. (And it |
| 18 | +intuitively makes sense). |
| 19 | +** https://github.com/oxidecomputer/dropshot/issues/199[Oxide discussion on route overlapping here]. |
| 20 | +** The motivation is because I usually keep things in a single binary and it just looks better for my frontend |
18 | 21 | to be accessed at `https://myapp.com/` and my api to be accessed at `https://myapp.com/api`. Due to the overlapping
|
19 |
| -restriction the frontend previously had to be at something like `https://myapp.com/-/`. |
20 |
| -** The drawback is without proper testing you can have overlapping routes that don't follow the pattern of access |
21 |
| -you thought they would. My solution to this is just good tests. |
22 |
| -** I also lowered some of the logging levels. Typically I run my dev terminal at `DEBUG` log level and like it so |
23 |
| -that there is more information than I would run in production but not a deluge of it. The logging levels previously |
24 |
| -were all mostly at the debug level making actual dev signal hard to get. |
25 |
| - |
| 22 | +restriction the frontend previously had to be at something like `https://myapp.com/-/`. Some say this is bad URL design |
| 23 | +but the tribe has spoken. |
| 24 | +** There are two drawbacks to this approach: |
| 25 | +*** If you make overlapping routes mistakenly, you might be routed to a handler that you did not expect. The only |
| 26 | +way you find this out is through thorough testing. |
| 27 | +*** Currently because of how specificity matching works we don't do backmatching. That means that if we have two routes |
| 28 | +registered: `/foo/bar` and `/{slug}/bar/lol`, A request intended for path `/foo/bar/lol` will fail with a 404. |
26 | 29 | * Moved the slog logger to use tracing instead.
|
27 | 30 | ** All my crates use tracing and I've been having a really good time with the tracing ethos and implementation.
|
28 | 31 | ** It's also used by a lot of core rust crates, seems to be pretty well supported, and has good async support.
|
29 | 32 | ** First I attempted to create a https://docs.rs/tracing-slog/latest/tracing_slog/[slog drain that converted between the two]
|
30 | 33 | but the code felt like a hack and didn't map key/value pairs very well.
|
31 | 34 | ** Software philosophically I don't think a lib focused on REST API ergonomics should be handling log output or
|
32 | 35 | configuration, so I removed some of those pieces.
|
| 36 | +** I also lowered some of the logging levels. Typically I run my dev terminal at `DEBUG` log level and like it so |
| 37 | +that there is more information than I would run in production but not a deluge of it. The logging levels previously |
| 38 | +were all mostly at the debug level making actual dev signal hard to get. |
33 | 39 |
|
34 | 40 | * Various other small quality of life changes.
|
35 | 41 |
|
36 | 42 | Since the two changes above are largely non-backward compatible changes, I created
|
37 | 43 | this fork instead of trying to get these merged upstream.
|
38 | 44 |
|
| 45 | +== Regularly scheduled programming |
| 46 | + |
39 | 47 | Dropshot is a general-purpose crate for exposing REST APIs from a Rust program.
|
40 | 48 | For more, see the https://docs.rs/dropshot/[online Dropshot documentation].
|
41 | 49 | You can build the documentation yourself with:
|
@@ -69,3 +77,6 @@ It's early, and we may find we need richer facilities in the framework. But we'
|
69 | 77 | == Examples
|
70 | 78 |
|
71 | 79 | To run the examples in dropshot/examples, clone the repository and run `cargo run --example [example_name]`, e.g. `cargo run --example basic`. (Do not include the file extension.)
|
| 80 | + |
| 81 | +Since we've moved to tracing, you can turn on logging for each test by uncommenting the tracing_subscriber implementation |
| 82 | +inside each example. |
0 commit comments