AWS Boilerplate | Hacker News Reader

AWS Boilerplate

github.com

109 pointszczarnecki61 comments

Initial reaction to seeing HN showing me “AWS Boilerplate (github.com)” was I thought AWS had launched a new service and it was potentially open source.

Please consider renaming to something like ‘Boilerplate for AWS’ since it would avoid confusion that this is something official from AWS, and because such a name is less likely to cause trademark issues per the AWS Trademark Guidelines.

https://aws.amazon.com/trademark-guidelines/

Yeah, my first thought was oh shit Amplify has been replaced here we go again.

Amplify is so shit

I think the same result could be achieved by simply lowercasing the ‘b’.

I used to work at a web agency, and my biggest impactful was without a doubt setting up something similar. Instead of starting from scratch at each new project, or copying config from another project, I wrote a "project generator" that asked you a few questions (Django or symfony? React or vue? NextJS? Terraform?) then generated a fully-configured project for you, including a staging and a production environment.

It's incredible how much time is lost on config: AWS is a big one, but having to configure Django, Black, Flake8, Webpack, ESLint, prettier, Typescript, Sentry, react-router... It easily takes days, and copying from other projects meant we were propagating some less-than-ideal setup.

Automating setting up a React-native app was clearly the most challenging, I don't work there anymore but I don't think it's a smooth process even now

This is why I love opinionated frameworks, why I love hand-holding tutorials, why I love abstractions. I don’t like code. I don’t like writing it, I don’t like reading it, I don’t like thinking about it. A mechanic doesn’t love his crescent wrench, he loves working on engines. The wrench is just a tool. What I enjoy is the final product and seeing a project come together as time goes on.

“The right tool for the job” doesn’t matter for most regular CRUD boring programming work. Django vs Rails vs a huge bundle of JS libraries cobbled together at random... for most programming work it doesn’t matter. So why not pick the one that lets you get your job done the quickest and easiest?

I get nothing (nothing but added stress) from trying new frameworks and new libraries and new packages constantly. I want to learn the right way to do something and then get down to business. My boss and my stakeholders don’t care what language or framework I’m using. The only consideration I need is “how quickly and easily can I get this done” and to be honest most of the time that’s Rails.

These days I’m using AWS Amplify which is an opinionated framework for AWS serverless apps and that’s all I really want... someone to make the “right” decisions for me so I can get my own work done. Because my job isn’t to pick languages and frameworks, it’s to produce a finished product.

If you don't like code you don't become a developer.

If you hate wrenches you're going to have a .. difficult time being a mechanic.

I feel the same way about rust’s standard lib, which is pretty sparse compared to, say, python and go. Finding libraries for common tasks is the most stressful part of an otherwise stress-free language (first world problems, I know). I get that it’s a trade off, and I get why the designers chose this path, but I would have preferred it the other way.

I use Go pretty regularly and I feel this. I had to choose a CLI framework and was bombarded by 10 different options all with wildly different designs to choose from. The flipside of this is Go's old errors library which lacked so much functionality that people standardized on an open source package.

> Django vs Rails vs a huge bundle of JS libraries cobbled together at random... for most programming work it doesn’t matter.

It might not matter to you, but it sure matters for the end user.

This sort of attitude is why blog pages weigh north of 20 Mb and load for minutes nowadays.

You read the absolute wrong conclusion from that statement. Hint: Django and Rails are not front end frameworks and you can definitely use them to serve 20mb front ends too.

If mechanics didn't love their wrenches, companies like Snap-on tools wouldn't exist. Where you get the same thing as a good tool at a big box store, but for 5x the price.

Snap-Ons business model isn’t the high quality of their tools, it’s their financing. I have a mechanic friend who is over $7,000 in debt to Snap On. They’ll finance just about anyone who has a job.

For folks who want a tool to help them accomplish this, I have heard good things about cookiecutter: https://github.com/cookiecutter/cookiecutter

