-
I am usually skeptical of articles on node.js, because I feel like there is so much hype around it, and it is usually not substantively better. However, switching from 30 servers to 3 is pretty impressive. What I am wondering is how they can maintain so many long-lived connections simultaneously, where every view change there’s some sort of database/cache call (ie blocking). Do they just not have that many simultaneous connections? Is there something about node that makes it really ideal for this? Do they have other machines that sit behind the 3 servers that do other logic? Obviously the data sits on other machines, are there also other machines for mediating which data nodes they hit? What exactly are the responsibilities of these three servers? Do they send HTML over the wire, or just raw data that the client plugs into templates?
-
-
I guess if they are long-lived so it doesn’t really matter, but for shorter lived calls, it does matter, because each database call means they are keeping a file descriptor and process open longer. At linkedin levels of volume, that matters. We know that asynchronous doesn’t mean that the process disappears, it just gets sent to the background until the data it’s waiting for is back.
-
-
Read Ikai’s article. The original Rails stack was routinely communicating between data centers. This would negatively impact performance for a node stack too. But it would hurt the scalability a synchronous server stack far more. Node/any asynchronous code can do as it pleases between slow requests. Rails/any synchronous server has to sit patiently and wait for a response.
A better network architecture would have served them well too and perhaps obviated some of the desire for a rewrite.
-
-
-
No, no, no, no. Normal people don’t always use the email field properly. The might put the username in the email field and the email in the username. Just check for an @. There is no email in the world outside your server that you can sent to without an @.
-
I did that for a time (which I mention in the article), but it’s still a superfluous check on top of an activation email. If your users are typing the wrong values into your registration form, perhaps you need better labeling or placeholder text? Display an error that the activation email couldn’t be sent. But why add superfluous checks?
-
Because it’s a lot easier to validate a form than write code that 1. catches bounce emails 2. sorts out which are invalid emails and which are transient problems 3. flags the user so they don’t generate more bounces 4. prompts them to re-enter their email address until they do.
-
Unless you just delete users who haven’t activated their account by email within a time span that works for your app.
-
-
That’s likely possible, except you can have the same problem with the server side validation. What his article suggested and we both agree on is a client side warning.
-
-
-
-
-
(my experience with coffeescript is mostly limited to reading blogs about it.) My biggest gripe with coffeescript is that too much of the javascript bleeds through. It’s a little more than syntactic sugar, but in many places not much more.
Compare with, say, chicken scheme, which outputs C code. You wouldn’t know that (and don’t need to know that) if you’re writing scheme code. Or clojure, where you are exposed to the jvm and class library, but for the most part the idiosyncrasies of the java language are masked away.
I have in general found little use for languages specified as “it’s like this other language, but different in these ways…”. (exception: sass, and possibly other superset languages where it’s not different; it’s just more. groovy may be another example, but I don’t actually use it.)
Yeah. A standard defense of CoffeeScript is to compare it to a C –> Assembly compiler, but the C-ASM gap is big and CS-JS gap isn’t.
I remain confident that CoffeeScript will be completely forgotten in 5 years (except by unfortunates who inherit code and have to pay for the sins of their parents).
If you have the javascript output, it’s not too hard to throw away the coffeescript and refactor the javascript it generated.