Introducing node. js

A few years ago, completely abandoned the ASP, completely out of the Microsoft direction. Web development, in the corporate team, uses node. js, Mongodb, and Git, replacing ASP. NET MVC, SQL Server, and TFS. At the time, it was a high-risk decision. Everyone is accustomed to the net, and the accumulation of knowledge and technology is concentrated in this direction.

On the face of it, it was only my personal annoyance over the years that followed Microsoft, which led to a halt to the entire technical line, and from a technical point of view, the team was different. A few years past, all kinds of hard and toss, sometimes complaining to each other, we finally natural, accustomed to the new direction, no one back to the meaning of ASP, as Kate, but ... Must be compared, today is obviously more relaxed.

Of course, at first it wasn't all smooth, every choice, every one of them was Wang Veronica, and her melon was absolutely unique. In the face of many Wang, we also difficult to get objective comparisons, choices often need to do their own. After two projects, it really makes everything smooth. The programming, the various details, and even the different design ideas that are involved in it, have obviously experienced many iterations. There is no way, node. JS is relatively new, there are not many applications on a large scale in some companies, and this type of text is certainly rare, and it is difficult to find other people to generalize the regular team development model.

Let me briefly describe a company that is mainly based in node. js, well, confined to small and medium-sized companies ... Perhaps there is some help, less go some detours. Our final choice is to

1, Ide:webstorm, no other.

2, Version management system: Git, unique.

3. Unit test: Jsamine, the front and rear end is common.

4, front-end frame: angular.js, let Ember.js and a few old frame sexy lying in bed bar.

5, Server: pure static page + very little use jade+rest

6, socket.io+ independent Small module: Of course, this is almost the only alternative way to communicate with the client two-way. However, it is important to note that in most cases, we have very few opportunities for service-side push, which is a very convenient way to use this as a standalone small application.

7, asynchronous Process Control: Promise is the only choice, and from the beginning to be forced to use, can not be ignored, this is related to the great differences in design thinking, and even whether we can really be in the direction of node. js to persist. We use Q.js, which is consistent with the miniature version q.js used by the front-end angular.js, reducing the learning cycle.

8, front and back of the common code: As long as the front-end is likely to use the code, must be in line with the specification, to achieve the front-end sharing.

I know most of the majority, or most of the technical articles, talk is not extreme, the mean, in the affirmation of one to two choices, will also identify with other options, well, this is a very mature style, very kind personality. I'm only going to extremes to give the only answer to every choice.

Not because I'm immature, well, I'm also a super senior architect, senior programmer, and process management expert ... Ah, is there any other halo and hat to wear?

Now that we have a focus on the selection of the collision between the left and right, we come to the conclusion that our choice is unique ... In most cases, when you see this handy text, you no longer need to repeat the painful process. I think this is true kindness ... Why are you so polite? Oh, this may be a little "you don't have to think, the yuan capital to help you think about", this is not good ... I'm going to list some of the main reasons for the selection below. To avoid falling from the sky and aggregating into a team of bricks.

One, the IDE's choice: webstorm

The first problem we encountered was language, C # go to JS. Of course, this is actually not too big a problem, the ASP. Net-oriented team, basically everyone has the relevant grammar knowledge. Especially happy is that node. js, developed in the backend, does not need to consider browser differences like front-end development in general. The initial consensus was simple thinking: the Js+node system library + many optional package =c#+.net frameworks. Well, of course, the total space occupied by node. JS is about ten megabytes, and what does the IIS and. NET Framework add up to? Dozens of times times the volume difference, even if the two are equally matched, is not that despised under that too stingy hard side?

Of course, to get started, the first question is the IDE. Initially, I was tossing around a person, using visual studio+iisnode+tfs, various inconveniences. 1 weeks later turned to webmetrix,3 days after the dingy abandonment. Then a variety of ides like running water-like try ... Webstorm was also initially rejected.

In a month of dark night, a pair of confused eyes, staring at the ceiling.

I picked up Webstorm and took a finer step to try out the various features it claimed. Syntax Auto-awareness, Debug for node. js, git integration, Unit Test framework integration ....

Well, all the alternatives have turned into clouds.

Second, version management system: Git

