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.
your question is more serverless vs up and running all the time, like with App Service.. Durable Functions is a workflow engine... So a Serverless API makes sense when you call it seldom as you pay only when it's used, so it's cheap because the resource is powered down when not needed. Next time you need to use it you might experience a cold start, a delay in the response as it needs to power up an then answer you.. An API that's up all the time, using, for example, AppService costs a lot more but it always answers fast. So it comes down how often you need to call your API..
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.
I know my question was off topic, Thanks for answering. I asked this question in Microsoft Build Live session, I got answers like it depends on use-case. Yes I agree. So based on your answer it will be not a wise decision to convert all our existing REST API's to Serverless API. So Conclusion is to consider using RESR API's if you want the API's to be up all the time otherwise go for Serverless API and cut our cloud cost.
yes that would be my recommendation.. consider if you have code that needs to run seldom like a new customer was created or a batch job needs to start.. That could be made serverless...
Converting an existing API to Serverless is a matter of cost for the most part. If your REST API is already stateless, there should be no technical/design difficulties converting it to SERVERLESS API. Rememer that Serverless is not a type of API, it is more of a way to store your REST API (a good comparison is a docker stored REST API vs Serverless for example).
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?your question is more serverless vs up and running all the time, like with App Service.. Durable Functions is a workflow engine... So a Serverless API makes sense when you call it seldom as you pay only when it's used, so it's cheap because the resource is powered down when not needed. Next time you need to use it you might experience a cold start, a delay in the response as it needs to power up an then answer you.. An API that's up all the time, using, for example, AppService costs a lot more but it always answers fast. So it comes down how often you need to call your API..
I know my question was off topic, Thanks for answering. I asked this question in Microsoft Build Live session, I got answers like it depends on use-case. Yes I agree. So based on your answer it will be not a wise decision to convert all our existing
REST API'stoServerless API. So Conclusion is to consider usingRESR API'sif you want the API's to be up all the time otherwise go forServerless APIand cut our cloud cost.yes that would be my recommendation.. consider if you have code that needs to run seldom like a new customer was created or a batch job needs to start.. That could be made serverless...
Converting an existing API to Serverless is a matter of cost for the most part. If your REST API is already stateless, there should be no technical/design difficulties converting it to SERVERLESS API. Rememer that Serverless is not a type of API, it is more of a way to store your REST API (a good comparison is a docker stored REST API vs Serverless for example).