So, there is clearly a shroud of mystery surrounding my understanding of Netlify and the services it offers.
It was my initial understanding that I can deploy an application to a node server. This would allow me to run Javascript frameworks like Nuxt 3 utilizing SSR and Server Routes.
I’ve recently learned, however, that Netlify does not actually issue a Node server when I deploy a site - This brings me to my question:
How the heck have I been able to deploy a Nuxt 3 application to Netlify with in-tact SSR and Server Routes without actually using a node server? I’ve done absolutely no setup in regard to Serverless Functions, so my only idea of what could be going on is that Netlify has detected my need for one based on my codebase and automatically set one up for me…?
Additionally, what does the scalability of this solution look like? I appreciate that scalability is a complex question, but assuming I’ve addressed everything outside of the purview of Netlify, is there anything additional I should be aware of as a rule of thumb?
To offer some additional context - I have a Nuxt 3 application which uses a variety of server routes to interact with a MySQL database hosted on AWS as well as various third party APIs (I understand I’m responsible for scaling the Database server and handling third party API rate limits). Will scalability be an issue for me since I’m using Nuxt Server Routes instead of serverless functions?
Many frameworks either provide, or have provided by us/the community, adaptors which translate your dynamic code into lambda functions automatically. Nuxt is one of those: Nuxt on Netlify | Netlify Docs (via Nitro).
The scalability high-level answer is “we can run quite a lot of serverless functions for you at the same time”, though the number is not infinite. You’ll want to be aware that you’ll run into charges far before you run into a lack of headroom, though, since we only include limited numbers of function invocations included at any plan level south of Enterprise (see our pricing page for more details: Netlify Pricing and Plans). At any level of usage that isn’t costing you hundreds of dollars per hour, we will almost certainly be able to handle the load of your application with no special tuning.
If you have very high availability/scaling/concurrency needs, you should talk with our sales team about a custom contract that can include such functionality. Note that almost none of our customers run loads this high, and something tells me that thousands of them have applications requiring much more frequent and intense dynamic workloads than your site would.
Then again, maybe you secretly work for facebook and are thinking about migrating their service to Netlify. In that case, you are right, we are not configured for that level of traffic and you should definitely talk with our Sales team before migrating that traffic over here!
Checking out my existing site via the Netlify admin panel, I can indeed see that there is a “server” function running - That clarifies alot.
I am still a bit unsure, though, about the implications of using all of my server-side functionality via Nuxt Server Routes compared to what it would look like if I refactored them all to Netlify serverless functions - Does my current “server” function scale appropriately to handle all of the requests coming from Nuxt (one user can of course trigger lots of different server routes, presumably handled all by this one lambda function)?
Or maybe thats a misunderstanding on my part - Maybe new serverless functions are are being spun up and shut down as these server routes are triggered, and I’m just not seeing that happen? (this could make sense, but I’m not sure how Netlify’s Nuxt adaptors work, precisely)
Sorry for the naivety here , and thank you for the help
From our point of view, a lambda function is a lambda function. We abstract away the concerns with startup / management for you, and the details of how we manage it are both tedious and not something we share directly anyway. But, TL;DR the ones nuxt/nitro generate for you vs ones you handcraft will cost the same to run and have the same headroom - I am talking thousands of concurrent functions here, not dozens. Be aware that there is a max runtime to them - 10 or 26 seconds - so you do need to make sure they don’t “bite off more than can be chewed” in terms of doing a ton of work or accessing slow API’s. Since you are paying for runtime as well as # of invocations, this is to your benefit to consider before the first bill comes
But, if you weren’t scared off by the cost aspect for the long term prospects of running your site with us, I am almost certain there will never be a scalability problem in serving up the full load of your many concurrent visitors, short of you running an intentional load test/attack on our platform, which could, with some work, overwhelm your specific site’s headroom. This is fortunately against our terms of service, aside from just being fiendishly expensive to prove a point, so I am confident you won’t do that
, and thank you for the help
