Hypnotoad router vs dynamic configuration

[daleif]

I have an app that in production runs under hypnotoad, nice and smooth.

I have a small issue with it though. It has two configurations one static (the normal yml file) and one dynamic stored in a DB.

My routing table for the normal users depends on settings in the dynamic config. (when we are in mode A users can access certain routes, mode B other routes etc).

The problem is that the routine table does not update correctly when we change modes using the web app it self.

What is the proper approach to a configuration like this other than physically reloading hypnotoad from the cli?

[jhthorsen]

Maybe you can try this after changing the routing table:

$app->routes->cache(Mojo::Cache->new);

You can however change the routing table as much as you want until the first request (iirc), but the order of the routes are significant, so if you have a catch-all route then it must be after the dynamic routes from the database.

[daleif]

That might be the one. I have our catch-all routes at the very end, so that should not matter.

[daleif]

Hmm, can we set that cache from within a controller? And isn't that the main problem here. When we change the dynamic config (aka updates the db), we need to flush all the cached routes in all workers (unless I'm mistaken, not entirely sure if the router lives in the main process or in the workers)

[jberger]

I'm pretty sure you're not supposed to change the router after the application starts. Probably why you're using hypnotoad, to restart the app. Honestly if you need that level of dynamism in your routing I'd probably just use a wildcard route and use that to dispatch from your own code

[daleif]

Hmm, that's annoying. It works nicely with morbo ;-)

Basically we are routing peoples entry page to different stuff depending on which mode we are in. Some modes even don't let non-admins have access.

It was nice to have that the "forbidden" end destinations give 404 when you are in the wrong mode.

I'll see if we can design it differently, hopefully without having to add too many checks for "no you do not have access in this mode"

[daleif]

You're right, the startup method should be thought of as being executed only once. So no dymanic stuff can happen there, that needs to be moved into controllers.

So as you said we been to build our own dispatcher and add a check to relevant controllers such that users get a 404 if they are not allowed in this controller in this configuration mode.

Not to hard to do.

I think this executed only once is mentioned in a single sentence in the documentation somewhere.