4 ms·

Before I even look into it, I'll tell you this: the headline was enough to grab my attention on its own. I strongly feel this is a badly underserved niche and I

Before I even look into it, I'll tell you this: the headline was enough to grab my attention on its own. I strongly feel this is a badly underserved niche and I've had major issues with Firebase's limitations. You definitely have a winning idea here in this user's opinion.

christyjacob4 5y ago
That's great feedback and more validation to the problem we're solving. Glad to hear that. Would love to hear if there are any specific pain points with Firebase that you'd like to be addressed. Being an open source project thats the biggest advantage we have over Firebase. The community!
- aerovistae 5y ago
  For me the most painful part was latency, and especially cloud function latency. I wanted to create an entire API through cloud functions and rapidly discovered that they have major issues with "cold startup". A lot of people have had this issue~ https://stackoverflow.com/questions/42726870/firebase-cloud-functions-is-very-slow?rq=1 https://stackoverflow.com/questions/42726870/firebase-cloud-... I found a lame workaround by setting up a cronjob to ping the API regularly, but there was still bad latency for cloud functions that were interacting with the database. It was 1-2s of latency, which was a total nonstarter for my realtime collaboration code. I had to go write a socket.io server by hand instead. Also, there are extremely limited tools for observability/monitoring/logging of cloud functions, as well as for plain API interactions with firestore. I could see that trying to track down issues through that toolset was going to be nightmarish. In my opinion, for any app that scales beyond a small personal project, it is an absolute must to have good tools for inspecting logs with error rate graphs and stacktraces and so on.
  - christyjacob4 5y ago
    Thanks a lot for taking the time to type this. Really appreciate this. If I understood everything correctly, may I ask why you were using a cloud function to build the a realtime application rather than relying on their realtime database directly ?
    - aerovistae 5y ago
      It was because I needed to run validation over the inputs sent to the server, and then update other data which the user themself did not have authorization to access.
      - christyjacob4 5y ago
        Thanks a lot for clarifying . Makes sense :)
      - combyn8tor 5y ago
        You can validate the data with Firebase rules. The other data can be updated with Firebase functions. They listen for state changes on the relevant data and then update the data that the user does not have access to.
        aerovistae 5y ago
        I'm sure it's technically possible, but things were starting to feel hackier and hackier and already the latency was a no-go, so the value proposition was becoming less convincing. I'm still using it for user auth though, that seems to work well so far.
        vincentge 5y ago
        Appwrite is really meant to live happily beside your stack. Honestly, disable and rip out the containers you don't need, they're all stateless, and loosely coupled. You can disabled them in console. Use what you find useful. I often use Appwrite just for Auth + Avatar/profile management. Something I do for every app... something that I find painful to do for every app :P
rectang 5y ago
I'd consider myself fortunate if I never have to deal with Firebase again. Firebase simply did not behave as documented. Whole features shipped that were just wishful thinking. It reeked of high-level management applying pressure to ship-now-no-matter-how-broken.
- vincentge 5y ago
  Firebase is great for Hackathons =D
- wfme 5y ago
  My experience is quite different to this. I’d be interested to know which features behaved differently to their documentation?
  - rectang 5y ago
    I most vividly recall unit testing, storage emulator, auth. For example: https://github.com/firebase/firebase-js-sdk/issues/5086 https://github.com/firebase/firebase-js-sdk/issues/5086 > Steps to reproduce: > Step 1: Read the documentation for setting up cloud storage unit tests at: https://firebase.google.com/docs/rules/unit-tests#storage https://firebase.google.com/docs/rules/unit-tests#storage > Step 2: Attempt to write unit tests following the examples in the documentation The reporter describes five problems which will thwart you when you try to write code according to the official documentation. How did these docs ship? Did nobody ever try the sample code and verify that the features worked as advertised? Did nobody write any tests to validate that the features actually worked? Are there no policies in place (e.g. "new features require tests" or perhaps code review) to prevent such mishaps?
deleted 5y ago
[deleted]

christyjacob4 5y ago

That's great feedback and more validation to the problem we're solving. Glad to hear that. Would love to hear if there are any specific pain points with Firebase that you'd like to be addressed. Being an open source project thats the biggest advantage we have over Firebase. The community!

aerovistae 5y ago
For me the most painful part was latency, and especially cloud function latency. I wanted to create an entire API through cloud functions and rapidly discovered that they have major issues with "cold startup". A lot of people have had this issue~ https://stackoverflow.com/questions/42726870/firebase-cloud-functions-is-very-slow?rq=1 https://stackoverflow.com/questions/42726870/firebase-cloud-... I found a lame workaround by setting up a cronjob to ping the API regularly, but there was still bad latency for cloud functions that were interacting with the database. It was 1-2s of latency, which was a total nonstarter for my realtime collaboration code. I had to go write a socket.io server by hand instead. Also, there are extremely limited tools for observability/monitoring/logging of cloud functions, as well as for plain API interactions with firestore. I could see that trying to track down issues through that toolset was going to be nightmarish. In my opinion, for any app that scales beyond a small personal project, it is an absolute must to have good tools for inspecting logs with error rate graphs and stacktraces and so on.
- christyjacob4 5y ago
  Thanks a lot for taking the time to type this. Really appreciate this. If I understood everything correctly, may I ask why you were using a cloud function to build the a realtime application rather than relying on their realtime database directly ?
  - aerovistae 5y ago
    It was because I needed to run validation over the inputs sent to the server, and then update other data which the user themself did not have authorization to access.
    - christyjacob4 5y ago
      Thanks a lot for clarifying . Makes sense :)
    - combyn8tor 5y ago
      You can validate the data with Firebase rules. The other data can be updated with Firebase functions. They listen for state changes on the relevant data and then update the data that the user does not have access to.
      - aerovistae 5y ago
        I'm sure it's technically possible, but things were starting to feel hackier and hackier and already the latency was a no-go, so the value proposition was becoming less convincing. I'm still using it for user auth though, that seems to work well so far.
        vincentge 5y ago
        Appwrite is really meant to live happily beside your stack. Honestly, disable and rip out the containers you don't need, they're all stateless, and loosely coupled. You can disabled them in console. Use what you find useful. I often use Appwrite just for Auth + Avatar/profile management. Something I do for every app... something that I find painful to do for every app :P

rectang 5y ago

I'd consider myself fortunate if I never have to deal with Firebase again. Firebase simply did not behave as documented. Whole features shipped that were just wishful thinking. It reeked of high-level management applying pressure to ship-now-no-matter-how-broken.

vincentge 5y ago
Firebase is great for Hackathons =D
wfme 5y ago
My experience is quite different to this. I’d be interested to know which features behaved differently to their documentation?
- rectang 5y ago
  I most vividly recall unit testing, storage emulator, auth. For example: https://github.com/firebase/firebase-js-sdk/issues/5086 https://github.com/firebase/firebase-js-sdk/issues/5086 > Steps to reproduce: > Step 1: Read the documentation for setting up cloud storage unit tests at: https://firebase.google.com/docs/rules/unit-tests#storage https://firebase.google.com/docs/rules/unit-tests#storage > Step 2: Attempt to write unit tests following the examples in the documentation The reporter describes five problems which will thwart you when you try to write code according to the official documentation. How did these docs ship? Did nobody ever try the sample code and verify that the features worked as advertised? Did nobody write any tests to validate that the features actually worked? Are there no policies in place (e.g. "new features require tests" or perhaps code review) to prevent such mishaps?

deleted 5y ago

[deleted]