Arbitrarily limiting JSON size/nesting because it blocks your event loop seems silly. What if a customer needs to give you something taking a while to parse?
Do the parsing in a web worker.
Gotchas from Two Years with Node
61–70 of 125 posts
Re: Gotchas from Two Years with Node
#62"Simple exceptions should be caught using a linter. There’s no reason to have bugs for undefined vars when they could be caught with some basic automation [...} It catches unhandled errors and undefined variables before they even get pushed to production. "
And there are people still thinking untyped languages are good for the server...
"Node is good when you're using a linter, when you're writing your back end in go, when you write MASSIVE unit tests..." May be it could be much simpler to use a more suitable langage, no ? Just saying...
Re: Gotchas from Two Years with Node
#63Earlier quoted context omitted.
I think it makes sense, early on you're still "figuring it out" so a flexible framework thats easy to dive into is advantageous. I don't see anything wrong with planning a rewrite X months into a product, since 90% of things don't make it to month X.
A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, giving competitors an opening. As an example, I recently migrated a Node app from MongoDB to Postgres. This ended up taking two and a half weeks, due to re-writing a fair portion of the server-side code. That's a long time to go without delivering new features…
"A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, giving competitors an opening."
On the flip side, over-engineering before launch means time spent NOT MAKING ANY MONEY because you haven't launched yet. It means pouring engineering effort into something whose success is still hypothetical.
If the biz folks want to know "why didn't you get it right the first time", ask them why they didn't become millionaires at their first jobs.
Re: Gotchas from Two Years with Node
#64> Plenty of times, there will be an uncaught exception which–through no fault of your own–bubbles up and kills the whole process. Really? I'm just a beginner with node.js, and I've been deeply frustrated by error handling, but if this is true, that's pretty damning. In just about every other web framework under the sun, you can go wild with exceptions and the worst you'll get is a 500 response for that request. (Yes,…
Same happens with Java, C++, and many other languages. There are web server packages on node that do catch errors that happen in synchronous code. For async, you can use promises, which take errors into consideration. I'm not sure what happens on unhandled async errors on other languages, I guess in Java you could have a dangling request (happened to me before) or it could crash the app (also happened to me before).…
You CAN get a white page or an error message by default, you don't "just get" them. It doesn't make any sense either because (surprise) you can and should configure that away. I see your edit but what's the point of that sentence other than to jab at PHP?
Re: Gotchas from Two Years with Node
#65Why not Java EE? Everything out of the box. Tried, proven, standardized. Well suited for startups: http://www.adam-bien.com/roller/abien/entry/a_java_ee_startu...
> Everything out of the box. Everything except that special sauce called green threads (or goroutines). They are quite popular these days for good reason - callbacks suck.
Blatant self-promotion here, but Java's got fibers (aka lightweight threads, aka goroutines), too: https://github.com/puniverse/quasar
BTW, I don't like the term green threads because they have a connotation of being scheduled onto a single OS threads, while fibers/lightweight threads employ parallelism.
Re: Gotchas from Two Years with Node
#66Earlier quoted context omitted.
why? PHP/ruby/python are successful too in the server space. Javascript,especially ES6, isn't worse than the formers. Devs should know by now that the dumbest tool that is good enough has good chances of being successful today. All these tech won't replace enterprise techs, but enterprise dev is a tiny percentage of all devs outthere.
> PHP/ruby/python are successful too in the server space. Again, from the perspective of someone that worked in a startup using TCL for server applications, I also don't get it. Other than being attractive to developers without formal education, and after a certain scale it becomes too costly to re-write. The work we developed at that company teached me never to use a technology stack without a JIT or AOT compiler fo…
That's really all about how you structure things. If you're building small, distributed, API-oriented applications -- it's really very easy to re-write your infrastructure. If you're building large monolithic applications, with in-band communication only, you're right, it is pretty tough.
The "formal education" piece is a little rough though. Count me among the developers working with Node.JS and a university degree.
Re: Gotchas from Two Years with Node
#67> Plenty of times, there will be an uncaught exception which–through no fault of your own–bubbles up and kills the whole process. Really? I'm just a beginner with node.js, and I've been deeply frustrated by error handling, but if this is true, that's pretty damning. In just about every other web framework under the sun, you can go wild with exceptions and the worst you'll get is a 500 response for that request. (Yes,…
By default the error handling for node is on an error it will in fact kill the process. It is a horrible design. So test your code :)
This not the same as other technologies. PHP will return an error but will not take your site down as node does.
Re: Gotchas from Two Years with Node
#68Earlier quoted context omitted.
A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, giving competitors an opening. As an example, I recently migrated a Node app from MongoDB to Postgres. This ended up taking two and a half weeks, due to re-writing a fair portion of the server-side code. That's a long time to go without delivering new features…
As a counter-example, I recently read Twitter was built on Rails 6 months after it was released. Once the concept was proven out, and the production app was failing like crazy (fail whale everywhere) - they rewrote their entire stack in Scala/on the JVM. Now should have Twitter spent the first 6 months of their life building out the perfect infrastructure with proven tools spending the little money they had mainly on…
Twitter was also originally built as a side project to amuse some friends. It wouldn't surprise me if someone took the view that they were writing a stupid little throwaway thing which everyone would probably get bored of, so why not try learning this hot new web framework everyone's talking about.
Re: Gotchas from Two Years with Node
#69The root of the eventloop issue is not Node-specific. The real underlying issue here is that one CPU core is given too much work while others are more or less idle. Offloading some of the work to another process naturally solves this issue - It doesn't really matter that this other process is a Go program or a Node.js one - Both approaches would have solved the problem. Attributing credit to Go itself for solving the…
> In Node.js, it's really easy to identify process boundaries since the child_process module forces you to put code into different files and communicate via loosely coupled IPC channels.
I find that approach troubling. Process boundaries are expensive, because you have to serialize and everything each time you cross a boundary.
I also haven't used Go, but I think you can get great clarity with something like Akka's Actor model. And to do it you don't have to pay a large serialization tax until you move particular actors to other machines.
Re: Gotchas from Two Years with Node
#70Node, like Rails before it, was an enabler tech - it enabled non-developers to build stuff. Those with experience would have gone direct to something like Erlang in the first place, carefully sidestepping the dog that is Go.