More About the Project

There's a growing list of serverless frameworks and utilities out there. Some are maturing quite nicely given the technology is still changing. This project was built for a very specific purpose: to help you build serverless microservices faster. On AWS. It is an opinionated framework. It does not aim to work on multiple clouds. Yes, this is vendor lock-in. Yes, only one language (Go) is supported. The belief is that by planting a flag (mostly) in one camp, a more reliable and less confusing framework can be built.

The API is straight forward. The documentation and examples you read will be relevant and work for you because you will be using the same cloud provider. Maintenance of the framework is a lot easier and that makes for less bugs and issues.

This isn't all to say you can't use other cloud providers and services out there. Why not use a fine database like CosmosDB? Sure you can. But the Aegis CLI will never provision one for you and you won't find any service interfaces or helpers for it in the core framework (maybe another Go package). So while you are only mostly locked-in.

It's really not that hard to use multiple clouds for things when you're talking about microservices. But your core code base is going to have to be Go and on AWS Lambda. That's why you're here though, right?

If you need more than that, here's a list of serverless resources specifically for Go: https://github.com/SerifAndSemaphore/go-serverless-list

So the other reason for this project is education. The code is simple and straight forward and there are plenty of comments. So you can certainly read through it and learn. Keep in mind that many of the helpers and interfaces in the framework can be used independently. If you find yourself working with plain ol' Lambda handlers and you don't want to deal with a map[string]interface{} and all the assertions and figuring outs of getting data - you may just find a helpful function in Aegis to make that a one liner for you. So dig around. The framework isn't designed to restrict how you code or how you architect your code. It's designed to reduce boilerplate and be flexible. It prefers convention over configuration, but it does not obscure any of Lambda's functionality for Go.

Special thanks to @tj and @mweagle for their help with many questions and their hard work on their frameworks and tools. Thanks to many other people, projects, and of course Amazon as well.

If you find you don't like the conventions in this framework, I would highly suggest you look at their work. Apex and Sparta.

Of course another popular one to look at is the Serverless and it too has some Go support. It was the very first framework for Lambda that I ever used (with Node.js) and they run a good operation there too with some services. There's just going to be too many projects to list, so the moral of the story is -- try.