[PaulHoule]

One big question is: do those API implementations keep any state between requests in RAM or is all the state in the front-end and/or database?

If there is no local state than serverless is a feasible solution, if not the best. If there is then you need to find some substitute for that local state and the case for serverless is much worse.

[danpalmer]

I think there's a lot of nuance to this. You may not keep any explicit state, but you may keep a lot of implicit state (often in frameworks and libraries). This state can include: database connections, cache connections, HTTP connections to downstream services, local LRU caches for computations, compiled regexes, import caches, and much more depending on the language and infra being used.

It's common for servers to take a while to start up, it's common to see the first request to each endpoint take a bit longer, it's a common optimisation to add keepalive to downsteam services, or tweak your database connection pooling. These issues are normally straightforward optimisations, and startup time isn't usually too much of an issue. With FaaS platforms these become significant hurdles that take engineering work to overcome, require introducing more services, more cost, etc.

[birdstheword5]

Thank you for this - implicit state is something I never even thought of - that could be a serious problem

[birdstheword5]

Some api routes do caching - right now this is using Asp.net core's in memory cache. He recommended redis to replace this. I feel that it's a bit overkill

[PaulHoule]

Now that I think about it, some parts of ASP.NET do a lot of stuff behind your back so the concerns that Dan Palmer brings up in a sibling comment may be worse than you think...