All of these will be addressed, and others as well!

@rauchg

Can we still create an entire application on now 1.0 and choose a 1.0 plan? I definitely can't use 2.0 in it's current state.

@rauchg

I think , the now.json should accept all versions. It will make all of us happy !

What about elasticsearch?

@revskill

it does

@akryum

that was never possible to host to begin with, we only ever supported non-durable workloads

But we definitely want to make it super easy to connect and set up elasticsearch clusters

That's a big use-case we are looking into.

@dannyben

Docker is a great implementation detail

That's awesome

Any example for it ? It looks awesome. Imagine it will allow us to incrementally refactor big monothlic to lambdas.

In fact, right now builders can choose from a whitelist of runtimes, but in the future there will be more and more flexibility there

What about subscribing to 1.0?

Just version: 1 will work! We mention this in the upgrade guide. That's also why all existing users have to actually go out of their way by specifying version: 2 to upgrade. We didn't want to hurt any existing use-cases.

What i mean is, using two versions in the same file.

@akryum

new subscriptions will also work with version: 1 in now.json until full compatibility is achieved.

@revskill

that's not possible currently, but you could use the path alias feature!

(Notice that the new model also dramatically simplifies the gateway aspect of things)

I have a majestic monothlic under graphql endpoint for both http and subscription to render a NextJS application. It'll be deployed under version 1. My plan is to moving all mutation to lambdas under v2. What the now.json should be in this case ?

@rauchg

Yes, I absolutely love the ability to use the filesystem itself instead of path aliases. Hosting all endpoints in a single source tree is killer DX

@rauchg

Do you have plans to support things like redis or rabbitmq for websocket subscriptions?

@revskill

that's a very great way to do an incremental migration. Good decision. What I would do is set up an alias for your new v2 monorepo (e.g.: v2.api.company.com), and then use path alias for your current production app to start progressively migrating paths.

@nathaniel

It's not even just the best possible DX. It builds faster. It's more secure, by isolating parts of the application from one another at execution time, but not in the source code organization.

@akryum

Now you are speaking my language. I think that's the true way to scale realtime communication.