Watching for updates is not enough to detect updates. Sometimes there are tcp issues, and all sorts of other random bugs can pop up to cause an update to go unseen by a process waiting on a watch to fire. To mitigate this, we just need to add a timeout chan to the select loop of processEvents in db.go which returns false when selected. The timeout channel should be randomized to prevent a thundering herd effect when each gateway reconnects.

Now that we have prometheus wired up, let's expand the things we're measuring:

• counters for all errors (although maybe Fatal's are less useful because Prometheus is pull-based and will probably not retrieve it in time)
• latency histogram for Get's to the config database
• latency histogram for Put's to the config database

• no persistence for dev
• one task service

Streams will sometimes be larger than what a single websocket can receive. It would be nice to provide a mechanism for external subscribers to receive feedback about stream partitions, and if they are falling behind. An example business built on this idea is Gnip:

http://support.gnip.com/apis/volume_streams2.0/

endpoint that invokes function from discovery

/invoke/<function name>

The local etcd test fails occasionally with a 60 second timeout for receiving the first update written to the database.

@brianneisler need more info here

• what is an url under which gateway accept events (http://.../<username>/<functionname> or /<functionname>
• is HTTP request payload directly passed as event to Lambda function or is wrapped with some object? What is the structure of wrapping object?
• what is the expected response object structure? Same as for API Gateway?

• function endpoint, including cloud provider required invocation info
• named function, mapping to several function endpoints, with weights for load balancing
• topics
• pub-sub, mapping from function input/output to topic, and topic to function name
• external security config

This is a Feature Request

Ideally the gateway would support multiple headers to be configured, and perform a request-time match for us returning only one CORS header since only one is supported by W3C https://www.w3.org/TR/cors/#resource-requests.

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: user/create
          method: get
          cors:
            origins:
              - https://origin1.com
              - https://origin2.com

Related issue from framework serverless/serverless#2476

eventually we may have a high-value customer who is trashing the performance of a system that is used by a large number of other customers. we should think about how to migrate users in this system from one cluster to another.

• validattion

Right now config API endpoints don't validate requests. Having some simple validation would be great.

• validation

The idea is to be able to call functions deployed in users' account from our account.

For AWS there are two options:

• use role delegation (user's AWS account allows role from our account to manage user's resources)
• use API credentials

We want to integrate this with the framework so it's transparent to the user.

It requires Gateway to accept accessRole param in function instance object.

It should allow attaching an event to a function.

It can be implemented as a part of function discovery, where during the function registration source events can be defined

Example:

{
	"id": "welcome-email",
	"instances":[{
		"provider": "aws-lambda",
		"originId": "arn:aws:lambda:us-east-1...",
		"region": "us-east-1"
	}],
        "events": [{
            "id": "userCreated",
            "retry": false
            ...
        }]
}

or as a separate endpoint POST /subscriptions

Example:

{
    "functionId": "welcome-email",
    "eventId": "userCreated",
    "retry": false
    ...
}

retry is an example field. I should start with something simple, at-least-once delivery semantic.

Should we use logfmt? Or something different? I think that this decision should be made early so it's easier to apply the same pattern everywhere.

• validation

API spec is in the README

• validation

We discussed it with @spacejam (https://github.com/serverless/company/pull/338#issuecomment-303724238). The best option to start and not get involved in difficult dist sys problem is to use existing consistent data stores for storing instance state.

This task is about implementing first integration. I think it makes sense to start with interface definition (probably based on https://github.com/serverless/gateway/blob/master/db/db.go) and implementation for DynamoDB.

• validation

Right now, we are deserializing function config from JSON on every invocation. We should maintain a cache of deserialized configuration which is maintained by the Created, Modified, and Deleted callbacks.

• storing credentials on a function level
• using credentials for invoking a function

Bugs and human coordination issues increase dramatically to the extent that state exists in multiple places. https://github.com/serverless/services-service stores data and other components will need to coordinate about state transitions (configuration etc...). It would be wonderful if we could do both simultaneously with a reactive storage architecture. My initial thought is to take heavy inspiration from the k8s storage model, where multiple components treat etcd as a reliable, persistent configuration store + pubsub, as different components can "watch" directories that they are interested in and react to changes in them. This work is to determine any hurdles that may stand in the way of moving that way.

Focus: what does this solve?

Explanatory graphic, maybe showing pub-sub - the ascii diagram is not clear enough

Description of how it works in a paragraph.

1. starting up in local mode
2. basic configuration
3. hitting a function on aws
4. creating a topic
5. creating a subscriber
6. creating a publisher
7. triggering the publisher and observing the effect

• topic
• pub/sub
• graph

What will the local development experience look like for a developer working on a serverless service that uses the gateway? I emphasize that i'm not talking about devs developing the gateway itself, but instead using the gateway as part of their serverless service

Some questions/thoughts

• Is it possible to boot and run the gateway locally? (i'm pretty sure it is but here for posterity)
• Is it possible to have a locally running version of the gateway tap in to events from another gateway (one running on our hosted service)?
  • We can't replicate all cloud infrastructure to run locally. However, we can enable developers to connect their local development experience in to cloud inf events which is a good replacement.
• Could the gateway binary be embedded in to the framework so that we could offer a better local dev experience without having to install a plugin.

I would start with something simple like Kinesis RMQ. Implementation should include import feature allowing reacting on events.