proto-jojo

    0.1.2 • Public • Published

    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

    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:

    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.

    Keywords

    none

    Install

    npm i proto-jojo

    DownloadsWeekly Downloads

    25

    Version

    0.1.2

    License

    MIT

    Last publish

    Collaborators

    • davidwells