Jauny
Hey everyone!
Sorry if the question has been asked before - I’ve seen a few equivalent questions but nothing similar.
I’m comparing Phoenix, Rails and Node to build an API for a client right now.
Their current backend is a Parse app with MongoDB supporting iOS and Android app and a Next.js app, so we’re purely talking about API/backend layer right now. We’d be moving out of Mongo to MySQL or Postgres.
It’s for a P2P marketplace, so the basic needs are
- authentication (including facebook login)
- payment (paypal and braintree/stripe soon)
- messaging
- CRUD
- Probably a graphQL layer (multiple resources often required on most pages, such as users, reviews, items for sell, followers, etc on profiles)
- Deploying on aws elastic beanstalk
Almost no eng team right now (2 founders + 1 android engineer) but hiring 10-12 engineers this year (all platforms).
I’ll probably have to argue against Node since this is what they have right now. I’m debating between Rails and Phoenix with myself, as I trust Rails in being able to be good enough and make me fast as there will be gems for everything.
Are there any red flags I should be aware of with Phoenix? Something that might not be as easy as with Rails?
This is not going to be such a straight forward project as we’re talking of a rewrite + migration of backend, which is always tricky, so I wanna make sure we head the right direction, building the correct platform to support all clients and be efficient.
Cheers 
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
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
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
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.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
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!"
Most Liked- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
abitdodgy
We are using Phoenix in production at a multinational retailer that handles millions of transactions per month. So far it has been a fantastic decision and an absolute pleasure. It’s the most reliable part of the stack in terms of uptime and speed. It’s also cheap to run and maintain. We’re migrating chunks of our ERP (extremely complex system built around SAP) to Phoenix, and the results have been consistently positive.
Although, the one thing I miss from working with Rails in the larger ecosystem.
Fl4m3Ph03n1x
If you have to deal with MongoDB, then you are better off with NodeJS, mainly because the driver for MongoDB is official (meaning it is made by MongoDB themselves).
Elixir does have a community driver, but it pales in comparison to the NodeJs one. We used the Elixir driver for a while but its performance was so abismal we were forced to integrate our Elixir stack with NodeJS just for the MongoDB drivers to get the performance we needed.
If however, you want GraphQL, then both Elixir and Node are good options. There is even a GraphQL book for Elixir in case you want to check it out:
easco
Apart from the learning curve of understanding a framework, I’ve not run into any problems using Phoenix as an API server (both Rest and GraphQL through Absinthe) for iOS and Android applications.
When the Phoenix server is making a direct response to an query we see response times that are measurably faster than Node, but not perceptible at the human/UI level. In much of our usage, however, the Phoenix or Node application is acting as an intermediary (a middle-tier) to back-end systems whose API calls dominate the execution time.
One thing with Elixir and Phoenix that seems to catch folks by surprise is the unique deployment options. If you have a deployment pipeline in place for Node entities, you will likely have to explore the Elixir deployment options and change that pipeline for Elixir. It’s not overwhelming by any stretch of the imagination, but lots of folks come here with questions and remarking on how it was not as straightforward as they thought.
Last Post!
Jauny
Thanks, we’ve actually faced speed issues using the current Node backend, so that’s good to hear this will be an easy sell!
For the deployment issues, I’ve heard those yes. We are on Elastic Beanstalk and already had issues deploying our Next.js app there. Hopefully I’ll have learnt things and will be able to deploy Elixir there without too much trouble either.
We use CircleCi for CI and it seems like they have documentation for phoenix, so I’m not too concerned there