Local experience?

[brianneisler]

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.

[austencollins]

Great questions. More thoughts...

There is an immediate opportunity to offer value and gain users quickly by making the Event Gateway a compelling alternative to AWS API Gateway. This is why we are starting with this functionality.

The Event Gateway will offer a better alternative to AWS API Gateway by:

1) Offering a single gateway experience for functions on multiple clouds. 2) Treating HTTP requests like any other event, offering a single, simple developer experience for writing functions that can react to anything.

Another way to add value is to offer a better local experience than AWS API Gateway. If you look at our Framework data, the serverless-offline plugin, which emulates API Gateway locally, is our most popular plugin. Its commands are the 5th and 7th most popular commands, and it's not even in the core of the Framework!

The data is clear. There is major demand and therefore a big opportunity here to offer something better, via an excellent local experience.

Suggestions:

1) Ensure the gateway works locally like it works in the cloud. We can't recreate all managed services (e.g., DynamoDB, S3), but we can emulate serverless compute locally and enable the event gateway to run locally, which will still be major progress for serverless architectures compared to the poor local experience they have today.

2) Work closely with the Framework team to figure out how we can create a beautiful developer experience here.

3) Always remember that we are not building an API Gateway. We are building a new category. HTTP requests should be handled like any other event. We must enable developers to focus only on functions, events and building their vision, rather than worrying about the underlying event source or aberrations developers must be aware of to work with those sources. Aberrations are the enemy of simplicity. We will onboard users into our event-driven application experience via this familiar, valuable functionality, and then expand on that experience and functionality of the gateway to give them something much more powerful.