I am a Full stack .NET Developer, I like to work with C#, Asp.Net Core, SQL, Mongo DB, Azure, JavaScript...
Always eager to learn new technologies. I am here to share, ask & eventually learn.
There are many reasons why developers would choose a Serverless backend for an API. The main ones are a) to reduce operation management overhead, since the infra is managed by the cloud provider; b) reduce financial commitment by paying per usage; c) having an infra that is easier to scale to different levels of demand.
You would not use serverless if the reasons to choose it aren't worthwhile for your project/team or when its limitations are problematic. For example: AWS Lambda has an execution timeout of 15 minutes and a memory limit of 3 GB, which rules out long-running processes or highly memory-intensive workloads.
I am a Full stack .NET Developer, I like to work with C#, Asp.Net Core, SQL, Mongo DB, Azure, JavaScript...
Always eager to learn new technologies. I am here to share, ask & eventually learn.
Thanks for the limitation of server-less. I also heard that server less API might experience a cold start, a delay in the response as it needs to power up an then answer you.
Cold start is not a âlimitationâ of serverless, itâs just a product of its nature - the same factor that makes serverless attractive also creates the incidence of cold starts but there are many ways to mitigate it, if it becomes an issue.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice đ,
Suppose I have a normal
REST APIwhich returns list of Products.And then I have a
ServerLess APIwhich returns list of Products.Can you tell which is better in this case , to use
ServerLess APIor NormalREST API?Also When should I NOT use
ServerLess APIinstead prefer NormalREST API?Hi, these are good questions.
There are many reasons why developers would choose a Serverless backend for an API. The main ones are a) to reduce operation management overhead, since the infra is managed by the cloud provider; b) reduce financial commitment by paying per usage; c) having an infra that is easier to scale to different levels of demand.
You would not use serverless if the reasons to choose it aren't worthwhile for your project/team or when its limitations are problematic. For example: AWS Lambda has an execution timeout of 15 minutes and a memory limit of 3 GB, which rules out long-running processes or highly memory-intensive workloads.
Thanks for the limitation of server-less. I also heard that server less API might experience a cold start, a delay in the response as it needs to power up an then answer you.
Check answer from below posts:
dev.to/shaijut/comment/12b0n
We should keep the limitation in mind. Thank you :)
You can use provisioned concurrency to avoid cold starts:Â dashbird.io/knowledge-base/aws-lam....
Or even a third-party library (e.g. JS: npmjs.com/package/lambda-warmer or... pypi.org/project/lambda-warmer-py/) to take care of it themselves.
Cold start is not a âlimitationâ of serverless, itâs just a product of its nature - the same factor that makes serverless attractive also creates the incidence of cold starts but there are many ways to mitigate it, if it becomes an issue.