Choosing Git, initially because TFS is no longer available, we've already said goodbye to the great visual Studio 20XX. So... The best-rated, apparently Git,github has grown to the point where other open-source communities are stunned, and even TFS has to support git. This is too vulgar: everyone one-sided say a thing good, this thing is good.

But, but that one, but. This thing is a lot more trouble than TFS. Oh, we don't really like the people who knock orders, do we? I am the first person to use and then train other people, although the process lasts for three days ... But:

1, distributed is really the most humane approach: no longer need home and the company server synchronization to sync, not the same city is no longer a problem.

2, branches become the main thinking ... The premise is that mergers and conflicts are surprisingly simple.

3, the most delighted is that, combined with webstorm, almost to the effect of using TFS in VS, we have not entered the command manually for several years.

So, what else do you have to think about?

Three, unit test: Jasmine

This choice is purely due to my innate laziness. Front end angular.js, unit test with Karma...jasmine, I started to try to use Jsmine on the server side, to solve the integration with IDE, promise test, we still need to do unit testing in different ways?

Iv. Asynchronous Process Control: Promise,q.js

Anise beans, there are n kinds of writing. So, experts tell us that the process of handling asynchronous processes, in addition to the callback function mode, there are event mode, subscription release mode, Promise. My answer is only one, Promise,in q.js. In our first project, we avoided using too many third-party libraries, and all of the asynchronous processes were handled honestly with a nested callback function. This, although tortured everyone, but it is clear that everyone can quickly understand, fast to do. However, in the first project, when we encountered complex computations with more than 10 steps, layers of nesting almost caused an insane person to appear in our team ... In order to avoid parents to come to the door, veteran ... I spent the night wandering through the async.js (an asynchronous process library with almost a monopoly), q.js and some other ways.

I am ashamed to say that promise's understanding seems easy, but in two hours, I found it difficult to really understand, it is very rare things, I looked in the mirror, looking at the human head that has always thought good performance, frustrated sigh. Under the pressure of project progress, I chose async.js ...

After the free time, I finally after two times twists and turns, thoroughly understand the concept of promise, the use of details. Before the start of the second project, I spent 2 days in the team and set up a very impersonal programming specification: This project does not allow callback functions, does not allow async, and only uses Q.js Promise. Any code that does not conform to this specification will be returned, and I will answer any questions about it.

What is the reason? Without promise,node.js programming would be an unusually dull, dull, unreliable, quack-style chore. I rise to this height, I am expected to face 1000 tomatoes plus 2000 eggs, but the believers have eternal life. Flat process processing, unified programming mode, chained programming style, unmatched exception handling. Async.js implementation of asynchronous processes, all the code is relevant. Promise can do all the steps are irrelevant, well, think of the most basic "encapsulation" it? This is all the reason why, the choice of Q, but also to reduce the difficulty of learning---we are in the Angular.,js front, has blurred the use of miniature version of the q.js.

Five, the front-end frame: angular.js

The front-end frame, in recent years like the underground world of mice, the number is very large.

Angular.js, Microsoft's knockout, someone is respected as the first ember.js .... Wait, wait.

After I have tested multiple, choose Angular.js, which is easy to get started, but the learning curve is a steep frame. Reason: When I compare, I find that Angular.js's code volume is much leaner than most frameworks, and it is a fairly balanced compromise between ideal and reality. In combination with rest, we can almost easily make all-static applications, of course, every place is not refreshed.

There are no drafts, and they are written as if there were no changes. A few other choices, relatively better understanding some, not wordy. Using MongoDB may be a mistake ... Not supporting transactions is a very deadly problem. But it also persisted for a long time ... Our team has always been unable to evade NoSQL, and NoSQL's first choice is still mongodb, at least from the thinking side that everyone is now very familiar with and accustomed to. node. JS is really in the enterprise as the main direction, the domestic estimate is not too much, a lot of information is scarce. I have built 119874409 groups, welcome you to exchange.

The age of node. js, already 10 years old, does not seem easy to become one of the true mainstream, but I myself, still very optimistic about the future development, considering its easy cross-platform, unique asynchronous mode, and C + + natural affinity, even in the desktop development, Android on the platform of some attempts, node. JS is highly likely to be one of the important technical directions.

Introducing node. js