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?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
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
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #performance
- #security
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.
Bringing learning, work and compliance together since 1987.
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!"
First Post!
krasenyp
I think you mix two concepts. Phoenix is a web framework, you build back-end systems with it and it has no assumptions on a database existence at all. Firebase is before everything else a storage service. Can you define business logic in Firebase? No. It seems you have a very superficial perception of what Phoenix is. There are a myriad of tutorials, articles and many books which can help you dive deeper into the framework.
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?
Last Post!
holgerwiehen
If I remember right, Firebase’s main feature is that it seamlessly syncs value changes from the backend to the frontend, right? If you are interested to somehow replicate this behaviour with Phoenix you might want to read on GraphQL subscriptions as well as GraphQL mutations with the Absinth library for your Phoenix backend. On the frontend you would pair this with a library like Apollo Client.
But I would also like to encourage you to consider simpler solutions when you just need to get things done. Besides existence of well engineered solutions like the Firebase API and GraphQL APIs, you will get a long way with a simple JSON REST API on your Phoenix backend. Pairing this on your React / ReactNative frontend with a simple data loading library like SWR you get a really simple integration between your frontend and the backend with features like: fast and responsive UI, optimistic updates, local data caching with transparent refetching, http caching,…
It is great that you studying technologies like Web Sockets, Phoenix Channels,… that are usually involved when building rich realtime user experiences. But you might be surprised how something simpler like SWR data fetching and a REST API can produce a great user experience also with lot less complexity.