Users of Firebase, I need your help!



  • Hi users of Firebase.

    I’d like to ask you a couple of questions and hope for some great feedback.

    What is it you like and/ or dislike about Firebase?

    Have you found an alternative, which is better/ or worse? If so, please explain what makes it better or worse.

    Looking forward to your replies and thanks in advance! 🙂

    Scott


  • Admin

    For me, Firebase offered me a serverless approach to my API, a noSQL db with offline functionality built in and very well documented features.

    That being said, I’m very scared of the pricing model. Free sounds nice but I wonder how well that’d scale when users come in the masses.



  • Well, if you are offering a service, it should be for a charge of some sort, if you want the costs to be covered. Theoretically, with the right cost to price calculations, you’ll cover your costs and even make money for yourself. 😄

    Scott





  • Ok. So, good code design isn’t a given, when using Firebase and might even cost you an arm and a leg. Got it. 😁

    Scott



  • @s-molinari Sorry, but you’ll have to give your own … my arms and legs are very precious to me 😀



  • I couldn’t get it to work. Versioning nightmare, I had to guess which of numerous google libraries would work with each other through trial and error. I’m calling Firebase not production ready: https://forum.quasar-framework.org/topic/3613/cordova-and-firebase-nightmare-working-from-default-quasar-v1beta-app

    Also vendor lockin. Dropped firebase and hoping somebody has a solution



  • Yeah. Unfortunately, no matter what backend platform you decide to take, it will cause a vendor lock-in. There are no interop standards for backends or backend APIs, unfortunately. GraphQL comes close in some ways from an API standpoint, but what is happening to your data is always going to be proprietary to the system in use.

    Scott



  • @s-molinari said in Users of Firebase, I need your help!:

    … GraphQL comes close in some ways from an API standpoint,

    { sarcasm mode on }

    GraphQL is in essential this:

    POST /api/sqlexecute?query=select%20login,password%20from%20users;
    

    Quite scary. Firebase is this:

    We know, that google is evil, aggressive, unpredictable and just a bully, but we try to believe, that firebase is different, that it could help us and always will.
    

    This false belief is in real world called “addiction codependency”.

    { sarcasm mode off }

    { sad mode on }

    we, as we developers are now (as in just now) building the world from the tv series “Years and years”. Highly recommended as a binge candidate.

    { sad mode off }



  • Um, @qyloxe - GraphQL is a bit more than your (sarcastic) example, because the query also forms the return result, which REST can’t do.

    I don’t get the rest of your comment and to be honest, it’s not the discussion I wanted either. Thanks any way.

    Scott



  • @s-molinari said in Users of Firebase, I need your help!:

    Um, @qyloxe - GraphQL is a bit more than your (sarcastic) example, because the query also forms the return result, which REST can’t do.

    Well, both solutions are based on conventions. Nothing stops you from writing something like this in REST:

    GET /api/v1/users/?fields=login,password
    

    IMHO you missed a point - it is this “bit more” that is “quite more scary”.

    To be clear, I’m not defending or praising anything - just commenting on IMHO quite controversial thesis about graphql and rest. There is possibility, that we think very similar, but are using different words 🙂

    For starters - there is no solution, be it graphql, rest, rpc, soap, …, which is “easier” or “better” on ALL levels of abstraction. You can not forget about complexity. You can only shift complexity from one place to another. And that is what “graph query language” does.

    What IMHO are main pain points with graphql?

    1. One endpoint. It means that it is hard to cache, load balance, proxy, monitor, react, log at the network or transport level (http). Those functionalities need to be implemented at the application level.
    2. Multi-level queries. Most of those queries (posts->comments->users->attrs) are just multi level iterations and results in multiple calls. I for example strongly prefer using JSONB Postgres types and JSON operators used by query optimizer based on indexes declared by experienced DBA.
    3. Separation of concerns. In small teams or dysfunctional teams it is tempting to let the frontend developers shape and query the data as they wish. In short term it is obviously faster. In long term, frontend developers should do frontend and backend developers should do backend. We could elaborate on that, because I agree, that graphql shifts people roles and in this aspect it could not be compared to rest, soap, rpc etc.

    to be honest, it’s not the discussion I wanted either.

    network routers rule #1: you can’t control what others say to you, you can only control what you are saying to them 🙂

    In case of Firebase you also misdirected the point about vendor lock-in. It is not a simple vendor lock-in as: oh, I choose OVH, but I will be using my dedicated server, and my Postgres, and I use cloudflare as network frontend and configure my DNS elsewhere. Oh, and my logs, operations, billing will be processed in another application and the firm and the vendor is on my continent and I have a legal leverage with him because I signed a legally binding contract. No. In case of Firebase it is a TOTAL lock-in. Every piece of technology and operations is in control of Google. What is worse, that one problem with for example billing could disable all your other operations. There are so called “developer horror stories” with apps on play store or even youtube. IMHO if you are building a small/demo project than firebase is OK. Or if you are building a global application, and this solution is so big, that you have a legal and operational means to negotiate with google in case of problems (without them disabling your global solution for the time of negotiation as is a standard procedure in google haha).



  • @s-molinari said in Users of Firebase, I need your help!:

    Yeah. Unfortunately, no matter what backend platform you decide to take, it will cause a vendor lock-in. There are no interop standards for backends or backend APIs, unfortunately.

    Perhaps, it might be worth looking at LoopBack … it can “plug-in” a variety of different backend database solutions … Postgres, MySql, MariaDb, Oracle, MSSQL, Couchbase … and many more



  • @digiproduct - Once you use LoopBack, you are locked into LoopBack’s way of doing things. In other words, your application couldn’t be easily ported to another framework/ system. That’s vendor lock-in and inevitable, once you are at a certain level of programming abstraction. Even with a programming language, you have vendor lock-in. 😉

    Scott



  • @qyloxe -

    1. One endpoint. It means that it is hard to cache, load balance, proxy, monitor, react, log at the network or transport level (http). Those functionalities need to be implemented at the application level.

    There are ways to HTTP cache GraphQL queries. There are other things that can also be done, like query caching (i.e. not sending a large query over the line, but rather sending only a query identifier) and also caching resolver read requests with Redis or something along those lines. All of that is also enhanced through the store/ cache kept on the client, which only gets updates to data that needs updating, which is the magic power of GraphQL.

    You can also have multiple endpoints, or do you think Facebook’s billions of users all go through one single endpoint? GraphQL endpoints can scale very nicely in fact, along with being able to be monitored, or did the Apollo team build a system that has no use?

    1. Multi-level queries. Most of those queries (posts->comments->users->attrs) are just multi level iterations and results in multiple calls. I for example strongly prefer using JSONB Postgres types and JSON operators used by query optimizer based on indexes declared by experienced DBA.

    You can use any DB you’d like in any way you’d like. You just have to follow the resolver pattern. Not sure what you are getting at here.

    1. Separation of concerns. In small teams or dysfunctional teams it is tempting to let the frontend developers shape and query the data as they wish. In short term it is obviously faster. In long term, frontend developers should do frontend and backend developers should do backend. We could elaborate on that, because I agree, that graphql shifts people roles and in this aspect it could not be compared to rest, soap, rpc etc.

    Um, the front-end developer can only shape a query on the data offered to her by the “Schema”. The backend dev controls that Schema. So, only what is available via GraphQL can be requested. It’s not like the front-end dev is making direct queries to the database, so again, I miss the point.

    I don’t mean to sound condescending, and it might be my own reading comprehension lacking here, but I feel you haven’t made the full paradigm shift that is required to grasp the full advantages of GraphQL and we haven’t even gotten to the advantage of building queries in components bit yet either. 😁

    Scott



  • @s-molinari said in Users of Firebase, I need your help!:

    @digiproduct - Once you use LoopBack, you are locked into LoopBack’s way of doing things. In other words, your application couldn’t be easily ported to another framework/ system. That’s vendor lock-in and inevitable, once you are at a certain level of programming abstraction. Even with a programming language, you have vendor lock-in. 😉

    Scott

    Agreed … I just mentioned LoopBack because it gave increased Database portability … plus with it being OpenSource, you could potentially fork it and end up with your own level of abstraction …

    Not saying that’s a route to be considered lightly …

    But, in all this … there isn’t really Vendor lock-in … just really a cost-benefit situation of a project re-write …

    After all, if you had $500million to throw at a project … even radical solutions start to become feasible …

    However, I think this thread has now disgressed completely away from your original intention … and instead of arguing semantics … we should be helping you get it back on topic …



  • Hi Scott;

    Right now, I’m going through the pros and cons of two approaches for database and services, but each has it’s own long list of side effects and benefits, which is going to take some time to get my head around it.

    For the time being I will mention the two directions and a starting point for the pros and cons, and if/when I complete the list, I can share the rest.
    Note: I have a large app to build that will require 4 modules: Admin, Website (Marketing site + anonymous usage of system), Vendor and consumer.
    The Website, Vendor and consumer modules will be written as SPA in Vue. These are public facing modules to be able to run on Mobile as efficiently as possible.
    The Admin, depends on the following direction.

    a) Firebase: (Firestore, Cloud Function, Firebase storage, Firebase hosting and etc.) - All the way for backend data and backend services.

    a. Pros:
    i. A lot of backend services are in place,
    ii. Great performance with Firestore,
    iii. Saves me a lot of time to build backend REST services,
    iv. Auth system built in,
    v. Easy hosting,
    vi. good access to run serverless functions.
    vii. Firesrore SDK is very easy to use in Vue.

    b. Cons:
    i. Putting all my eggs in Google basket.
    ii. No control of pricing like I’d would if I was running a fixed monthly charge of Dedicated server with my own app server.
    iii. Firestore query is very primitive compared to SQL query.
    iv. I have to write the whole Admin in Vue as well.
    v. If your app runs Cron Jobs, get ready to pay a lot of monthly charge to uncle Google.

    b) MSFT Backend REST hand built server using WebAPI and IdentityServer4 for auth and MySQL for database.

    a. Pros:
    i. #1 the monthly cost is a lot less and fully under my control.
    ii. No charge on the CPU or calling my own functions or running my own queries.
    iii. I can build powerful queries either using MSFT Entity Framework (ORM) or writing SP.
    iv. Much more powerful queries that Firebase offers.
    v. The Admin can be written in ASP Core as server side that connects directly to my database. Big time saving here.
    vi. I will build the auth server using Identityserver4 that becomes part of the backend server.

    b. Cons:
    i. I have to build the complete REST server to serve the Vue modules.
    ii. I have to host and maintain my own database and application.
    iii. I have to build my own LIVE server to update all users in RealTime and it is built into Firestore.
    These are just from the top of my head.
    Hope this helps Scott!



  • @digiproduct - Thanks Ben!

    Interesting that Firebase’s query capabilities are lacking. Good to know! Thanks.

    Scott


Log in to reply