Rauchg

14 ms·

121.
by Rauchg 8y ago
The goal is to provide the experience that many other languages have, where you don’t configure anything. You just run “$tool build”
122.
by Rauchg 8y ago
The goal is precisely to not just bundle, but incorporate important optimizations like the V8 Compile Cache ( https://github.com/zeit/ncc/issues/51 ), which is what inspired the project and name to begin with
123.
Ncc: Node.js Compiler Collection(zeit.co)
58 points by Rauchg 8y ago|22 comments
124.
by Rauchg 8y ago
What the parent comment is correctly saying is that for certain databases (that are oriented around stateful connections) you might benefit from a infrastructure-level optimization. However, this is not the case for all databases. Further
125.
by Rauchg 8y ago
Please keep in mind v1 will be around. We'll compel you to move by thoroughly reaching feature and use-case parity :)
126.
by Rauchg 8y ago
We definitely look forward to giving you tools here. One can conceive a `now dev` process that faithfully reproduces the cloud gateway.
127.
by Rauchg 8y ago
You'll find that nothing could bring us closer to this vision than making compute so remarkably inexpensive and scalable, out of the box, for everyone :) This is why serverless is so exciting to us.
128.
by Rauchg 8y ago
This is something that is only necessary for legacy databases. Modern database providers give you gateways that deal with a huge number of connections with no issues.
129.
by Rauchg 8y ago
Very important: you absolutely don't have to switch to or configure any cloud provider. However, it is a very healthy thing to understand the "behind the scenes" in case you need to interoperate with existing APIs or database
130.
by Rauchg 8y ago
To be perfectly clear: Now 2.0 is already fully rolled out to all regions. As a matter of fact, this is an example of executing `now --regions all` :) https://twitter.com/rauchg/status/1060616737215795200
131.
by Rauchg 8y ago
Servers will also eventually go cold, unless you pay for them 24x7. With the Now 2.0 design, you instead are very likely to not suffer from cold instantiation to begin with, due to the healthy constraints imposed by the system. In other wor
132.
by Rauchg 8y ago
We are planning to give you very simple hooks and integrations to support WebSockets (e.g.: PubNub or Pusher). For scalability reasons, it's likely you'll want to separate the code that deals with the "request-response"
133.
by Rauchg 8y ago
The data can be stored anywhere. Now is only in charge of executing your code in the best infrastructure provider available. It completely takes away the pain-points of setting up and managing the cloud infrastructure directly.
134.
by Rauchg 8y ago
As far as we are aware, no one until today had solved the problem of compiling to serverless functions. If you look at the solutions out there, they all involve you dealing with low-level APIs or config that have little to do with how you
135.
by Rauchg 8y ago
Logging is built-in. Just append /_logs to your deployment URL and you'll see all stdout and stderr of your underlying functions.
136.
by Rauchg 8y ago
We are quite confident that 2.0 can meet all the customer needs of 1.0, but going far beyond in terms of scalability, at a much lower cost. A great example of this is "doing work in a loop". Sure, you can spin up a process and t
137.
by Rauchg 8y ago
Keep in mind that the the intelligence that goes into the builders (which are OSS, which you can write your own of) is specifically around not making code changes. Surely, some code changes are necessary to go serverless (when considering l
138.
by Rauchg 8y ago
We have been running an internal beta of the jobs feature, and we'll keep everyone posted! We agree that invoking entrypoints periodically is a much better way to model most worker / daemon workloads than a "stateful event lo
139.
by Rauchg 8y ago
Auto-generation is a great way to put it. Cloud functions are an incredible primitive, but in our view, they constitute primarily a compilation target. Some small adjustments will be necessary when _importing_ large legacy codebases, but th
140.
by Rauchg 8y ago
In our upgrade guide we detail how you can break down a "server" that you would otherwise deploy as a monolithic container: https://zeit.co/docs/v2/platform/upgrade-to-2-0#don-t-rush-t... The limits
141.
Now 2.0(zeit.co)
415 points by Rauchg 8y ago|117 comments
142.
by Rauchg 8y ago
Very cool!
143.
by Rauchg 8y ago
On macOS, I recommend: `brew cask install docker`
144.
by Rauchg 8y ago
Haven't read the papers yet, but it immediately reminds me of Anna: https://databeta.wordpress.com/2018/03/09/anna-kvs/
145.
by Rauchg 8y ago
Thanks a lot for your feedback. I think adding playback controls on hover is going to help a lot. We picked video/gif as the delivery format to give people a real-life impression of performance. (I took the videos myself while using th
146.
by Rauchg 8y ago
> Somehow this sounds very expensive to me (like restarting Windows 2000 every hour just to avoid a BSoD, except that here it’s not that time consuming a process) The crucial difference is that the activation cost of booting up a full
147.
by Rauchg 8y ago
This is not supported nor maintained by us. Thanks a lot for bringing it to our attention. We will do our best to reach out!
148.
by Rauchg 8y ago
We will be announcing very clear pricing when it goes into GA. Needless to say, serverless makes for a much much cheaper (and robust) operation than VPS and traditional clusters.
149.
by Rauchg 8y ago
As we mentioned in the blog post, there is zero difference between a `Dockerfile` you execute locally and one that you give to us. [One of the differences is performance. You'll find that we can build and execute much more quickly :)
150.
by Rauchg 8y ago
Most databases are quite unfit for the serverless world that's becoming a reality, where the needs shift towards global replication, flexible horizontal scalability (sharding) and vertical (provisioned QPS). We like and use CosmosDB be

More ›