2
votes

I have been studying microservices and serverless solutions and am playing with an angular frontend hosted on S3 and Lambda functions that talk to various DynamoDb tables via the API gateway on AWS.

Every example and video I read/watch uses a simple CRUD microservices as part of a simple 'todo' application or similar. My problem is where does the business logic sit? If I'm building a complex application I don't want all my business logic in my frontend Angular application. Or do I? I could build an Application API which in turn calls CRUD microservices but that feels like a monolithic approach.

I appreciate there may not be a definitive answer but can anybody advise a novice on best practice?

1

1 Answers

3
votes

There are several best practices I follow in designing Serverless Microservices

  • Start with only few Microservices (Less the better up front, unless you know exactly how the service separation should be, delaying the decision to split)
  • Separate your business logic that goes to the API, and use the handler as a controller in MVC to invoke the business logic. (This will also helps to unit test logic without depending on Lambda).
  • Its not necessary to write only simple CRUD in your API. It depends on your domain and Business Logic required. (But don't build another monolith without separating the code in to different services. Several AWS Service limits will also give you some guide on how much endpoints should be there in a service & etc.)
  • Apply the design patterns available for Microservices (e.g If you want to sync data bases between each Microservice, use Pub-Sub pattern using SNS, DynamoDB Streams and Lambda)
  • Use the Angular App to put most of the presentation logic.
  • Use CloudFront as a proxy and a CDN to avoid CORs.

If you need more information you can refer the following articles I have written on this.

Note: You can use the CloudFormation in Deploying Angular/React Apps in AWS to automate the creation of S3 and CloudFront with best practices.