3 ms·

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 Firebas

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

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