How we used Node.js to build real-time award flight search(blog.milewise.com) |
How we used Node.js to build real-time award flight search(blog.milewise.com) |
and as a former ITA Software employee, i can scoff and say they aren't actually doing anything resembling flight search. they're just scraping websites and APIs. node.js might be fine for that, but so is anything else. at that level it's more a matter of preference than capability.
I ask because (1) the airline websites tend to be _really_ slow and (2) they tend not to find the cheapest/best flights - an ITA search can often beat them.
1) Part of our reason for using Node+Socket.IO is to deal with the problem of having a bunch of different sources returning data over a wide spread of time.
2) You'd be surprised about the airline sites. While they don't necessarily have the widest variety of good fares, airline will often reserve their cheapest fares for their own sites (called Last Seat Availability).
He's awesome, super talented and incredibly fun to work with.
It's more just an annoyance of the language. Specifically, anonymous functions are must easier in JavaScript, so it was just easier to write read and write maintainable code.
In Python, you are limited to only passing in simple lambda functions (although deferreds do get around this issue somewhat). It's not a show stopper but when combined with all the other advantages of Node.js, it just made the decision to switch a lot easier.
We also ran into a lot of issues related to poor garbage collection in Python and were using up a lot of memory. This was not related to dangling references but rather Python's permanent allocation of Integer and Float objects.
Finally, we just saw better performance out of V8 than Python (although we never tried anything else besides vanilla Python 2.6).
For our specific problem, Node.js worked well. It's not always the right solution. We will write a more detailed blog post soon with specifics of how we used Node.
That's pretty specious. You can easily write a function defined inside a function that you can pass by just naming it. "Anonymous" functions are just syntactic sugar. Furthermore, writing a new python named function is easier (fewer chars) to write than a javascript anonymous function, so the "sugar" gained is moot.
Finally, as you build more and bigger systems, you realize that those multi-line anonymous functions you had you actually want to be named (for documentation) and tested. So you'll end up de-anonymizing the complex (multi-line) ones anyway.
As for speed, why not compare a jit (v8) to a jit (pypy) ?
EDIT: This information does seem to be covered in the FAQ, but you don't see the link to the FAQ anywhere when you are trying to capture user accounts on initial signup: https://secured.milewise.com/faq
This is definitely an area for metrics and user testing, but probably better for us to err on the side of caution =)
Just a side note, but do you use some other collection API such as Yodlee or are you maintaining your own data scrapers for all the airline sites?
The "fibers" utility is quite popular. There are also several different promise libraries, and a few code-translation approaches that simulate coroutines.
They all build on top of the very simple EventEmitter and continuation-passing-style ("callback") style that the node-core API uses.
As a JavaScript luddite, I prefer passing functions around and listening to events :)
Node worked better for them, what's the problem?
It creates less noise and busy work in your code.
Explicitly specifying functions like having to pre-declare all your variables at the top of your scope.
I really don't understand why whenever somebody switches to node from python people pounce on them like this, as if people aren't allowed to find a particular syntax annoying?
We have our own account scrapers augmented with a partner API from AwardWallet for the more esoteric programs (CVS Rewards anyone?)
It would have been a little odd for me to say "Nice use case for Python" considering the original post was about Node, and specifically said they tried writing it in Python but "writing asynchronous code in Python is like using your keys to open a beer bottle." That also made me laugh.
In fact, the original article specifically talked about why Node.js was a good choice for this use case. I agree. Not that you couldn't do it in other ways. Erlang would also be a good choice here, I'm sure. There is always more than one way to do most anything. Still, and in spite of the fact that Node might be getting too much hype, it is an excellent tool for this type of async need.
> Node gets a lot of attention despite
> not doing much of anything new
Most people close to the project (Ryan, me, Mikeal, Felix, etc.) are usually pretty quick to point out that node does virtually nothing that hasn't been done before. Async IO is not new. Event loops aren't new. IOCP isn't new. JavaScript isn't new.If anything, node's success so far has been a result of combining established technologies in ways that make it easy for more people to write reasonably fast programs that use the internet in fun and interesting ways.
Novelty isn't really what it's all about. If anything, I look at novelty as a hazard. Most ideas are bad, and it's hard to tell when they're new. If you can take some existing good ideas, and make them more fun, that tends to be a more successful strategy (or at least a more enjoyable one.)