7 ms·

When should I use Node for back end?

52 points by atulanand94 10y ago

dvdhnt 10y ago
The main point of the article is correct; NodeJS is not for CPU-intensive applications. Here's a more verbose article on the topic, circa 2013: https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-...
ankurdhama 10y ago
There are modules that you can use to make node work for CPU intensive tasks. Search for WebWorkers. The real idea is don't do CPU intensive tasks in the event loop thread.
- iends 10y ago
  We all have different performance requirements, but in my experience, when you actually care about the performance of CPU intensive task, child_process.fork or WebWorkers are still insufficient. Instead, sometimes you use node native modules, sometimes you separate you child_process.spawn something written in Go, C++, or Rust(,etc), and sometimes you set up a separate work "queue" to pass work either on the same machine or over the network. I've used both kafka, zeromq, or even just files on the s3. A linux domain socket is nice too.
  - ankurdhama 10y ago
    The performance of the CPU bound task and performing any CPU bound task on the main IO thread are 2 different things. The article was about the problem you face when you do CPU bound task on the main IO thread. The WebWorkers and other approaches are about how to avoid using the IO thread to do CPU tasks. How the performance of those CPU tasks is depends on other factors. You can use WebAssembly or asm.js code to reach the performance of natively compiled code.
RSZC 10y ago
I don't necessarily buy being blocked by CPU-intensive operations as a rationale as to why you shouldn't Node, given that it's pretty trivial to offload these onto a separate process. https://github.com/LearnBoost/cluster https://github.com/LearnBoost/cluster - one I've used
- nrjdhsbsid 10y ago
  It is non trivial to share state between node threads. The state is shuffled around outside of the VM unlike go, Java, and c#. In those languages, the overhead of sharing a variable are basically zero. In node you get sharing at basically the speed of TCP local sockets on the machine. So maybe 5GBps. With natively threaded languages you get sharing at the speed of the cpu cache, orders of magnitude faster If performance is important enough that multithreading comes into play, don't use node.
  - ilaksh 10y ago
    See `webworker-threads`.
    - nrjdhsbsid 10y ago
      They don't share variables low level, so the problem remains. In Java and similar languages the variables are shared at the machine level, including atomics
    - nrjdhsbsid 10y ago
      They don't share variables low level, so the problem remains. In Java and similar languages the variables are shared at the machine level, including atomics
bikamonki 10y ago
I use NodeJS like AWS lambda functions but running on my own tiny VPS (Digital Ocean droplets). Why instead of lambda? B/c I have zero restrictions on NPM packages and many other things I can use. Now, I do not write full APIs, instead I use everything a BAAS has to offer (like Firebase) and complement what it lacks. For example: - When a Firebase ref changes I listen to the event in Nodejs and update a full text search index elsewhere. - When a Firebase ref is created I send the appropriate transactional email/push/sms. - Do data validations before pushing to Firebase. So in general, I do things that cannot/should not be done on the client-side while still opting for serverless architectures. PS: Parse.com was great in that it had server-side code that was run on events like object updated/created. The code was NodeJS. In sum, it had lambda-like functionality already built-in. But Parse.com closed shop. Not sure if any of its spin-offs are offering a good service at decent prices.
harshaw 10y ago
Ok, so for me the problem for Node is: a) So you reimplemented all of the goodness of twisted in javascript? :) b) and you have to debug that new pile of code? c) with a language (in it's original form) that has a bunch of issues, despite being fun to develop in Maybe Node with an ES6 backend? Maybe that's better. However, from my perspective, event based development works for some apps but is a total PITA for traditional workloads (websites). I would think about Node for a messaging use case, or message processing.
0xCMP 10y ago
While it's true that node can handle CPU intense tasks with WebWorkers or some other clustering there are also memory concerns. Node can doesn't mean it should with the exception of keeping your stack simpler (a single language). But that's a compromise to achieve a different goal. I personally like Go more these days because it doesn't have these problems, it's very easy to do concurrency, and it's memory overhead is much lower. This in contrast to my other favorite option, python, which is a nicer language imo, but it's concurrency story is worse and memory overhead is about on par (varying from case to case, but my point being they're both much more than Go).
santoriv 10y ago
I imagine I'll get downvoted for participating in the language flame wars but.... I've been working on a NodeJS backend at my main gig for the last two years. For two years before that I was working on an backend application written in C#. Based on my experience with those two systems, the answer to the question "When should I use Node for the back end?" should be: Only if your main language is javascript and you don't have the time and/or inclination to learn something else. For me, working with C# was massively more productive. Static typing, robust async/await, and the fantastic tooling you get with Visual Studio + Resharper are huge benefits. Dynamic typing, callbacks and/or weird promise logic, and dodgy open source libraries which may not be very well documented or maintained are huge downsides for Node JS. I would never choose to write a new project's backend in Node JS. YMMV.
- nikcub 10y ago
  Have you tried TypeScript on the backend? I've seen that a couple of times now recently - .NET shops adopting nodejs on the backend via TypeScript and the feedback has been positive.
  - santoriv 10y ago
    I used Typescript on the front end a couple of years ago but not on the back end yet. I imagine that it would be better than es6 since there would be some typing. I'd still rather go with C# and not have to deal with callback/promise land.
    - jayajay 10y ago
      ES6 and ES7 fixes everything here except strict typing, by the way.
      - Arnavion 10y ago
        async-await is in neither of those, though TS does support it and downlevels it to ES5/ES6.
