ersaurav
Hi everyone,
I’m working with a Laravel-based eCommerce application and evaluating whether Elixir/Phoenix would make sense as a separate service for some workloads rather than trying to move the entire application to Elixir.
The idea would be to keep the main eCommerce application in Laravel/PHP while using Phoenix/Elixir for workloads that benefit from concurrency and long-running processes.
Some possible use cases I’m considering are:
-
Real-time notifications
-
Background processing and job orchestration
-
High-volume API requests
-
WebSocket-based functionality
-
Processing events from the eCommerce application
The Laravel application would communicate with the Phoenix service through HTTP APIs or events.
For those who have used Elixir alongside another backend stack:
-
Would you keep Phoenix as a completely independent service?
-
Would you use a message broker/event bus instead of synchronous HTTP wherever possible?
-
How do you handle authentication between the Laravel and Phoenix applications?
-
What types of workloads have you found are actually worth moving to Elixir?
-
Are there any architectural pitfalls when introducing Phoenix alongside an existing Laravel monolith?
I’m particularly interested in experiences from teams that have successfully introduced Elixir incrementally rather than rewriting an existing application.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #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.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
bottlenecked
Hi there
does this mean the decision to move (at least parts of the app) to Elixir has already been made?
Because, don’t get me wrong, I love Elixir and would love for people to adopt it more and more, and it does perform marvelously under load, but maintaining two (or more) services across different languages sounds like a hefty price to pay.
If the current service is struggling under load (I don’t know for sure, just assuming the reason for considering Elixir might be performance related), would it make sense to try and optimize the current Laravel service instead? Or use better hardware to host it? On the other hand, if you only anticipate larger traffic volume (but not there yet), I’d probably advise to wait and see how the current app actually performs under load before proceeding to a partial or full rewrite to another language.
At my current workplace we still have Ruby/Rails services working alongside Elixir ones, and migrating as many as we can into Elixir and consolidating lots of micro-frontend like services under fewer larger ones has been a blessing, especially given our smaller team size.