What we’ve learned so far

Though we may move to a different architecture for production, we’ve learned a
bit about working with the framework effectively.

1. Test API Gateway locally

Serverless allows you to invoke AWS Lambda functions locally but has no such
support for API Gateway. As a result you can’t easily test your lambdas with the
inputs they’ll be receiving from API Gateway in production. API Gateway doesn’t
always process HTTP events in obvious ways either. Spending a few minutes to
deploy your lambdas each time you want an accurate event body will have you
barking at the moon. Catching
the Serverless offline plugin
late in the game makes us wish we’d known about it much sooner.

2. Structure lambdas for unit tests

To test Lambda functions, they need to be exported for use by a testing
framework differently than they’re exported for use by AWS Lambda. You can solve
this by exporting your business logic in a straight-forward way for your test
framework, and then write a wrapper to export that export for AWS Lambda.
The
Serverless docs do
a great job exhibiting this.

3. Authenticate on the client

Serverless allows you
to authorize against a
Cognito user pool.
You can prevent headache and avoid unnecessary Lambda costs by using
the
Cognito client-side SDK to
authenticate users with Cognito on the client, and then let Serverless use that
user’s Cognito ‘identity’ to determine permissions on your HTTP endpoints.

4. Check for new resources regularly

Community support for the Serverless Framework is strong and lively. A search
that turned up nothing useful yesterday might provide exactly what you’re
looking for today.
Here’s
an awesome, thorough walkthrough for building a Serverless React app which
was published a few weeks into our project, and discovered weeks later. If you
aren’t finding what you need, look again next week.

5. IAM role policies are strictly typed

Serverless allows you
to
configure an IAM role that
your Lambdas will assume when interacting with other AWS services. Unless we
explicitly granted permission to perform specific actions on AWS resources (like
user pools or buckets), service calls from our Lambdas were typically denied-
even when we configured very flexible policies to the resources themselves.
Though never fervorless, our navigation of permissions issues was much easier
after
discovering this list of IAM policy snippets.

Conclusion

On the whole, the Serverless Framework is a growing, well-supported framework
with good documentation. We foresee using it for odd jobs around the house when
AWS tools make sense. For application development, however, we’ll continue
to use app-specific platforms awhile longer.