nrjdhsbsid 10y ago
I beg to differ with node being the "best choice" for IO intensive ops. Java performance will be better on IO as well, as long as you're using NIO or something like EPOLL native bindings in Netty, which is asynchronous like node but also multi threaded. The point is that node is not that fast. If performance is paramount don't use it. Node really shines when you need to use client side libraries on the server. The two best uses I've seen is server side rendering of pages and html5 canvas for browser based painting apps
- klodolph 10y ago
  This is a bit of a fine point to make here, but it's not necessary to use stuff like NIO or EPOLL for all IO intensive programs. It depends on the amount of time you expect the threads to be waiting. If the wait times are low, you can expect traditional IO and threads to be quite competitive. EPOLL / NIO is still great for stuff like HTTP front-ends.
  - ec109685 10y ago
    Because of HTTP keep alives?
    - klodolph 10y ago
      Yes, that's exactly right. But there's also factors like the slow loris attack, where malicious clients hold a connection open and send a few bytes at a time, never completing the HTTP request. For these attacks, it makes sense for client connections to use the smallest amount of server resources feasible.
- doctorpangloss 10y ago
  In line with my experience as a Java 8 NIO and latest node user, node basically performs identically to the best Netty implementation in IO-bound tasks. That parity could be attributed to relentless optimization of a fundamentally pretty straightforward problem in V8 that finally made it to the latest node. My experience matches the TechEmpower benchmarks, which you should check out here: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ . They didn't get much discussion when posted.
embwbam 10y ago
When your team is composed of node developers. I would choose it over Python or Ruby, because Typescript and Flow are great type systems. Source: lead node dev / CTO since it came out. Currently using Haskell for all new projects.
- nrjdhsbsid 10y ago
  Is this flamebait lol?
- codygman 10y ago
  I would guess that you'd fall in love with Purescript: http://www.purescript.org/ http://www.purescript.org/
  - embwbam 10y ago
    I like purescript a lot. But the elm community has won me over. It's well designed and productive.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
- tome 10y ago
  > Currently using Haskell for all new projects. Would you mind saying where you work?
  - embwbam 10y ago
    I have a small contracting business. (2 employees) I spend some negotiating power on being able to choose what technology I use.
jayajay 10y ago
This is why node is powerful when used with AWS Lambda, you can treat CPU bound tasks as if they were IO. You can also do this by routing the job to a different processor on the same machine. Node is best when used as a relay or hub between many services and clients. Let those services do the computing work, let node manage everything and do the IO work. Node is kind of like an airport. Airports let you order food, alcohol, and even other cities. But as soon as you order, all of the work is offloaded to a third party -- the restaurant, the bar, or the airplane -- allowing the airport to handle someone else.
sauronlord 10y ago
Never
- nrjdhsbsid 10y ago
  I feel you. My god js is still horrible. Why anyone would willing develop more than they have to in it is beyond me. Yeah we have ES(x) coming and typescript and node yay! All of the stuff coming to js has existed in better form in other mainstream languages for many years. Even stuff js still doesn't even have on the roadmap like multithreading, true static typing, and compilation Are mainstream js developers really that ignorant of what is out there to suggest running js on the server all the time?
  - bobbytherobot 10y ago
    > Are mainstream js developers really that ignorant of what is out there to suggest running js on the server all the time? No. At least not the high caliber ones. There are those that know only know JavaScript and will try to make everything fit. Although, you can say that about people who only know Java, or Python, etc.
