WORK IN PROGRESS
Example solution using serverless hosting to submit and view tickets.
Components
- Lambdas created using Serverless Framework
- AWS DynamoDB for storage
- NodeJS
- AWS account and AWS CLI with access token setup in
~/.aws
Lambdas
cd lambdas
serverless deploy -v
Note: Requires DynamoDB table setup via serverless deploy
# api
cd lambda
npm install
serverless offline start
- Serverless Framework
- Example - aws-node-rest-api-with-dynamodb
- Blog - How To Create a Serverless Node.js App with DynamoDB For The First Time - outdated serverless config but useful context
- Example - Serverless Framework project code for creating DynamoDB triggered lambda - best example config I've found, there seems to be multiple ways to do this and some didn't work for me
- JSON for DynamoDB stream event object for insert - useful for creating event processing logic
Functionality:
- Add description/text/priority/status/user to ticket data
- Create materialised view of ticket for retrieving ticket separate from events (see single table modelling in dynamoDB)
- Updating ticket to set status
- Adding comment to ticket
- Update event structure with versioning and proper events for create/update/addComment, with explicit event version
- Display ticket history via events
- Create ticket loader to generate and submit large volumes of tickets (for test data and performance testing)
- Authentication (can be demo only, setting a cookie username for use in submitting/viewing tickets based on query parameter, investigated serverless authentication here)
- Add additional event processing functions to demo value of event driven structure
- sentiment analysis
- notifications (email/push web hooks in browser/pub-sub)
Misc:
- Use AWS layers to handle node_modules rather than packaging them
- Tests do not cover checking values are passed to services correctly or detailed functionality
- Why AWS? Clear documentation, great tooling, lots of examples/patterns especially for Serverless Framework, fast deployment, rapid testing cycles, offline support. I tried Azure but found it frustrating in comparison, with 15 minute deployments, poor documentation and support.
- Why a single Lambda project? Putting all the different Web/API functions in a single project isn't my normal approach, I like to split things out into separate repos/projects with tests/deployments. But single project works well with the Serverless Framework, which creates a single API Gateway to expose the Lambdas and link their dependencies. Lambdas can share code without fuss. Deployments are single push, putting the common deployment package with code into S3 and updating all Lambdas at once. How far this can scale for complexity I don't know, the limit for deployment packages in S3 is 250 MB (see here) and this project is around 8 MB without many Node modules.
- Why not use Express? It's not hard to use Express with Lambdas, there is a good wrapper aws-serverless-express which makes it easy to direct HTTP requests to an Express application. For this project I wanted to keep things as low level as possible, with individual lambdas using a single script each (with common code extracted), so I was forced to understand how Lambda sends requests with event/context/path/parameters. For a more complex application with developers who are familiar with Express it might make sense to use it for Lambdas, particular HTML functions.
- Why no templating engine? I wanted to keep things as simple as possible and since the HTML being returned in responses was basic I just stuck to using JavaScript Template Literals. If I had more complex HTML I would look at including a templating library and how it could fit in a Lambda project (e.g. how to reference template files).