danilop / serverlessbydesign

A visual approach to serverless development. Think. Build. Repeat.

Serverless By Design

Serverless By Design is a visual approach to serverless development:

• An application is a network of nodes (serverless resources, such as Lambda functions or S3 buckets) connected by edges (their relationships, for example a trigger or a data flow)
• Edit an application adding nodes and edges following an event-driven design
• Import a previously exported application to continue working on it
• Choose a runtime, and build your application (for example, using AWS SAM)
• Optionally use canary or linear deployments for your future updates
• Edit templates and code files for the final configurations before deploying the application
• Export an application to save it for later use in a JSON file
• Take a picture of the application architecture to have a visual representation to share
• Fine tune the physics used to place nodes and edges on the screen, for example enable/disable it or choose another solver

Serverless By Design runs in the browser and doesn't need an internet connection when installed locally.

A live version is available at: http://sbd.danilop.net

Think. Build. Repeat.

License

Copyright (c) 2017 Danilo Poccia, http://danilop.net

This code is licensed under the The MIT License (MIT). Please see the LICENSE file that accompanies this project for the terms of use.

Installation

You need node and npm. Just run:

npm run build

to build it for production, then open dist/index.html with your favourite browser.

For a development build, that you can debug with a browser, use:

npm run dev

Usage

Here are a few examples to help you start:

• Basic API
• S3 Processing
• Firehose Processing API
• Streaming Analytics
• Some IoT
• All Together Now

Dependencies

This code depends on:

• Vis.js
• js-yaml
• FileSaver.js
• jszip
• font-awesome
• JQuery

serverlessbydesign's Issues

CloudFormation code deduplication

As mentioned in #2, a considerable part of the CloudFormation-related code could be better modularized/centralized. Such a refactor should also allow for framework-specific specialization.

Separate dependencies from JS/CSS code

I would make clear what is a library/dependency and what's part of the repo. Eventually, we could add a bit of dependency management and injection (npm, bower, browserify, gulp, webpack, etc.).

Outdated dependency 'vis'

You are still using a very outdated version 4.21 of vis.
This version is not supported anymore!

Please update to the new libraries:
https://github.com/visjs

Feel free to contact us if you need any support during the transition :-)

SQS Support

Is SQS Support in the pipeline?

Or is their a reason why you are not adding it to the serverless setup? In other words, are their better alternatives?

I heard some rumors SQS to Lambda was coming, by then it should definitely become a member of the 'serverless' family?

Adding Deployment Preference for the Serverless Framework

Deployment preference now works when generating a SAM template. Support for the Serverless Framework should be added. I think there is a plugin for that... any volunteer?

Allow hyphen symbol ( - ) on ID name input field when adding node

Would it be possible to allow hyphen symbol ( - ) on ID name input field when adding nodes?

We use this on SNS and SQS naming.

order-messages-in
order-messages-in-dead-letter

Lambda JS files should move to a subdirectory

Current situation:
Javascript files for Lambda functions (and probably any lambda source file) are in the root of the generated zip file. Calling aws cloudformation package causes each Lambda to include all files in the root directory, including .git and .idea directories. Uploads take longer than necessary and contain data that shouldn't be in there.

Feature request:
Move each Lambda file to its own directory and reference that in the Cloud Formation template when generating a zip file for download.

Adding new services

Hey, I want to make sure I've got the flow down to add new services (e.g. I want RDS in here).

Can you double check me?

1. update nodeTypes (index.js line 3) with a new entry. E.g.:
   rds: {
   name: "RDS"
   image: "./img/aws/IMAGE.png"
   }

2. update nodeConnections (index.js line 54)
   with whatever are valid keys from nodeTypes and define the string for "action" for each type you want to support.

3. add the right image to www/img/aws/IMAGE.png. -- looks like 62x64 is the dimensions?

4. Optionally update getEdgeStyle include a case for your action (up in nodeTypes) and define the edge (e.g. color, etc)