How to build complex apps with AWS Lambda and SOA?

0
votes

We currently run a Java backend which we're hoping to move away from and switch to Node running on AWS Lambda & Serverless.

Ideally during this process we want to build out a fully service orientated architecture.

My question is if our frontend angular app requests the current user's ordered items to get that information it would need to hit three services, the user service, the order service and the item service.

Does this mean we would need make three get requests to these services? At the moment we would have a single endpoint built for that specific request, which can then take advantage of DB joins for optimal performance.

I understand the benefits SOA, but how to do we scale when performing more compex requests such as this? Are there any good resources I can take a look at?

1
amazon-web-servicesaws-lambdaserverless-frameworkserverless-architecture
i think it's just a question of architecture. you can still build a single endpoint for that particular request that would do the same join in RDS and return the same result. you can use e.g. API GW integrated authentication with your user service. if you want to split away user service from item service from order service for some reason, then yes, you need to communicate between them. – grepe
The question scope just too broad. – mootmoot

1 Answers

0
votes

Looking at your question I would advise to align your priorities first: why do you want to move away from the Java backend that you're running on now? Which problems do you want to overcome?

You're combining the microservices architecture and the concept of serverless infrastructure in your question. Both can be used in conjunction, but they don't have to. A lot of companies are using microservices, even bigger enterprises like Uber (on NodeJS), but serverless infrastructures like Lambda are really just getting started. I would advise you to read up on microservices especially, e.g. here are some nice articles. You'll also find answers to your question about performance and joins.

When considering an architecture based on Lambda, do consider that there's no state whatsoever possible in a Lambda function. This is a step further then stateless services that we usually talk about; they generally target 'client state' that does not exist anymore. But a Lambda function cannot have any state, so e.g. a persistent DB-connection pool is not possible. For all the downsides, there's also a lot of stuff you don't have to deal with which can be very beneficial, especially in terms of scalability.