rajangdavis 10y ago
Pardon my ignorance, but does Node improve as the V8 engine (or Microsoft's Chakra engine) improves? Also, when/if GraalVM becomes public, would Node then be more suitable for CPU intensive apps? I love javascript but never quite grok'd it as a server side language. I wouldn't mind using it, but have never found a good use case and this article hasn't really convinced me to delve into it. Edit: I have found that it has been pretty neat for some command line integrations, but lately, I have been falling back to Ruby.
- nrjdhsbsid 10y ago
  Yeah but I doubt it will ever hit parity with c#/Java/go. The lack of static typing and other fundamental languages choices will keep it from ever being as fast as those. V8 and friends were built out of necessity not because js was ever a good lang to begin with. I really have no idea why anyone would take a language as terribly designed as JavaScript and try to put it everywhere. Non existant typing system, crazy semantics, and lack of true multithreading will always make it second rate to the others
  - rajangdavis 10y ago
    Actually, I could be mistaken, but Node on top of GraalVM should give it closer parity with Java. I saw this video (https://www.youtube.com/watch?v=lYGfD2H99Ls https://www.youtube.com/watch?v=lYGfD2H99Ls) earlier this year, would be interested to see when and if this could be implemented in the mainstream.
    - nrjdhsbsid 10y ago
      V8 does almost everything JVM does, the problem is mostly in js dynamic typing and weak object implementation. There's a lot of runtime checks that just can't be optimized out. I would expect js to reach maybe a third of JVM performance but thats probably the limit
- EdSharkey 10y ago
  If you write your javascript in a way that is easy for V8 to JIT, then I think you'll benefit most from progressive enhancements made in the underlying engine. There's a lot of talks and articles on V8 performance, for example: http://mrale.ph/v8/resources.html http://mrale.ph/v8/resources.html Surprisingly, very boring, predictably shaped prototypey classes written in the "hidden classes" style they prescribe will JIT compile amazingly well. I think a lot of the fancy uses of JavaScript to roll types with mixins and traits or simply to sidestep needing the 'new' keyword to instantiate objects miss out on lots of performance benefits on V8. Honestly, where does all the hate for 'new' come from? Prototypey classes work fine once you understand how to roll them/extend them, and 'new' is a real keyword in the language, what's to hate?
danschumann 10y ago
I'd still ( and have ) used node for cpu intensive stuff. If you have a long running computation that can be broken down (mine was 500-2000 steps), you can break the single process by `setTimeout(...,0)` the next step, so other stuff can serve pages. Or, you can break it out into a c job.
- RSZC 10y ago
  You might want to check out process.nextTick: https://howtonode.org/understanding-process-next-tick https://howtonode.org/understanding-process-next-tick
EGreg 10y ago
You should use Node.js for back end when you make WEB APPS and want to deliver real time updates and run background processes. Node.js has a very robust ecosystem that integrates well with front end Javascript.
devoply 10y ago
Go with Go, my son...
epynonymous 10y ago
i'm going to get downvoted on this for sure, but basically if you enjoy writing mindless, infinitely nested callbacks then nodejs is for you. i liked the package manager npm, but otherwise i prefer golang all the way for backend code.
- X0nic 10y ago
  I prefer Rails or Elixir, but golang is a solid choice.
  - epynonymous 10y ago
    came from ror/sinatra, but really like the deployment ease of golang, just copy a binary, dont need rvm, ruby interpreter, gems, etc. i think the performance is much better for golang, but i dont like golang's orms and the templating languages really suck relative to haml, etc. i mostly use golang for restful api backends and mobile on the frontend (mobile first), but for dynamic websites, golang is not that interesting.
bitwize 10y ago
When your boss tells you to.
ilaksh 10y ago
When the front-end is JavaScript and may share code with the backend or when you find an applicable package in npm. Or when you know JavaScript better than other languages.
cdegroot 10y ago
One good spot that comes to mind is when you implement "Backend For Frontend" style APIs for your clients in a microservices environment. Assuming you have a single page app in JS, you can have the front-end team own their specific API implementation and have them work in the language they know best. There's often also the possibility to reuse some code between the two. Apart from that, I'm a JS hater, so I would personally always avoid Node - I neither like the language nor the server-side model, I don't think either one scales well, and there are better solutions out there for the server side (besides the JVM and .NET based stuff in the other comments, I like BEAM-based things like Elixir these days).

52 points by atulanand94 10y ago

The main point of the article is correct; NodeJS is not for CPU-intensive applications. Here's a more verbose article on the topic, circa 2013: https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-...

ankurdhama 10y ago

There are modules that you can use to make node work for CPU intensive tasks. Search for WebWorkers. The real idea is don't do CPU intensive tasks in the event loop thread.

iends 10y ago
We all have different performance requirements, but in my experience, when you actually care about the performance of CPU intensive task, child_process.fork or WebWorkers are still insufficient. Instead, sometimes you use node native modules, sometimes you separate you child_process.spawn something written in Go, C++, or Rust(,etc), and sometimes you set up a separate work "queue" to pass work either on the same machine or over the network. I've used both kafka, zeromq, or even just files on the s3. A linux domain socket is nice too.
- ankurdhama 10y ago
  The performance of the CPU bound task and performing any CPU bound task on the main IO thread are 2 different things. The article was about the problem you face when you do CPU bound task on the main IO thread. The WebWorkers and other approaches are about how to avoid using the IO thread to do CPU tasks. How the performance of those CPU tasks is depends on other factors. You can use WebAssembly or asm.js code to reach the performance of natively compiled code.

RSZC 10y ago

I don't necessarily buy being blocked by CPU-intensive operations as a rationale as to why you shouldn't Node, given that it's pretty trivial to offload these onto a separate process. https://github.com/LearnBoost/cluster https://github.com/LearnBoost/cluster - one I've used

nrjdhsbsid 10y ago
It is non trivial to share state between node threads. The state is shuffled around outside of the VM unlike go, Java, and c#. In those languages, the overhead of sharing a variable are basically zero. In node you get sharing at basically the speed of TCP local sockets on the machine. So maybe 5GBps. With natively threaded languages you get sharing at the speed of the cpu cache, orders of magnitude faster If performance is important enough that multithreading comes into play, don't use node.
- ilaksh 10y ago
  See `webworker-threads`.
  - nrjdhsbsid 10y ago
    They don't share variables low level, so the problem remains. In Java and similar languages the variables are shared at the machine level, including atomics
  - nrjdhsbsid 10y ago
    They don't share variables low level, so the problem remains. In Java and similar languages the variables are shared at the machine level, including atomics

bikamonki 10y ago

I use NodeJS like AWS lambda functions but running on my own tiny VPS (Digital Ocean droplets). Why instead of lambda? B/c I have zero restrictions on NPM packages and many other things I can use. Now, I do not write full APIs, instead I use everything a BAAS has to offer (like Firebase) and complement what it lacks. For example: - When a Firebase ref changes I listen to the event in Nodejs and update a full text search index elsewhere. - When a Firebase ref is created I send the appropriate transactional email/push/sms. - Do data validations before pushing to Firebase. So in general, I do things that cannot/should not be done on the client-side while still opting for serverless architectures. PS: Parse.com was great in that it had server-side code that was run on events like object updated/created. The code was NodeJS. In sum, it had lambda-like functionality already built-in. But Parse.com closed shop. Not sure if any of its spin-offs are offering a good service at decent prices.

harshaw 10y ago

Ok, so for me the problem for Node is: a) So you reimplemented all of the goodness of twisted in javascript? :) b) and you have to debug that new pile of code? c) with a language (in it's original form) that has a bunch of issues, despite being fun to develop in Maybe Node with an ES6 backend? Maybe that's better. However, from my perspective, event based development works for some apps but is a total PITA for traditional workloads (websites). I would think about Node for a messaging use case, or message processing.

0xCMP 10y ago

While it's true that node can handle CPU intense tasks with WebWorkers or some other clustering there are also memory concerns. Node can doesn't mean it should with the exception of keeping your stack simpler (a single language). But that's a compromise to achieve a different goal. I personally like Go more these days because it doesn't have these problems, it's very easy to do concurrency, and it's memory overhead is much lower. This in contrast to my other favorite option, python, which is a nicer language imo, but it's concurrency story is worse and memory overhead is about on par (varying from case to case, but my point being they're both much more than Go).

