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?
1 Like
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.
I am new to Phoenix especially channels and will keep learning. I can define business logic on Firebase using cloud function, though, not super complicated ones , that I can do in phoenix.
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?
2 Likes
I think you were very accurate in your argument over the database schema. Yes, firebase has a No-sql schema and as of now I have used it only for simple logic. If I were to think about implementing something complex or changing its shape, I can see what you intend to say.
I completely missed out on tests, maybe because im not very good in writing them. Totally agree on how much control one has when using a dedicated web stack vs. firebase.
I think my doubts stemmed from the fact that all my apps have just been hobby apps and I dont think im near that stage where I can even think about building something on a large business backing stage. I think as I keep learning further about Phoenix and Elixir (next on menu is genserver), and building more complex solutions, I will be able to further appreciate how valuable is to keep complexity and correctness under control as my app evolves.
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.
https://pragmaticstudio.com/courses/unpacked-full-stack-graphql-with-absinthe-phoenix-react
https://www.apollographql.com/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.
