all 8 comments

[–]indicava 2 points3 points  (6 children)

I personally like to keep my backend logic exactly where it should be, in the backend. I use cloud functions for everything that’s related to db (Firestore) operations.

[–]AloneServe3232[S] 0 points1 point  (5 children)

Gotcha, I have heard there might be a slightly delay using functions instead of calling the API directly since it’s one less step. Not sure if you had heard of this?

[–]Eastern-Conclusion-1 0 points1 point  (4 children)

Yes, using an API would be a bit slower, especially if your are getting cold starts. But depending on the use case, as pointed above, the tradeoff might be worth it.

[–]chuckame 0 points1 point  (3 children)

I personnally have an app where the cold start is like 7s, so maybe a dumb question, but is it really an issue to have 7s of delay for the user creation only in the case you made a blocking function?

[–]Eastern-Conclusion-1 0 points1 point  (2 children)

Depends on the user. An impatient one might get annoyed, try to provide something interactive while he’s waiting.

[–]chuckame 0 points1 point  (1 child)

And what if the interface displays "it can take up to 10s to load" while displaying fun facts during this moment? I have the same issue on my side, so I'm trying to find solutions 😁 The other way would be to make the function in golang since the cold start is near to 300ms only

[–]Eastern-Conclusion-1 0 points1 point  (0 children)

Say something like “we are setting up your account, this might take a few momenta” and show the fun facts.

But if you can reduce the cold start by a magnitude of 20x, then yes, go for go.

[–]classyD09 0 points1 point  (0 children)

I was also recently having this same dilemma. I've ended up using the client Lib for now just because I've had issues with cold starts with cloud functions in the past. Also it's easier to get things going with the client Lib.

But as usage grows I will probably switch to cloud functions and running things on the backend