The more projects you work on, the more streamlined your tooling gets. Hopefully. Various services using different languages have different tooling requirements, of course. A sweet Makefile can be the entry to a unified tooling interface.
As long as I can run
make build deploy in a project, I’m happy. Do you a have more complex interface to deploy a
dev environment? Rethink your tooling and remove obstacles for people who want to work on your project or contribute to your code.
You might have noticed,
make will list the invoked commands in a target per default. You can avoid this, and have a more slick output using
@ in front of your commands:
greet: @ echo "Hi!"
# Without @ $ > make greet echo "Hi!" Hi! # With @ $ > make greet Hi!
You can always access environment variables in a
Makefile, but for composition, you may want to use wildcard targets in
greet-%: @ echo Hi $*!
# Say Hi to Frank $ > make greet-Frank Hi Frank!
Together with wildcard targets, using lists and foreach can be a powerful addition to your
NAMES := Anne Frank Paul greet-%: @ echo Hi $*! greet: @ make $(foreach NAME,$(NAMES),greet-$(NAME))
# Say Hi to everybody! $ > make greet Hi Anne! Hi Frank! Hi Paul!
I plan to write down more Best Practices soonish …
You can find plenty of frameworks and tools to provision your AWS resources. Some of them do a great job for a specific purpose, others are more generic. Nevertheless, I do prefer to use native CloudFormation templates…
With AWS AppSync, it’s easy to run your own serverless GraphQL service API. Thanks to Velocity Mapping Templates, DynamoDB, and AWS Lambda your can aim for an architecture without any maintenance at all. Getting started…
Let me be honest with you: GraphQL is the shit! Once you use GraphQL, you will never want to use anything else again. The same is true for a working and maintainable serverless FaaS infrastructure. Combine both…