menu

ZEIT

Our mission is to make cloud computing as easy and accessible as mobile computing. You can find our Next.js community here.

Channels
Team

clarify future support of docker on now platform

November 8, 2018 at 6:21pm
The ZEIT community has a new home. This thread is preserved for historical purposes. The content of this conversation may be innaccurrate or out of date. Go to new community home →

clarify future support of docker on now platform

November 8, 2018 at 6:21pm
It seems zeit is moving away from allowing customers to utilize Docker as a common 'primitive'; would you kindly clarify this?
Show previous messages

November 9, 2018 at 7:59pm
That's a big use-case we are looking into.
  • reply
  • like
Docker is a great implementation detail
like-fill
1
  • reply
  • like
That's awesome
  • reply
  • like
it does
Any example for it ? It looks awesome. Imagine it will allow us to incrementally refactor big monothlic to lambdas.
  • reply
  • like
In fact, right now builders can choose from a whitelist of runtimes, but in the future there will be more and more flexibility there
  • reply
  • like
What about subscribing to 1.0?
  • reply
  • like
Any example for it ? It looks awesome. Imagine it will allow us to incrementally refactor big monothlic to lambdas.
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.
like-fill
3
  • reply
  • like
What i mean is, using two versions in the same file.
  • reply
  • like
new subscriptions will also work with version: 1 in now.json until full compatibility is achieved.
  • reply
  • like
that's not possible currently, but you could use the path alias feature!
  • reply
  • like
(Notice that the new model also dramatically simplifies the gateway aspect of things)
like-fill
1
  • reply
  • like
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 ?
like-fill
2
  • reply
  • like
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
like-fill
1
  • reply
  • like
Do you have plans to support things like redis or rabbitmq for websocket subscriptions?
like-fill
2
  • reply
  • like
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.
  • reply
  • like
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.
  • reply
  • like
Now you are speaking my language. I think that's the true way to scale realtime communication.
Edited
  • reply
  • like
For example, your stateless endpoints can populate a queue that gets consumed by a client over a websocket connection
  • reply
  • like
So, you don't put all your eggs into one server basket, and you neatly separate responsibilities.
  • reply
  • like
I'm not as concerned as others on this thread, as all my projects will work fine on the new platform. That being said, I literally just migrated earlier this week from 1.0 to the serverless docker "v2" beta :/ I agree that this looks like the future, but why the rush to get rid of serverless docker? It is still an amazing product, that has a massive competitive advantage over any other offering I've seen! Why not two concurrent offerings? Now Lamba & Now Container?
like-fill
3
  • reply
  • like
That what's I was gonna do, but if I can just use now API for this it's neat
  • reply
  • like
I also loved merging the testing and build phase, and having that all triggered by a github push. It seems unclear how CI fits into this new paradigm. Is that something that would have to be triggered by the builder?
  • reply
  • like
thanks a lot for commenting. current discussions aside I think that now is an amazing innovator and pretty much everything you guys released this far is pretty much ground breaking. I would love to hear your thoughts on the issue of vendor lock-in / app portability though - as a lot of the stuff that is coming is quite unique to Zeit / now. do You think certain elements of zeits stack could become a standard outside of now?
like-fill
1
  • reply
  • like
So I guess I'll just develop on Now 1.0 and wait & see if Now 2.0 will work.
like-fill
2
  • reply
  • like
the "rush" is in the interest of truth-seeking. We, and I, learned a tremendous lot from that beta. I learned what works and what doesn't. I truly think this new world shouldn't wait and our customers will benefit immensely from it.
I think these systems are all in competition to one another to a very large extent, and I think this is the winner.
like-fill
1
  • reply
  • like
Show more messages
private
This conversation has been locked
private
This channel has been archived