c4lliope
Gradually upgrading, phoenix → nex using pluggable routes
I’d like to upgrade my Phoenix app to Nex.
Both of these packages rely on plug as middleware.
Maybe a plug mechanism can help to add new routes in Nex, alongside the earlier Phoenix app.
I imagine this is going to be a common use case.
As is, these seem related:
Mainly asking for guidance from @zhenfeng-zhu, and also opening this discussion to track my progress in my own codebase. (for the mods: we need a category of “Elixir Framework Forums / Nex”!)
As a nearly-real example, my blog is already in Phoenix. I’d like to build commenting using HTMX tags and dedicated Nex file-based routing. Here are two generic processes I can imagine.
Approach 1: Nex-in-Phoenix
- run
mix nex.new nex_app - run
rsync -a nex_app/lib/* phoenix_app/lib/ - start the
nex_appinside of thephoenix_app. - inside the phoenix router,
forward "/nex", to: NexApp.Endpoint - gradually move logic to
nex_appusing file routes.
Approach 2: Phoenix-in-Nex
- run
mix nex.new nex_app - run
rsync -a phoenix_app/lib/* nex_app/lib/ - start the
phoenix_appinside of thenex_app - somehow? forward to the phoenix routes from nex? is this possible?
- absorb the phoenix logic into Nex’s file routes.
Most Liked
GrammAcc
Do they have to be running in the same supervision tree? If the goal is to gradually port from Phoenix to Nex, I would probably just run both applications on different ports and proxy them with nginx or caddy. Then I could port one route at a time from the Phoenix app to the Nex app and without needing to keep Phoenix idioms around in the new Nex code. If you’re using postgres for your db, you’d just need to make sure both applications have the same db user credentials, and any service or data layer code could be pulled out into a local hex package (:path dep in mix.exs) if you don’t want to copy that code between both apps.
Honestly though, if the project isn’t too large, it might be easier to just do the full port all at once and maintain the existing Phoenix app until the Nex version is ready for prod. I guess it would depend on how the project is set up and if it’s easy to separate logic by individual routes or not. Food for thought anyway. 
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
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
- #code-sync
- #javascript
- #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
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"