Serverless is just for image processing or can I use to build my API

Serverless is not caring about your servers, not only Function as a Service, if you use Now or Heroku you're using serverless, you don't need to care about the server and how it works, that's the idea.

And yes, you can use serverless to build your whole API, even the frontend, you could create an API and deploy it to Now as a single app or tiny microservices or you can create a lot of tiny functions and deploy them to AWS Lambda and compose them to create a proper API.

So it's totally possible to run your application in a serverless environment.

You can use AWS services to create REST APIs. The only issue is that you can't do this with Lambdas alone. You need a whole set of services to create a REST API. The Lambdas are only the compute layer of the API. It's the Docker container that runs your code.

What you also need it the REST API endpoints to bind as event triggers for your Lambdas. For this, you use AWS API Gateway. Once you have an en endpoint you use it to trigger the Lambda.

But wait. You need a DB. For this, you use either DynamoDB which is AWS' offering for NoSQL pay-as-you-go storage, or a DB as a service like mLab or MongoDB Atlas. DynamoDB is basically just like Mongo, but you pay for it in a similar way as with Lambda. Only pay for what you use.

Then, you need an authentication/authorization method. For that, you can use Auth0 or another AWS service called Cognito.

It's more than doable to create full-fledged applications and REST APIs by using Serverless Architecture. Just by using Lambda, you can't do anything, because the Lambda is just a function waiting to get triggered by an external event.

Hope I made sense. :D

You can read more about this here.

Lambda in particular would require your API to be stateless, because you cannot control the persistence or scaling... no single instance, always-running Lambdas. Additionally, if you need it to be responsive, you probably have to setup a script to ping it every few minutes or something. Otherwise the function can be unloaded, and the next request will cause a whole startup process again. Potentially taking a while before it sends a response.

So I would say that these constraints narrow its use as an API, but it is certainly still possible and a good fit in some cases.

Azure has a "serverless" API offering (called API Apps I believe), which is probably closer to what most would expect. You just upload your code, and the instance of your API stays running persistently. How high you can scale it (number of instances) is lower than Lambda though, IIRC.

I'm really surprised AWS doesn't have a similar API offering to Azure. (Or at least I'm not aware of it.)