1/ If you're interested in orchestrating multiple serverless microservices together using EventBridge and API Gateway, here's a sample implementation I made with 11 microservices: github.com/aws-samples/aw…
Now for some key takeaways 👇👇👇
Now for some key takeaways 👇👇👇
2/ On tooling/orchestration, Makefiles are great for decoupling between implementation details and what a service is. Each service has to have a Makefile and metadata.yaml file. The metadata file helps with dependency management and CloudFormation parameter injection.
3/ The Makefile defines how a service is built, tested, deployed, etc. While most services use SAM and Python, one uses CDK and Typescript. If there is a better way in the future, it's easy to adopt it. Thanks @hanninen for the tip! github.com/aws-samples/aw…
4/ On dependencies, you can clone the repo, install the necessary tools and run `make all`: this will deploy all the microservices in dependency order thanks to this script: github.com/aws-samples/aw…
5/ Thanks to that, every developer can easily have a replica of the platform to experiment. New team members? Let them play and break things to understand how it works without affecting anyone else. Because it's serverless, it's unlikely to break the bank with the test env.
6/ Which leads me into testing. There are three types of tests: unit, integration and end-to-end. End-to-end tests validate that the overall flow works as expected. For example, testing that an order can be created, packaged and shipped without error: github.com/aws-samples/aw…
7/ Unit tests run locally, so they are the fastest to run. However, they're only as good as the mock/stubs/assumptions you make, and it's easy to build tests that don't match with reality. They're good for iterating fast but at some point, it's good to test against real APIs.
8/ That's where integration tests come in. A service is supposed to emit an event following a change to DynamoDB or another event? This tests not only the code, but also IAM policies, configuration, etc. github.com/aws-samples/aw…
9/ Speaking of events, EventBridge is a key component of the platform: services emit events and other services are responsible for reacting to those. It's fairly easy to evolve sources and connections as your architecture evolves.
10/ For example, let's say you will only cancel a payment preauthorization when the Order service emits an OrderCancelled event, you just need to change this section: github.com/aws-samples/aw…
11/ However, some things are synchronous. E.g. when you create an order, it checks with multiple services if all the input data is valid. This is a gate between untrusted user input and trusted service-to-service messaging. github.com/aws-samples/aw…
12/ So, how do users interact with that? There is a single GraphQL API powered by AppSync that ties everything together for the end-user, whether it's internal users or customers. github.com/aws-samples/aw…
13/ Then some types that are reused across multiple services can be defined in the GraphQL schema (github.com/aws-samples/aw…) which mirrors schemas used across all microservices (github.com/aws-samples/aw…). If you're good at user interfaces, I'd love your help to make a web app. 😀
14/ So, how to use it as a developer? There are two main commands: `make ci` and `make all`. You can also use it for each individual service, for example for running "ci" for the orders service: `make ci-orders`.
15/ `make ci` runs the following targets from the service's Makefile (e.g. github.com/aws-samples/aw…): lint, clean, build and tests-unit. This will check for stylistic/syntax errors, build the service and run unit tests.
16/ `make all` does the same thing as ci plus package, deploy and tests-integ. This will deploy resources onto AWS and run the integration tests. You can also run commands individually for a service e.g. `make tests-integ-products`.
17/ When you're happy with your changes, you could do one last test to make sure everything is fine before creating your pull request with `make tests-e2e`. This will use the user-facing APIs to make sure the overall workflow is working as expected.
18/ Finally, there are always rooms for improvement and PRs/feedbacks are welcome! There are also cases where tradeoffs had to be made which are documented here: github.com/aws-samples/aw…
However, if something is missing, unclear, or you have questions, feel free to reach out! ✌️
However, if something is missing, unclear, or you have questions, feel free to reach out! ✌️
