Comment by aerovistae | Hacker News Reader

Comment by aerovistae | Hacker News Reader

Parent Full thread

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-...

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.

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 ?

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.

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.

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.

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

Thanks a lot for clarifying . Makes sense :)

Reply on news.ycombinator.com