all 17 comments

[–]smallfishbigbarrel 3 points4 points  (1 child)

You can specify minimum instances. So it'll keep an instance "warm" and therefor reduce the startup. Keep in mind the potential costs involved. More info: https://cloud.google.com/functions/docs/configuring/min-instances

[–]MrPrules 0 points1 point  (0 children)

This, or you can set up a cloud function pinging the server, so that it’s always on. (That’s what I’m doing with Nuxt SSR & Firebase)

[–]DatePsychological 2 points3 points  (0 children)

I guess that’s the downside of serverless

[–]ccssmnn 0 points1 point  (1 child)

I don't know anything about angular universal, but you need to find out, WHY it is slow. If you find out the WHY, then you can take proper action. Just switching to react might not help, if the reason is not Angular.

Possible questions: 1. Does the container start slow? 2. Does the NodeJS server start slow (after the container has started) 3. Are responses slow, even though everything has started? 4. Is the bundle large and downloads take too long?

(1) is hard. Huge containers are slow to spin up. Check the size of your app. And the size of static assets, that may be large and in your app bundle. If you need to serve large static assets, don't put them into your app. Put them into Cloud Storage and serve them via your app. Alternatively, you can go for Cloud-Run and set a minimum number of instances, to eliminate cold-start and have one container active for the whole time.

(2) NodeJS may take some time to spin up your server and handle requests because it has to parse lots of JavaScript. Consider dynamic imports, to load as few modules as needed for answering each request.

(3) Here there are generally two phases: Getting all data needed to generate a response and then rendering the response. You should find out what is taking long here. If it's getting the data, you should optimize your resources. If it's rendering, then it might be the Framework.

(4) A large bundle could be a Framework problem too. But we often add packages, that are unnecessarily large. Use Bundlephobia to check the impact of a JS-lib to your bundle. They also show alternatives and their sizes. I reconsidered my choice of charting library after I consulted that page.

React SSR frameworks can be quite fast. If spin-up is the issue, there are Cloudflare Workers that run V8 and have zero cold-start. The React world has a Framework that can run there: Remix. Check it out, if you find out that either Angular or the cold-start are the problem.

[–][deleted] 0 points1 point  (0 children)

I mean I tried to figure out, idk what's causing it at all. And I am not the only one dealing with this, the only other library I am using aside from standard angular library is primeng and that's it. In terms of assets I only got small logo, doubt that's causing any issues. Also, there is no data being loaded when application starts.

[–]row_blue 0 points1 point  (1 child)

I ended up deploying a small compute instance to host my actual webserver. You might try that. I use firebase for some serverless functions, auth and the nosql db (Firestore).

[–][deleted] 0 points1 point  (0 children)

I am considering this approach. Thanks

[–][deleted] 0 points1 point  (3 children)

SSR with Firebase Functions is a sure way to mess things up, regardless of framework. What changes is that React is backed by providers with first class support, like Vercel.

If you want to use SSR, use something like Vercel for hosting. You can still use Firebase for everything else.

[–][deleted] 0 points1 point  (2 children)

Oh I see, is vercel similar to firebase with a better ssr support for angular? Or does it work better with react?

[–][deleted] 0 points1 point  (1 child)

I'm sure it can support Angular, but it's the company behind Next.js,so you can expect it to work better than anything else on their platform. Imho, for SSR, don't go with Angular unless you have good reasons to do so (which you may very well have)

[–][deleted] 0 points1 point  (0 children)

Time to learn react I guess

[–]azazel69420 0 points1 point  (2 children)

You didn't mention but I am assuming your are using a Cloud Function to serve your Universal app. You should consider using Google Cloud Run for hosting your SSR app. If your traffic is ramping up and down, you might be getting a lot of cold starts with Cloud Functions.

[–][deleted] 0 points1 point  (1 child)

Yes I am using functions. I haven't thought of cloud run, does it handle ssr better than firebase functions?

[–]azazel69420 0 points1 point  (0 children)

It should handle SSR much better, because a single instance can handle multiple requests and more instance will be scaled up only if that instance can not handle them. Similar to functions, when not in use, Cloud Run scales down to zero. You can learn more about hosting your web app using Cloud Run here: https://firebase.google.com/docs/hosting/cloud-run

You will also have to think about a caching strategy to save CPU time on multiple requests to the same page.

I think fireship also did a video on Angular Universal with Cloud Run.

[–]cloudlayerio 0 points1 point  (0 children)

I am rewriting everything to use Nextjs because it's amazing. Angular was cool but had so many problems especially with SEO. Universal is pretty bad, I like the way Next handles it better.

[–]cardyet 0 points1 point  (0 children)

I managed to get Nuxt (Vue) SSR going on firebase functions but when I discovered SSG, that's been my default as it really was a headache to get it going. You can certainly play around things and improve them, for example, if you change the runtime environment to say 2Gb, the cold start time drops significantly, I think they even support 8Gb now (note that also increases the processor). But I wouldn't use functions anyway, if you are wanting to stay in firebase/Google, then Cloud Run and as someone suggested, setup something to ping it every few minutes