MisterD
Phoenix - New Route from User Input - Adding Route Programmatically
Hi,
I was thinking about simple user settings for Permalinks.
Something like Wordpress has: Customize permalinks – Documentation – WordPress.org
The question is - how to make same behaviour in Phoenix ?
In case of predefined route structures - everything is clear, you simple make predefined routes in advance.
But what about custom one ?
- How to make a new route structure from user input ?
- How to add a new route programmatically ?
To my understanding the routes are build during compilation time, but does it mean it is not possible to create during runtime ?
If so then, what would the solution ?
- Load routes from DB during compilation time and then if new routes are added - restart everything ?
Any ideas or an advice is very much welcome !
Marked As Solved
idi527
![]()
There wouldn’t be any performance issues if done correctly. I have a plug for webhooks that are generated at runtime to which I forward from the phoenix router module.
It works roughly like this
# in the router.ex
scope "/" do
# ...
forward "/webhooks", MyAppWeb.Plugs.WebHooks
end
# in plugs/web_hooks.ex
def call(%Plug.Conn{path_info: path_info, params: params} = conn, _opts) do
if handler = get_webhook_handler(path_info) do
handler.handle!(params)
end
send_resp(conn, :ok, [])
end
Also Liked
chrismccord
I think you misinterpreted. You may be thinking of responses I have had to folks asking for matching on regex patterns as “wildcards” as me denying those kinds of matches because that would be much slower since we can’t pattern match, but a wildcard match, ie get "/*" or get "/foobar/*" will be super fast and just as fast as any other route match. As other have said, you can get what you by a either a wildcard forward match in the router, followed by your own custom lookup and dispatch code, which calls the appropriate controller (or plug), ie controller.call(controller.init(some_action))
easco
A Plug accepts a Plug.Conn and returns a different Plug.Conn resource.
Part of the Plug.Conn structure is the “path_info”. Your plug could look at the Path Info and decide what function to call, pass he connection to it, and halt the propagation of the connection (so the the router never sees it).
Or, it could return a new Plug.Conn, with different path_info, let it propagate to the router, and the router could use its regular mechanism on the new path_info.
easco
Just a thought off the top of my head. The Phoenix Router is “just a plug”. It tends to be the Plug at the end of the pipeline, but it is still a Plug. So it seems you could develop a Plug that looks up a new route in a dynamic data source (an ETS table, or database).
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








