There's tons of low traffic parts of apps. So if you're building in more of a 'microservice' architecture instead of a giant monolith, serverless has it's place. Most of your app is serving requests to users, but your signup and login flows might only run 100's of times per day and they are simple workflows, check if user exists > create new users > add password > send email verification.
Then, the email verification is checked by a second function. You click the link, it updates a field in the DB and redirects to the main page.
login is the same, we validate the creds and give a token.
And then the only infra we maintain is the stuff we have always on and serving mass requests. There's a lot of stuff that doesn't run that often that is more or less a single function and running a fleet or redundant machines for that doesn't really add value.
It just depends on how your app is designed as to if it makes sense.
If the load is so minimal for those functions and you are already running other infra for the rest of your app why would you "outsource" those functions to a serverless runtime? What do you gain besides another system you deploy to?
By duplicating and distributing parts of your app into a bunch of distributed targets you will, eventually, accumulate drift in assumptions about your environment/partners/libraries/databases/etc
Then, the email verification is checked by a second function. You click the link, it updates a field in the DB and redirects to the main page.
login is the same, we validate the creds and give a token.
And then the only infra we maintain is the stuff we have always on and serving mass requests. There's a lot of stuff that doesn't run that often that is more or less a single function and running a fleet or redundant machines for that doesn't really add value.
It just depends on how your app is designed as to if it makes sense.