proto-jojo v0.1.2
Prototype
Potential prototype of v2.
This is a backwards compatible prototype that builds on inertia of v1 community and brings them into the future with us.
It enables a highly configurable & composable pieces and multi-cloud & third party resource for all existing serverless projects & more.
Backing Product Philosophy
- Domain Expertise is paramount - We must eat, sleep, breathe serverless.
- Next level user experience - UX/DX is baked into every nut & bolt. Remove all points of friction in our users lives.
- We must be users of our product - Dogfooding is everything, otherwise it’s all guess work
- Invent and Simplify - We must trust our instincts and move fast
- Measure everything - Learn from mistakes but not be afraid to make them
- Growth state of mind - Bake in growth mechanisms (activation/retention/analytics) throughout product
- Iterate and improve - Slow time to market = death
- Mantra - Have fun & build awesome. We create the future.
Table of Contents
How to use examples
# Clone down repo
git clone git@github.com:DavidWells/prototype.git
# in root
npm install
# cd into an example folder
cd examples/basic
# run config command
node ../../index.js config
# run deploy command
node ../../index.js deploy
# or any other v1 command
node ../../index.js info/remove etc
Additionally if you just want the end user experience use one of the 2 demo repos:
- https://github.com/DavidWells/prototype-email-service
- https://github.com/DavidWells/proto-github-webhooks-service
Whats New?
Standardized Service Config
Service config
is now a first class citizen in serverless. Developers can now specify all the configuration requirements of a given service.
The config
key in serverless.yml
enables:
- Easier service re-use
- Streamlined setup via
proto config
- Composition of services
- Future usage in GUI tools
# Service configuration. Values needed for service to work
config:
SENDGRID_API_KEY:
displayName: "Send grid API Key"
type: string
required: true
default: 'your-api-key'
Config types are based heavily on the RAML type system
Config values are written out to a .serverless.config.json
file
{
"stageName": {
"SECRET_API_KEY": "xxxx"
},
"dev": {
"SECRET_API_KEY": "yyyy"
}
}
See example in larger config example.
Multi-cloud & third party resource support
Serverless v1 resources
were limited by the choice of the service provider. For example if the provider
was set at aws
, resources was limited to a single CloudFormation Stack.
This is no longer the case!
We are expanding the functionality of resources to handle multiple resources.
See example(s) in github webhook examples.
# Multi cloud / third party resource defintion examples
resources:
# provision github webhook
GitHubWebhook:
type: Github:Webhook
config:
apiToken: ${config.GITHUB_AUTH_TOKEN}
repository: ${config.GITHUB_REPO}
# provision cloud formation
MyCloudformationStack:
type: AWS:CloudFormation
Resources:
myDynamoTable:
Type: 'AWS::DynamoDB::Table'
Properties:
TableName: 'overbearing-ops'
AttributeDefinitions:
- AttributeName: id
AttributeType: S
KeySchema:
- AttributeName: id
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
# provision terraform modules
TerraFormStackOne:
type: 'Hashicorp:terraform'
variable:
ami:
description: the AMI to use
resource:
aws_instance:
web:
ami: "${var.ami}"
count: 2
source_dest_check: false
connection:
user: root
A working example that provisions GH webhoojs can be seen and deployed from here
Composable Services
(Needs real world validation)
See nested composed example in examples.
app: my-real-application # or `service` key
services: # or `components` or under `resources` key
userService:
type: ./user-service
version: 0.0.1
inputs:
USER_TABLE_NAME: my-app-table-name
emailService:
type: ./email-service
version: 0.0.1
config:
SENDGRID_API_KEY: 12311dasdwwqdaww
smsService:
type: ./sms-service
version: 0.0.1
config:
TWILIO_ACCOUNT_SID: 121312331
TWILIO_AUTH_TOKEN: 9827271711
TWILIO_PHONE_NUMBER: 1-900-324-1312
dbStandAlone:
type: ./service-with-db
version: 0.0.1
Service Manifest
It's common practice to require stack outputs like api URL
s, ARN
s, and other custom values after a service is deployed.
After the deployment of a service, the service creates a manifest.json
file for easy consumption.
This file can be referenced by front end applications or piped into service discovery tools.
Example of a manifest file with stage specific values. (final shape of manifest output TBD)
{
"dev": {
"urls": {
"base": "https://d3ul21vxig.execute-api.us-west-2.amazonaws.com/prod/",
"byPath": {
"handle-entry": {
"url": "https://d3ul21vxig.execute-api.us-west-2.amazonaws.com/prod/handle-entry",
"method": ["POST"],
},
},
"byFunction": {
"handleFormEntry": {
"url": "https://d3ul21vxig.execute-api.us-west-2.amazonaws.com/prod/handle-entry",
"method": ["POST"],
}
}
},
"functions": {
"handleFormEntry": {
"name": "site-form-service-prod-handleFormEntry",
"arn": "xyxyxyxyx"
},
},
"resources": {
"MyCloudformationStack": {
"myDynamoTable": {
"TableName": "xyz-lol"
}
},
"GitHubWebhook": {
"repository": "davidwells/components"
}
}
},
"prod": {
... prod stage resources
}
}
Configurable plugins
(Note: not implemented yet)
In serverless v1, plugins often needed to specify their configuration in the custom
block of serverless.yml
# Before
custom:
valueNeededForPlugin: 'xyz'
plugins:
- my-serverless-plugin
By turning the plugins array into a keyed object, configuration can live directly on the plugin declaration like so:
plugins:
MyServerlessPlugin:
valueNeededForPlugin: 'xyz'
webpackPlugin:
config: ./webpack.js
Custom Scripts
Extending functionality can now easily be accomplished inline in serverless.yml
without needing to author a custom plugin.
See basic example in examples.
scripts:
beforeDeploy: node ./tests.js
deploy: node ./sms-boss.js
afterDeploy: "npm run integration"
Multi region support
(Note: not implemented yet)
In serverless v1, you are constrained to a single region per deployment, but by altering the region
key to accept an array, we can deploy to multiple regions simultaneously
# Service provider
provider:
name: aws
runtime: nodejs6.10
region:
- us-west-1
- us-east-2
Other Feature Ideas/Requests
IAM role support on function level
"Would be cool if you could define iamRoleStatements at the function level."
Feedback / Feature Requests
After completing the steps, please fill out the quick 3 question survey!
If you would like to see additional features added don't hesitate to request them!
FAQ
Is this backwards compatible with version 1 of the framework?
Yes
Does it work with serverless variables?
Yes
Do additional CloudFormation resources work?
Yes
Can I run this on-prem?
Yes
How many resources can I leverage today?
254 (all of cloudformation + github webhook resource (sls IP)). There is no limit on the amount of resources we (or the community could add)
Credits
Thanks to Phillip Muens, Eslam λ Hefnawy, and serverless community for their hard work on v1 and Austen for starting it all with v0.
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago
6 years ago