Building our full stack on javascript: The Basics

In the JavaScript world, it is very easy to type your technology stack using a set of small packages, each of which solves its own specific problem. And this is good, on the one hand, and on the other hand, you have no particular choice - frameworks that perform a wide range of tasks in JavaScript are not popular.

In this series of articles, I want to share my practical experience of building a JS stack.

• Article 1: Basics
• Article 2: Server
• Article 3: Customer

I switched to full-stack JavaScript from .NET. And after I had mastered the basics of Node, I had to spend a lot more time building my basic stack of technologies and how to organize the code. Unfortunately, there are not so many examples of final applications in JS, where you can see how to solve the main tasks for most projects, such as error handling, database access, code organization, authorization, and so on.

In order to always have at hand an example of using basic technologies, Contoso Express was written, an example of a full-stack application on JS. In our team, we use this project as a starting template for other projects, so it will be maintained and updated in the future.

Github: Contoso Express

Contoso Express is a remake of a famous Microsoft textbook for learning the basics of developing .NET web projects.

Original Contoso Univerisity

For many parts of the stack, it is difficult to stay with one alternative. Therefore, for some technologies there are alternative implementations. See ALT threads in Contoso Express repository.

These articles are for those who already know the basics, if you need to fill in knowledge in a certain area, look for the necessary additional resources .

Let's get started!

Why javascript

The reasons can be many, here is my top list:

• Simplicity : Basically, the libraries in Node have simple APIs that are easy to understand and work in an intuitive way. If it didn’t work with one library, it’s usually easy to find a good alternative.

  
  

• Control : The programmer builds the project infrastructure himself, selecting and combining small modules for specific tasks. It takes more time, but the result is worth it. Having understood once, the received experience is easy for applying further.

  
  

• Universality : JavaScript initially worked only on the client. Initially, along with Node, he moved to the server, and more recently it has become possible to successfully write desktop (Eletctron) and mobile applications. Moreover, for mobile applications there is an option of hybrid applications (a wrapper over the browser (Cordova) is used) or applications with a native interface (ReactNative, NativeScript). For Node there is a huge variety of libraries and it is easy to integrate it with other technologies, databases, cloud technologies, various formats and protocols, everything is there.

  
  

• Easy deployment : Node is very easy to deploy on a server: both on Linux and on Windows. After many years of working with .NET, deployment every time was an unpleasant test for me, on Node this process even brings pleasure. This is just a try.

  
  

• Performance : Node is asynchronous and does not block the execution process during lengthy operations, such as reading a file or accessing a database. This allows you to achieve a high level of performance when using a single thread (single threaded environment). On the other hand, computations in JavaScript are slower than in statically typed languages. For most projects, this is not a problem. If calculations are needed, and not just data transformations, then it is better to write a separate service on something else.

  
  

• One language on the server and client : This is convenient, as it allows, without effort, to transfer code between the client and the server, easier to develop and maintain.

  
  
• JavaScript language : JavaScript is very flexible and easy to use, many flaws in the language are fixed in the latest version of ES6, typing can optionally be added using TypeScript.

And this is not a complete list.

JS language options

Modern JavaScript can be written in several ways:

• ES5
• ES6 / ES7 next
• JS compiled languages ​​(TypeScript and others)

JavaScript Standards

• ES5 is a 2009 version of JavaScript, fully supported by all modern browsers and Node.

  
  

• ES6 is a recent approved language update. Development of standard support for all JS engines is still under development.

  
  
• ES7 / Next - not yet approved new JS features.

You can look at the current status of ES6 support at
Kangax ES6 .

Thus, in the near future, it is impossible to develop the client part right away on ES6, because there is no support in all browsers yet.

For the Node, the V8 engine is used, the current stable LTS version of which (4.x) does not support all the new features of ES6.

LTS (long term support) is the NodeJs version recommended for production use. The next LTS Node is expected in October 2016 and already has support for most of the features of ES6.

Transpiling

In order to use the features of ES6 / ES7, there are several transpilers that convert code written on ES6 to ES5.

Pay attention to the difference between transpilation and compilation: here .

Babel is the most popular transpiler from ES6 / Next to ES5.

TypeScript

TypeScript is a JavaScript extension language that adds static typing. Types in TypeScript are used to check the correctness of the code and additional features of refactoring and auto-hints. When TypeScript is transported to JS, all type definitions are omitted.

TypeScript supports many ES6 / ESNext features and can be used as a transpiler (instead of Babel).

In addition, there are additional constructs in TypeScript that are not found in JS - enums, inheritance and polymorphism in classes, and so on. They are transported to JS using auxiliary JS code.

Not all the features of TypeScript are equally useful; I’ll list the main categories:

