proto-jojo

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.

See Examples

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

• Whats New?
  • Standardized Service Config
  • Multi-cloud & third party resource support
  • Composable Components/Services
  • Service Manifest
  • Configurable plugins
  • Custom Scripts
  • Multi region support
• Feedback / Feature Requests
• FAQ

How to use examples

# Clone down repo 
git clone [e-mail]: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 URLs, ARNs, 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!

Leave your feedback ❤️

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.