A complete, serverless starter project
Jump to: Getting Started | Quick Start | CI/CD | Architecture | Contributing
SLIC Starter is a complete starter project for production-grade serverless applications on AWS. SLIC Starter uses an opinionated, pragmatic approach to structuring, developing and deploying a modern, serverless application with one simple, overarching goal:
Get your serverless application into production fast
This project is free to use by enterprise, startups, students, educators, enthusiasts and skeptics alike. We actively encourage contributions, suggestions and questions from anyone.
For the CICD pipeline architecture, see CI/CD
SLIC Starter is a complete, working application. By including all the aspects of a real application, SLIC Starter goes beyond a typical demo project. You are encouraged to:
We chose a monorepo approach using npm workspaces . Every serverless module (service) is a package under the packages directory. The monorepo/multirepo decision is always a tricky one, but we think monorepo works best here for these reasons.
SLIC Starter uses:
Authentication is a difficult problem with constantly-evolving security requirements. SLIC Starter uses Cognito and the Amplify SDK to remove the burden. Cognito can still be complex when getting started. SLIC Starter provides a complete setup with user pool and identity pool, sign-up and login. Amplify is used to authenticate in the web client. There is even a Cognito/Amplify simulation that allows you to work in local development mode, avoiding the need for a real Cognito backend in all cases.
SLIC Starter includes useful, working examples of typical CRUD (create, read, update and delete) actions with a REST API. Currently, these APIs are implemented with DynamoDB and the DocumentClient
API. For an example of this, look at the implementation of the Checklist service.
Upon first deploying SLIC Starter, the API Service will create Record Sets and an API Domain Name for your API. APIGateway and Route53 handles the creation of these resources for us.
A major goal of SLIC Starter is to provide a realistic, working examples for event-driven messaging, including a scalable and real-time message bus.
Following the KISS principle, SLIC Starter only requires the simplest messaging possible for now, so we use EventBridge (originally inspired by this article!)
SLIC Starter has a front-end web application. It uses React, Redux and Material UI. Out of the box, the front end is configured, built, packaged and deployed to S3 and CloudFront with a domain and HTTPS certificate.
sliclists.com
is api.sliclists.com
)Getting continuous integration and deployment (CI/CD) right is one of the most important things in your microservice or serverless project. Having a good foundation here allows you to keep making changes fast. It's also fairly difficult to get right. SLIC Starter has made key choices to help you here.
SLIC Starter covers automated testing with:
All tests can be run in local development mode as well as against a fully-deployed environment. The API and E2E tests are executed against a staging environment before deployment to production.
For details on integration (API) tests, see the README.md in integration-tests For details on end-to-end (E2E) tests, see the README.md in e2e-tests
SLIC Starter provides a basis for observability including:
We use AWS Secrets Manager for storing the GitHub personal access token and AWS Systems Manager Parameter Store for storing other secrets, such as API access tokens.
SLIC Starter is designed to get you up in running with a real-world application as quickly as possible. The fact that we go beyond the average sample application, there is a bit more involved in getting to production. For example:
sliclists.com
) and will set up DNS entries for use in production (like api.sliclists.com
) and staging (stg.sliclists.com
, api.stg.sliclists.com
). If you want to get up and running with a system quickly, you can skip domains by following the QUICK_START.md guide.This section covers a full deployment using multiple accounts with domain names and HTTPS certificates. It takes quite a bit longer than your average sample app since there is DNS and certificate approval involved. If you want to try SLIC Starter out in a single account without domains, go to the QUICK_START.md
To set up deployment to your own accounts, first run through these steps.
app.yml
. This is an important step, so ensure you change all values to suit your needs.owner
and name
under sourceRepo
)domainConfig
to point to your domain. Use a domain you own so you can update DNS entries to point to your deployed environment. When the deployment process runs, the domain owner will be sent an email to verify ownership before the deployment completes.enabled
to false
and the topic ARN to ''
, unless you need alarms and dashboards out of the box. If you aren't sure what to do, or don't want to incur the cost of additional dashboards and alarms, disable it. If you want nice alarms and dashboards, set up an SNS Topic as your alarms destination. Ensure that this topic it is accessible from all accounts by updating the SNS Topic Access Policy.SecretString
values with the following names/test/mailosaur/serverId
/test/mailosaur/apiKey
These are picked up by the integration and end-to-end test CodeBuild projects./STAGE/sharing-service/code-secret
where STAGE is the stage you are deploying to (dev, stg or prod). You can choose any secure password for this, since it's a shared secret. The important thing is that it is not stored in plaintext anywhere.Once you get all services in staging successfully deployed, you might find that the test stage fails. This is likely to do with the front end being inaccessible. As we already mentioned, your DNS entries will need to be set up. Let's understand how this all works better!
NS
and A
records for staging in your staging account. When production deployment happens, it will also create NS
and A
records in your production account.sliclists.com
)NS
records from your production Route53 into your domain registration name server settings. You will then need to copy the NS
record (only the NS
record!) for staging into your production Route 53 for the apex domain and give the NS record the staging domain (e.g., stg.sliclists.com
).NS
type records) from your staging and production account into that provider's DNS records.Once you have set up the required DNS configuration and it has propagated, your front end staging application should be available at https://stg.YOUR-DOMAIN.TLD
and you can click Retry on the test phase of the pipeline!
For the email-service
to send emails, you must choose a 'From:' address and set it in parameter store. The parameter name is /<STAGE>/email-service/from-address
. <STAGE>
should be replaced with stg
or prod
as appropriate.
In order for the email service to send requests to SES, either the email address or the domain needs to be verified. This is not automatically done as part of the SLIC Starter deployment.
If you are using SLIC with a domain configuration, the verification process is quite straightforward because we use Route 53 for our DNS records. See here for documentation on how to achieve domain verification through the AWS Management Console.
By default, SES will require validation of each email address to which emails are being sent. To avoid this, you can request a sending limit increase, which will remove your account/region from the SES Sandbox.
It is possible to run much of the application functionality locally and get a reasonable simulation of what the fully-deployed application does. Of course, every local simulation of an AWS service has limitations, so this mode should not be relied on for pre-production testing. It allows for fast feedback on simple API and frontend changes.
Local execution support utilises Localstack, serverless-offline and serverless-dynamodb-local
Prerequisites:
serverless-dynamodb-local
installs and runs DynamoDB Local so it requires a Java Runtimedocker-compose up -d
npm exec --workspace packages/checklist-service --call "sls dynamodb install --region us-east-1"
npm start --workspace=packages/checklist-service
npm start --workspace=packages/frontend
You can run all other backend services using npm start
in each package root.
Normally, when you run npm start
in the frontend
package, it will use localhost
for APIs and mock Amplify/Cognito configuration values.
To run the front end locally with a real backend deployed to AWS, you need to generate a .env
file that will be picked up by Create React App.
For example, to use the development environment deployed to AWS, you can generate an env
file. Your AWS credentials need to be configured to talk to the development account in order for this to work.
SLIC_STAGE=dev node scripts/fetch-deployment-config.js
cp .env.production .env.local
Then you can restart the front end:
npm start --workspace=packages/frontend
.env.local
will be picked up before the default .env.development
file and will ensure your front end is configured against the development back end.
SLIC Starter provides a fully-featured application for managing checklists called SLIC Lists. SLIC Starter is self hosting, so SLIC Lists is continuously deployed to sliclists.com from this repository!
SLIC Starter uses Standard with ESLint.
npm run format
).npm run lint
.SLIC Starter is open source and contributions are welcome from everyone. It was started by the team at fourTheorem, also the authors of the book, AI as a Service, a Manning publication on Serverless, AI-enabled applications.
There are many other amazing resources to help you get started, learn and evolve your Serverless practice. Here are a few recommendations!
See CONTRIBUTING.md
Copyright fourTheorem Ltd. 2018-2022. Distributed under the MIT License. See LICENSE