Update custom-binary example to trigger migrations#256
Conversation
The `example/custom-binary` uses the `trailbase::api::serve` function, which starts the services but don't trigger the boostrap user migrations itself. Reverse enginering how the `cli::run` command works, it seems it's triggered by `Server::serve` function instead. This commit updates the example code to use the `Server:serve` function to ensure initial migration logic is included on the custom binary.
|
I'm sympathetic to bootstrapping user-defined migrations and reducing the divergence between Server::serve and api::serve. However, as it stands an example that doesn't work is worse. It's not trivial to just inject a router due to the dependence of AppState via CustomState. We'd have to inject a builder (with all the generic nonsense that it brings to ServerOptions) or we'd need to pull out the AppState consruction or we'd need to add another Server livecycle, or .... Let me sleep over it. |
|
Thanks for replying. No need to rush on it, and feel free to close it also. I was more keen to report the finding of migrations not being triggered by the example in case someone else attempts it. |
…ssing a custom router that gets merged into the server, update the `custom-binary` example, and remove divergent `api::serve`. The latter allows custom binaries to behave more consistently with the main trail binary. This change is motivated by #256. Thanks @bltavares 🙏. WARN: This is a API breaking change and warrants a major version update.
I appreciate it when folks step on my toes 🙏. I went the long (and hopefully most principled) way of pulling out the AppState construction. Take a look at https://github.com/trailbaseio/trailbase/blob/dev/examples/custom-binary/src/main.rs#L48 |
|
Nice! I like the proposed API, seems much easier to add routers without exposing the |
2 participants
The
example/custom-binaryuses thetrailbase::api::servefunction,which starts the services but don't trigger the boostrap user migrations
itself.
Reverse enginering how the
cli::runcommand works, it seems it'striggered by
Server::servefunction instead.This commit updates the example code to use the
Server:servefunctionto ensure initial migration logic is included on the custom binary.
Note: the current example fails in
debugmode, as it attempts to accessUserfrom thetrailbaseextractor, but there is anassert!informing thatthe
CookieManagelayer is not installed.It should be possible to fix it by adding the
CookieManagelayer as well onthe custom router, but maybe a better fix would be to pass in an
custom_routeronServerOptionsto be merged and use the same shared layers.