santoriv 10y ago

I imagine I'll get downvoted for participating in the language flame wars but.... I've been working on a NodeJS backend at my main gig for the last two years. For two years before that I was working on an backend application written in C#. Based on my experience with those two systems, the answer to the question "When should I use Node for the back end?" should be: Only if your main language is javascript and you don't have the time and/or inclination to learn something else. For me, working with C# was massively more productive. Static typing, robust async/await, and the fantastic tooling you get with Visual Studio + Resharper are huge benefits. Dynamic typing, callbacks and/or weird promise logic, and dodgy open source libraries which may not be very well documented or maintained are huge downsides for Node JS. I would never choose to write a new project's backend in Node JS. YMMV.

nikcub 10y ago
Have you tried TypeScript on the backend? I've seen that a couple of times now recently - .NET shops adopting nodejs on the backend via TypeScript and the feedback has been positive.
- santoriv 10y ago
  I used Typescript on the front end a couple of years ago but not on the back end yet. I imagine that it would be better than es6 since there would be some typing. I'd still rather go with C# and not have to deal with callback/promise land.
  - jayajay 10y ago
    ES6 and ES7 fixes everything here except strict typing, by the way.
    - Arnavion 10y ago
      async-await is in neither of those, though TS does support it and downlevels it to ES5/ES6.