It was one of the options I looked into, yes :) IIRC it's python-only, so didn't fit the bill. We ended up using Handlebars templates, and Plop (https://plopjs.com/) for prompts and the generation logic. It was lightweight and extensible, worked great

I have never worked for such an agency, but I actually find value in setting up some of the infrastructure from scratch, at least on the application side. It’s a time to dig into the latest versions of each component, or apply learning you wish you could have on other projects but things got too big to make large architectural changes. It costs a few days, but you’re laying down what should be the forever foundation, that’s worth fully understanding and trusting IMO.

All that being said, rolling AWS infrastructure ad-hoc like this is a terrible experience, but I far less experienced with it. Terraform seems like a great general tool to ease the pain, or something with this project.

That exploratory work is still done... its just done one time by someone who is "best" suited to do it. Then you just stamp out projects leveraging that exploratory work.

My point is more that the exploratory work is done at one point in time, not that it hasn't been done at all. If it has been years it's likely components you are familiar with have either matured or died, and starting a new project is a great opportunity to catch back up with the current ecosystem.

The project generator became a core part of our business (and a sales argument, actually), so it was maintained to be up-to-date. It's the implementation of what we collectively knew to be best practices: you don't always have time or knowledge to set up each individual component of a project.

If there's a later version of a component or you want to apply learning... contribute back to the project generator, to ensure other projects benefit from it

The only value we lost was the experience a dev gets setting up the infra from scratch. It is a consequent loss, but we deemed it very worth it (and retrospectively, I think it was)

Been working on a React codebase generator (https://divjoy.com) for the past year and seeing some decent traction with agencies. There’s definitely a need!

This could explain some of the “details” better.

“Backend” is a Django application - but not mentioned in the README, for example.

Also, what AWS services are being utilized? The Serverless stuff deploys to Lambda... that can be inferred, but the rest of it?

The documentation is a work in progress. It will be in a much better state until Friday

Additionally, it would be nice to see more details around security and operations.

What ports are opened? What roles are created? Is all traffic encrypted in transit? Is all data encrypted at rest? Etc. I could dig through the configs, but just a high level overview would be nice. Bonus points for a detailed threat model.

Operationally, how do I monitor this thing? How do I scale it? How is patching handles?

Just some constructive thoughts on areas that could be improved.

Those are all great points. Thank you!

This looks super useful!

For folks who are interested in deploying their containers on AWS without "boilerplate", we also have a tool called AWS Copilot which can help simplify setup and management of all the container infrastructure you need :D https://github.com/aws/copilot-cli

Shameless plug – I am building something similar to this for PHP with Laravel, Docker, Kubernetes, Helm, CI/CD, along with ready-made pages and tests: https://nana-landing.netlify.app/

Are the Documentation or "Get Started" links supposed to work?

nope, not yet unfortunately, I am still working on the documentation, I'll be done in a few weeks hopefully.

Looks solid. Are you using Nova for the backend?

Also, is this intended to be a thing you buy, fork, and make it your own? Or will it be more like a framework where customers receive updates to the core code?

No, I have built everything myself over the default Laravel setup. I have found myself doing this over and over again for new projects, that's why I decided to turn it into a kit that I and other people could just use.

This is going to be a fork and make it your own; once you get the code it's all yours. I may share security fixes as patch files maybe, but that'd be more of a manual work for everyone rather than an automated update mechanism.

AWS Amplify is in a similar space. It supports several frameworks and the development workflows and infrastructure management are built in to the project.

https://aws.amazon.com/amplify/

I urge fellow readers to try and plan out your entire app arch on Amplify before committing to it.

I have found it to be a pain in the ass because it tends to want to do everything for you leaving assets/buckets/things like `aws-amplify-23094139-85-3981759387593745983475-us-east-experiment-project` all over your account. I have been using AWS for over 10 years, so I tend to like to keep a clean house and name most of my things, or at least have them follow a sane convention. I also like to know what is being created.

Oh and the dev/stage/prod branching strategy is a nightmare.

What kind of naming convention do you tend to use these days?

I've found that creating a new isolated AWS account works well for this type of issue. In AWS organizations you can setup the new account using "+" in your email address, such as {your-email}+experiment-project@example.com. Then if you need to burn down everything and start over there is no impact or risk, and naming conventions are less relevant because everything in your "...+-example-project@" account is related to that one project.

I'm curious to see if they improve upon the Rube Goldberg machine that is validating PRs with CodeBuild's lack of support for branches in 2020: https://aws.amazon.com/blogs/devops/validating-aws-codecommi...

To the best of my knowledge most of the big shops are using “master ships everywhere, in-progress stuff is behind feature flags”.

There are pros/cons to this of course, but if you’re doing any A/B testing or bandit optimization you’re kind of stuck with it in one form or another. If you’re not doing any A/B or bandit then it’s probably a young enough project that you can do whatever you want.

This looks interesting, nice work. For comparison, I created a full-stack AWS boilerplate with similar aims: https://github.com/stackplanet/sourcestack

Wow, looks great! Can I ask you which tool(s) have you used to make the architecture schema?

[1] https://raw.githubusercontent.com/stackplanet/sourcestack/ma...

Sure, I used Lucid Chart https://app.lucidchart.com which has a lovely set of "flat" AWS asset icons.

Thanks!

My dream is to build something like this but in TypeScript, full stack. Using CDK for deployments, but also a really tight integration with higher order components. E.g. define a lambda handler and it automatically wires CDK code.

I guess kinda like serverless framework, but much less YAML and much more actual code.

Yeah, we often recommend using Serverless Framework and AWS CDK together. Serverless's strength is working with Lambda and API Gateway, but writing YAML for the rest of the resources is very cumbersome. So a good pattern here is to use CDK for the rest of your infrastructure, and Serverless for your Lambda functions.

In fact, we created a tool to do exactly this - Serverless Stack Toolkit (SST), which allows you to combine CDK and Serverless Framework - https://github.com/serverless-stack/serverless-stack

So you can do `sls deploy --stage dev` and `sst deploy --stage dev`.

Looks awesome and exactly what I needed. Will sign up tomorrow!

Awesome! I'd love to hear your feedback.

Feel free to send me an email anytime - frank@anoma.ly

I'm not really sure who this is for. It seems quite complex and opaque, for anyone who is well versed in AWS infrastructure I think you'll spend more time untangling this tool and trying to extend it beyond the exact use cases the author thought of than it would take you to set an app up yourself using your preferred config management toolchain.

For anyone not very familiar with AWS infrastructure, this is a very direct path to being in way over your head with a bunch of infrastructure you have no idea how to manage once it's set up. You'd surely be better off using a more managed setup like Heroku, or taking the time to read some AWS tutorials and set up only the things that you need, making sure you understand the different pieces along the way.

It makes me think of the Standards XKCD [0], I'm sure this project started out with good intentions thinking that "working with AWS SDKs is too complex, we'll make a few simplified make command to rule them all" but all they've managed to do is make yet another, extremely limited, but still opaque and complex tool.

[0] https://xkcd.com/927/

This is awesome. We used a serverless template from https://www.tinystacks.com/

Why does it use the Serverless framework AND the CDK?

As far as I know, they are both IaC frameworks.

Anyone else feel like AWS's primary goal isn't actually to make money but to put us all out of a job, but it doesn't quite know how to do so

How did you come to this conclusion?

Not quite put people out of a job as much as have absolute control over their entire product. They're using the convenience and low cost business model to hoover up developers (who are taking the bait) while not realizing that they're becoming wholly dependent on Amazon.

Not just technically, but in terms of their mental model on how to build and deploy applications. Over time, "just use AWS" becomes the defacto "how do I build this?" answer until nobody really knows how to build and deploy an application without them.

It's damn clever.

Arguably what VB did to C/C++ developers ;)

Ah yes that ubiquitous Visual Basic.

Back in the days, it was as ubiquitous as AWS is today.

Basically the outcome of the "I prefer to take the bait than to learn the simplicity of Linux" mentality.

Nowadays everything is 10-20x more complicated and expensive than it should be compared to 10 years ago.

AWS is sold to software companies, are you suggesting they want to replace their customers with... themselves? If companies could profit from purchasing their own goods I think the world would be a very different place lol

This is what happens when someone hears the phrase "one size fits all" and immediately thinks to themself, "Hey, I'M one size!"

What do you mean?

Hey now, the very first word in the readme is "opinionated"; your comment was both uncharitable and misleading.

It's a helpful, opinionated boilerplate.

Nice. This boilerplate can really help people get started quickly. Well done :)

On a different note, recently I was looking to learn AWS concepts through online courses. After so much of research I finally found this e-book on Gumroad which is written by Daniel Vassallo who has worked in AWS team for 10+ years. I found this e-book very helpful as a beginner.

This book covers most of the topics that you need to learn to get started:

If someone is interested, here is the link :)

https://gumroad.com/a/238777459/MsVlG

Your repeated promotion of this book in HN comments has crossed into spamming, and we're getting complaints about it, so please stop.

Sorry. I thought promotion of affiliate books was okay here. I'll stop it :)

Reply on news.ycombinator.com