theagilecoder
Comparing Phoenix and Firebase for building backends
First of all I love how easy Phoenix make working with rest apis and especially websockets. I have built a few simple android apps with the front end in react native and the back end in either Phoenix or Firebase; and in the process learnt both. I wish to share some of my learnings/questions comparing the two.
-
Real time stuff : Firebase makes showing the real time updates pretty easy. Any updates in the firestore is reflected easily in the front end. Cloud functions make running remote functions quite easy; though more line of code as compared to elixir and also if the app becomes popular then you have to pay up.
-
Dev Ops : Firebase doesnt need you to know devops. Working with phoenix I had to learn how to provision VPSs, install stuff, fight hacking attempts, deployment (boy, took me a week to get deployments working). Though, I cherish this knowledge and was fun learning all this.
-
Remote Push Notifications in android : Even when the backend was in Phoenix I had to integrate Firebase in the project only for push notifs. (I used pigeon elixir library to push notifs to firebase and then firebase pushes it to react native front end)
So I have been asking myself when would building the back end using Phoenix would be better than building it in Firebase for a RN app. I can see when the app has a huge number of users, then VPS would be much cheaper than Firebase. Also the joy of writing code in elixir has me spoiled. Other stuff such as concurrency and fault tolerance are there but I am not that advanced yet, so cant comment on that.
What would you say are the other upsides on building back end in Phoenix vis a vis Firebase?
Most Liked
holgerwiehen
Congratulations for comparing your backend options and for getting into Elixir / Phoenix.
I would say there is a significant upsides to a Phoenix backend, when going beyond a proof of concept / learning project. It is important to remember that an application with a real business behind it will face evolving requirements. Those imply in evolving the software.
When it gets to evolving the database schema over the lifetime of a software the differences between Phoenix with its plain relational database (often Postgres) and Firebase will show. They call Firebase a ‘schemaless’ database, right? In reality even a ‘schemaless’ DB has an implicit often even heterogeneous schema, as data has some form. When your changing business requirements demand that you migrate your persisted data to a new shape (schema) you are well covered by those tools the relational database you use with Phoenix offers. Firebase has no efficient solution to migrate the shape of thousands or millions data entries. So you will notice that you are trapped. It will be very difficult to evolve your application as business demands.
And even beyond data persistence, you are better positioned with Phoenix for a long lived project who’s code evolves. Even having serverless functions on Firebase for business logic, with Phoenix you have a cohesive package, full of tools like unit and integration tests. To keep complexity and correctness under control as your app evolves. A Firebase backend is more cobbled together. Cobbeling many simple services together is not simple, especially when maintaining the product on the long run.
In the end it all depends. If your project is a quick proof of concept, that does not back a business or you have no goal to evolve it, Firebase can be a good solution. But, thinking about professional development on a job or with an ambitious side project, you would probably choose a solution that makes software evolution productive and low risk.
I hope my answer contributed to your understanding. What do you think about those questions? How would you choose when you imagine yourself creating a product that backs a business?
Popular in Discussions
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
- #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
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