nrjdhsbsid 10y ago

I beg to differ with node being the "best choice" for IO intensive ops. Java performance will be better on IO as well, as long as you're using NIO or something like EPOLL native bindings in Netty, which is asynchronous like node but also multi threaded. The point is that node is not that fast. If performance is paramount don't use it. Node really shines when you need to use client side libraries on the server. The two best uses I've seen is server side rendering of pages and html5 canvas for browser based painting apps

klodolph 10y ago
This is a bit of a fine point to make here, but it's not necessary to use stuff like NIO or EPOLL for all IO intensive programs. It depends on the amount of time you expect the threads to be waiting. If the wait times are low, you can expect traditional IO and threads to be quite competitive. EPOLL / NIO is still great for stuff like HTTP front-ends.
- ec109685 10y ago
  Because of HTTP keep alives?
  - klodolph 10y ago
    Yes, that's exactly right. But there's also factors like the slow loris attack, where malicious clients hold a connection open and send a few bytes at a time, never completing the HTTP request. For these attacks, it makes sense for client connections to use the smallest amount of server resources feasible.
doctorpangloss 10y ago
In line with my experience as a Java 8 NIO and latest node user, node basically performs identically to the best Netty implementation in IO-bound tasks. That parity could be attributed to relentless optimization of a fundamentally pretty straightforward problem in V8 that finally made it to the latest node. My experience matches the TechEmpower benchmarks, which you should check out here: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ . They didn't get much discussion when posted.

embwbam 10y ago

When your team is composed of node developers. I would choose it over Python or Ruby, because Typescript and Flow are great type systems. Source: lead node dev / CTO since it came out. Currently using Haskell for all new projects.

nrjdhsbsid 10y ago
Is this flamebait lol?
codygman 10y ago
I would guess that you'd fall in love with Purescript: http://www.purescript.org/ http://www.purescript.org/
- embwbam 10y ago
  I like purescript a lot. But the elm community has won me over. It's well designed and productive.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
tome 10y ago
> Currently using Haskell for all new projects. Would you mind saying where you work?
- embwbam 10y ago
  I have a small contracting business. (2 employees) I spend some negotiating power on being able to choose what technology I use.

jayajay 10y ago

This is why node is powerful when used with AWS Lambda, you can treat CPU bound tasks as if they were IO. You can also do this by routing the job to a different processor on the same machine. Node is best when used as a relay or hub between many services and clients. Let those services do the computing work, let node manage everything and do the IO work. Node is kind of like an airport. Airports let you order food, alcohol, and even other cities. But as soon as you order, all of the work is offloaded to a third party -- the restaurant, the bar, or the airplane -- allowing the airport to handle someone else.

sauronlord 10y ago

Never

nrjdhsbsid 10y ago
I feel you. My god js is still horrible. Why anyone would willing develop more than they have to in it is beyond me. Yeah we have ES(x) coming and typescript and node yay! All of the stuff coming to js has existed in better form in other mainstream languages for many years. Even stuff js still doesn't even have on the roadmap like multithreading, true static typing, and compilation Are mainstream js developers really that ignorant of what is out there to suggest running js on the server all the time?
- bobbytherobot 10y ago
  > Are mainstream js developers really that ignorant of what is out there to suggest running js on the server all the time? No. At least not the high caliber ones. There are those that know only know JavaScript and will try to make everything fit. Although, you can say that about people who only know Java, or Python, etc.

