Cats-app using NestJS
Best way to evaluate a framework is to get rolling with a tutorial and follow each step to the word of it. NestJS is no different in this perspective i.e. of getting started. However, we ventured in charting a different trajectory to get started. This is the log of our experience as we ventured in this trajectory.
The approach
Author of the framework KamilMyśliwiec (@kamilmysliwiec[1]) has committed sample application[2] “cats-app” in GitHub to the demonstrate the prowess of the framework. What else could be a good starting point other than the author of the framework itself demonstrating the prowess of his own creation.
Though, we observed Kamil’s sample to be more technical than any other such sample say e.g. AngularJS’s sample application PhoneCat[3].
Our Oblog – First dispatch
We cooked this “Oblog” term for this post which expands to Observation Log. To begin we start by installing the CLI for NestJS.
|
npmi -g @nestjs/cli
|
This command fetched 208 packages with skipping optional dependencyfsevents(in a Windows 10 Home edition).
CLI gets us the freedom to run commands which otherwise would need a prefix’ish style before the actual commandnodee.g.
[1]https://github.com/kamilmysliwiec
[2]https://github.com/nestjs/nest/tree/master/sample/01-cats-app
[3]https://docs.angularjs.org/tutorial
|
node “[path to npm global directory]\node_modules\@nestjs\cli\bin\nest.js” new project
|
CLI shortens the command further to
|
nestnew project
|
Without digressing deep into the CLI and its necessity (as a developer tool) or the lack of necessity (dissoluteness into brevity) let us get the code sample from GitHub. We will need git command which can be downloaded from the Git’s own website. Once installed you will be able to run the following command –
|
git clone https://github.com/nestjs/nest.git “.”
|
Above code clones the repository to the directory from which you have executed the above command. You can very well replace the “.” in the above command with full path to any other directory to which you wish to download the code.
samplefolder of the repo contains the sub-folder01-cats-appwhich is also the app used to narrate the features of NestJS in the documentation.
| Tools of trade | For a Node.js application best place to inspect an unknown code is begin with package.json file. It gives a good perspective into the application and its complexity. More the dependencies, more the complexity and vice versa etc. |
Package.json file other than the standard tags contains NPM scripts[1] section where we can notice author have defined two different ways in which the app will behave. In developer machine it will run directly from TypeScript codebase using the TypeScript REPL package for Node.js. However, if run in production mode i.e.npm start –prodthe sample will be transpiled to pure JavaScript which is then run using Node.js runtime. We are referring to the following lines of code from the sample –
|
“scripts”: {
“start”: “ts-node src/main.ts”,
“prestart:prod”: “tsc”,
“start:prod”: “node dist/main.js”,
…
},
|
The above best demonstrates the claim made by the author when the framework is attributed as – “Uses progressive JavaScript”.
[1]https://medium.freecodecamp.org/introduction-to-npm-scripts-1dbb2ae01633
In the same file when we inspect the dependencies (particularly overlooking at the version number); we will find all packages in the Nest.js repository are all referred inferring the possibility of using them all which will give us the reference point to use them appropriately in some another functional context.
Also, typically all of them (though not necessarily) but evolve at same pace i.e. version number. We are referring to the following statements in the file –
|
“dependencies”: {
“@nestjs/common”: “^5.3.0”,
“@nestjs/core”: “^5.3.0”,
“@nestjs/microservices”: “^5.3.0”,
“@nestjs/testing”: “^5.3.0”,
“@nestjs/websockets”: “^5.3.0”,
“class-transformer”: “^0.1.7”,
“class-validator”: “^0.8.1”,
“reflect-metadata”: “^0.1.12”,
“rxjs”: “^6.0.0”,
“typescript”: “^2.8.0”
},
|
The devDependencies section gives us the insight on tooling required for the developer to build upon the sample.
We just warmed up ourselves with the ecosystem of the sample codebase. Our next dispatch of Oblog will explore codebase’s other aspects in the context of framework.
The Editorial Board
Teamware Solutions