• ES6 / ESNext - TS transpilation does a great job with it, although it is inferior to Babel in some aspects, for example, async / await in TypeScript is only available if you translate into the ES6 version. More on this in the next article.

  
  

• Static typing in the application code is the main reason for using TS, types in TS are optional, if the type is not specified, the type is "any", which means you can write and read any fields from this type, this translates the existing JS code to TS , much easier, no need to add types everywhere, but only where it makes sense. However, even if you do not describe types in TS, you will have many additional checks that help to detect trivial typo errors, even before you start the application. In addition, the hints in the code work well for you and you don’t have to look at what module methods and signatures they have.

  
  

• Typing third-party libraries - TS allows you to describe the structure of third-party libraries (for example, lodash or express), it allows you to control that you call methods with the correct parameters and allows you to see the methods and their signatures without using documentation. Unfortunately, the quality of such descriptions often leaves much to be desired, and when the description does not contain the required signature, it must be added manually. Sometimes it is easier not to use third-party descriptions (working with the library as with the type "any"). The problem is that now the descriptions of libraries in TS and the libraries themselves are most often written by different people. Most likely the situation will improve with the increasing popularity of TS.

  
  
• TS capabilities that are not found in JS - I would not recommend using them unnecessarily or if you are not using frameworks written directly on TS (for example, Angular2). Using such features makes the conversion of TS <-> JS much more difficult, they often change between different versions of TS.

What to choose

I would recommend choosing between ES6 and TypeScript. ES6 has a lot of useful add-ons that make development easier and more enjoyable and it is worth it to spend more time on the initial setup. On my projects, I switched to TypeScript, because it really seriously improves the development process, although it requires much more effort to configure and integrate. Whatever you choose, it’s good if you make an informed choice by working with both.

Development environment

WebStorm is a smart development environment with many built-in functions. Good support for typeScript. Paid. Configuration details for contoso express on project wiki . WebStorm is the main IDE in our team.

Visual Studio Code is a free environment from Microsoft. The best support for TypeScript, appeared recently, there are some familiar features. It develops quickly, is fully made and supports JavaScript plugins.

Others - you can use other JavaScript IDEs, such as Atom, Sublime, Brackets. TypeScript is more or less supported everywhere.

We select npm packages

Working with npm is easy. Just install and just publish your packages. Because of this, there are a lot of packages on npm (currently 330.000+).

Finding the right package is quite difficult. For any request on npmjs.com there are a lot of packages, and it’s not a fact that the main packages will be provided there for solving the necessary task.

Choosing a package is worth paying attention to: the number of downloads (popularity) and how often the package is updated (commits to the githab repository). Having found the right package, you can search for information on the Internet, so you can find other packages that perform similar tasks.

There is a site with an alternative search on npm npms.io , where characteristics such as popularity and regularity of support are immediately calculated.

In future articles I will describe the basic options for packages for basic development tasks. If the package name is in quotes (for example, "bluebird"), it means that the name with which the package is registered in npm and can be viewed at https://www.npmjs.com/package/{package_name } (i.e. the case of https://www.npmjs.com/package/bluebird ).

Database

SQL or NoSQL?

This question can not be answered unequivocally, depending on the specific situation. The most popular options for SQL / NoSql are PostgreSQL / MongoDb. The recent addition of JSON fields in PostgreSQL, makes it a very attractive option, combining the best of the worlds of SQL / NoSql. But despite this, MongoDb is still the most popular database for Node, and it may be easier to work, especially for those who have not had previous experience with SQL databases.

Database access

Working with a database you can use access directly with the help of a database driver or some kind of higher level ORM abstraction. If you do not have much interaction with the database, it is better to use access directly or a low-level abstraction, such as Knex (for SQL databases).

ORM

Sequelize is the most popular ORM for SQL databases. It provides a high level of abstraction over the database schema and supports basic SQL dialects (PostgreSQL, MySQL, SQLite and MSSQL). Used in Contoso Express.

Knex is a lower level abstraction. More like a query designer than a full-fledged ORM. It supports more dialects and gives more control over the generated SQL. There are functions for constructing a database schema and its migrations.

Bookshelf is another popular ORM based on Knex, the level of abstraction is lower than in Sequelize and many things need to be determined manually.

Mongoose - The most popular ORM for the MongoDB database most popular in JS

Direct connection

For all major databases, there are drivers of good quality, for direct connection. For Postgres, use "pg" or "pg-promise" packages.

What's next

In the next article I will talk about working with JS on the server. It will be more practical and will cover such things as choosing a web framework, organizing the project structure, working with configs, authorization, logging, error handling, and more.

I would be happy to comment comments, especially directly on the project code Contoso Express :)

Thanks to everyone who read to the end! Stay tuned!