rajangdavis 10y ago

Pardon my ignorance, but does Node improve as the V8 engine (or Microsoft's Chakra engine) improves? Also, when/if GraalVM becomes public, would Node then be more suitable for CPU intensive apps? I love javascript but never quite grok'd it as a server side language. I wouldn't mind using it, but have never found a good use case and this article hasn't really convinced me to delve into it. Edit: I have found that it has been pretty neat for some command line integrations, but lately, I have been falling back to Ruby.

nrjdhsbsid 10y ago
Yeah but I doubt it will ever hit parity with c#/Java/go. The lack of static typing and other fundamental languages choices will keep it from ever being as fast as those. V8 and friends were built out of necessity not because js was ever a good lang to begin with. I really have no idea why anyone would take a language as terribly designed as JavaScript and try to put it everywhere. Non existant typing system, crazy semantics, and lack of true multithreading will always make it second rate to the others
- rajangdavis 10y ago
  Actually, I could be mistaken, but Node on top of GraalVM should give it closer parity with Java. I saw this video (https://www.youtube.com/watch?v=lYGfD2H99Ls https://www.youtube.com/watch?v=lYGfD2H99Ls) earlier this year, would be interested to see when and if this could be implemented in the mainstream.
  - nrjdhsbsid 10y ago
    V8 does almost everything JVM does, the problem is mostly in js dynamic typing and weak object implementation. There's a lot of runtime checks that just can't be optimized out. I would expect js to reach maybe a third of JVM performance but thats probably the limit
EdSharkey 10y ago
If you write your javascript in a way that is easy for V8 to JIT, then I think you'll benefit most from progressive enhancements made in the underlying engine. There's a lot of talks and articles on V8 performance, for example: http://mrale.ph/v8/resources.html http://mrale.ph/v8/resources.html Surprisingly, very boring, predictably shaped prototypey classes written in the "hidden classes" style they prescribe will JIT compile amazingly well. I think a lot of the fancy uses of JavaScript to roll types with mixins and traits or simply to sidestep needing the 'new' keyword to instantiate objects miss out on lots of performance benefits on V8. Honestly, where does all the hate for 'new' come from? Prototypey classes work fine once you understand how to roll them/extend them, and 'new' is a real keyword in the language, what's to hate?

danschumann 10y ago

I'd still ( and have ) used node for cpu intensive stuff. If you have a long running computation that can be broken down (mine was 500-2000 steps), you can break the single process by `setTimeout(...,0)` the next step, so other stuff can serve pages. Or, you can break it out into a c job.

RSZC 10y ago
You might want to check out process.nextTick: https://howtonode.org/understanding-process-next-tick https://howtonode.org/understanding-process-next-tick

EGreg 10y ago

You should use Node.js for back end when you make WEB APPS and want to deliver real time updates and run background processes. Node.js has a very robust ecosystem that integrates well with front end Javascript.

devoply 10y ago

Go with Go, my son...

epynonymous 10y ago

i'm going to get downvoted on this for sure, but basically if you enjoy writing mindless, infinitely nested callbacks then nodejs is for you. i liked the package manager npm, but otherwise i prefer golang all the way for backend code.

X0nic 10y ago
I prefer Rails or Elixir, but golang is a solid choice.
- epynonymous 10y ago
  came from ror/sinatra, but really like the deployment ease of golang, just copy a binary, dont need rvm, ruby interpreter, gems, etc. i think the performance is much better for golang, but i dont like golang's orms and the templating languages really suck relative to haml, etc. i mostly use golang for restful api backends and mobile on the frontend (mobile first), but for dynamic websites, golang is not that interesting.

bitwize 10y ago

When your boss tells you to.

ilaksh 10y ago

When the front-end is JavaScript and may share code with the backend or when you find an applicable package in npm. Or when you know JavaScript better than other languages.

cdegroot 10y ago

One good spot that comes to mind is when you implement "Backend For Frontend" style APIs for your clients in a microservices environment. Assuming you have a single page app in JS, you can have the front-end team own their specific API implementation and have them work in the language they know best. There's often also the possibility to reuse some code between the two. Apart from that, I'm a JS hater, so I would personally always avoid Node - I neither like the language nor the server-side model, I don't think either one scales well, and there are better solutions out there for the server side (besides the JVM and .NET based stuff in the other comments, I like BEAM-based things like Elixir these days).