DEV Community: Dan T.

Threads without efforts in Odi (Node.js)

Dan T. — Tue, 05 Feb 2019 15:48:31 +0000

Introduction

Multithreading is a process of executing two or more threads simultaneously.The most programming languages provide an API for convenient work with threads and parallelism. The developer can focus on application logic, not on the communication channel, synchronization or architecture setup.

Node 10.5 added support for worker_threads module with an experimental flag. But starting from Node 11.7 this feature is available out of the box. It’s a good start for multithreading paradigm in Node.

worker_threads has a huge potential, so support for this module was added to Odi from early stages. As always, Odi goal is to provide convenient, clean and minimalistic API (with magic 🧙‍♂️), so developers can focus on development, not on setup.

Project Setup

From the last article, Odi got new CLI command which initializes project,
defines scripts and installs all required dependencies.

    odi init

Currently, there are only a few options:

    -j, --jsx-templating  add jsx templates
    -d, --database        add typeorm integration

Structure

By default, the project will have the following structure.

All required dependencies will be installed during command execution based on the template type. Also if -j flag was provided, views folder will be added in the project root directory.

Source Files

There are 2 predefined source files in the basic template.

The index.ts file that contains basic Odi configuration. By default, the
server port is set to 8080

And the home.controller.ts file with a simple controller definition.

That’s enough to start with Odi and development.

Scripts

For now, the only npm start script is available out of the box. In the next
release, npm test command will be available using Mocha and Chai.

Simply run the following command

    npm start

This script includes compilation and actual running, so after completion, you can easily open the browser and check http://localhost:8080 URL.

Threads

By design, Node is single threaded with non-blocking I/O. Such approach has many pros and cons. The main advantage is simplicity. The developer does not need to care about threads manipulations, data synchronization and etc. But any resource-intensive tasks will block the event loop.

Worker threads can process resource-intensive operations, so the main thread is always available. It’s really important for Server-Side applications, as any blocking task will delay accepting and processing of new client requests.

Task

Let’s create the resource-intensive (blocking) function for getting an answer
(Yes or No) based on random values generation.

Mathematical operations in most cases CPU intensive, so it’s a great example for our goals. Running this function with 200_000_000 factor takes ~5 sec for execution.

Blocking

As mentioned above, any blocking operation won’t allow other tasks to execute until it’s finished.

The best way to understand blocking is UI. Let’s add simple CLI loader to our application using Ora library, just for example.

First of all, we need to install it.

    npm install ora @types/ora

And change the Controller method in the following way. When the handler is triggered, the loader will appear in the terminal and will be spinning until our calculations are finished. Also, the time that was used for request processing will be printed.

Let’s start our server and trigger handler from the browser.

The loader is not spinning, as our calculation blocked the process. The loader must have the possibility to re-render frames every 80 milliseconds but can’t do it, as the event loop is blocked by getAnswer call.

Consequences

Let’s imagine that we have this code in the real application. The handler will block accepting and processing new clients requests. It will seriously affect the client experience. Such operations must be placed into other application or in the other thread.

Workers

Odi provides convenient API for multithreading. The developer does not need to think about any type of setup.

Definition

It’s really easy to define Worker in Odi application and container. There are
some similarities with Service definition. Let’s wrap getAnswer function.

Only Worker decorator is required for definition. Now we can inject it in the
controller as other dependencies.

Note, await keyword must be added before the worker method call, even if it’s not async, as communication between threads is done in an asynchronous way.

That’s all! 🧙‍♂️ The method will be executed in another thread and the result will be returned to the main.

Review

Now, example with UI loader can be tested.

Everything is working. The loader is spinning, as the code is running in another thread, so UI can re-render frames.

Check

To be sure that the method was processed in another thread, simply change getAnswer in the next way.

Information about thread will be available right in the console.

Comparison

As you can see above, zero configuration is required for workes setup and processing.No event emitters, event handlers, filename and etc are required like in the official example. Odi cares about initialization, messaging, method calls and errors handling.

Limitations

There are no limitations in addition to basic ones. Remember that the worker is something like another application, so runtime instances can’t be accessed between different threads. Also, Dependency Injection container can’t be accessed over the threads, so every single thread will have its own container.

Use Cases

Basically, workers threads can be used in next approaches:

Background and scheduled tasks
Resource-intensive operations
Queue-based processing

Those approaches can be easily improved and adapted for each particular need, but all of them leads to performance improvements and application flexibility.

Thanks for reading! Feel free to leave any feedback, ideas or questions.

If you like Odi, simply support us with start on GitHub. 🌟✨

Odi-ts / odi

🌪🌌 Opinionated, Declarative, Idiomatic framework for building scalable, supportable and reliable enterprise applications.

TypeScript framework for creating enterprise-grade (web) applications with simple and minimalistic API, that allows you to focus on business logic. Based on declarative and imperative programming, inspiried by ASP.NET / Spring.

Check Docs for more details.

Odi provides feature set for creation of easy supportable and scalable web applications.

Features Overview:

MVC
Full-typed DI / IoT
Authentication
WebSockets
TypeORM integration
GraphQL
AOP
SSR

For future updates check Roadmap
Got an idea, proposal or feature request? Feel free to Submit it!

🚀 Getting Started

Install npm package
npm install odi --save
Install reflect-metadata
npm install reflect-metadata --save
Import reflect-metadata (for example in index.ts):
import "reflect-metadata";

Enabled the following settings in tsconfig.json

"emitDecoratorMetadata":  true, 
"experimentalDecorators":  true

🌪 Overview

Controller

Controllers serve as a simple yet powerful routing mechanism in a minimalistic style.

@Controller('foo')
export class FooController extends IController {      
        
    @RoutePatch('{id}'

…

View on GitHub

Keep reading, much more interesting things will be shipped in the next updates!
😉🧙‍♂️

Building chat with Odi (Node.js)

Dan T. — Fri, 18 Jan 2019 21:06:19 +0000

Republish

Sorry for republishing the same story. My teammate accidentally deleted the previous publication. He thought that we published it before the release date 😢 Thanks for understanding 😜

Introduction

The chat application is the very common example that used to show simple real-time communication between client and server. This tutorial describes how it can be easily done with Odi,TypeScript server-side framework for
Node.js.

Project Setup

We are going to develop the application that not only establishes the real-time communication channel but also renders frontend to the client, including required assets.

Basic Settings

Let’s set up the Odi project. First of all, we should initialize package.json
and tsconfig.json files. We can do it with two simple commands.

    npm init -y
    tsc --init

And install Odi.

    npm install odi

Also, we need to modify tsconfig.json file, as there are few options that must be edited. Odi actively uses decorators and metadata, so we need to enable these features.

    "experimentalDecorators": true,
    "emitDecoratorMetadata": true

Another thing is target option. By default, it set toes5 but there are
several things that are not supported in is this specification. As we are
progressive, let’s set it to the latest version

    "target": "ES2018"

Project Structure

We are going to have different folders for views, assets and server source code.

src— server source code.
views— JSX templates that will be rendered to clients.
assets— client-side JS and CSS files.

JSX templates are tsx files that must be compiled. Add views folder to
rootDirs in tsconfig.json file and setup outDir.

    "outDir": "./build",
    "rootDirs": ["./src", "./views"]

Gettings started

Odi is based on the Dependency Injection pattern, so every application component will be automatically imported, instantiated and injected.

Only folder with source files must be specified, then Odi can scan it for importing application components (Controllers, Services, Repositories and etc).

Main File

Create index.ts file in src folder. It will be the server entry point file.

    import { Core } from "odi";
    import { join } from "path";

    new Core({
        sources: __dirname,
        server: {
            port: 8080,
            socket: true,
            static: {
                root: join(__dirname, '../../assets'),
                prefix: '/assets'
            }
        }
    }).listen(() => console.log("Server successfully started!"));

We just need to instantiate Core class. Core constructor accepts a single argument, settings object. There are a lot of possible options, but for now, we need only several of them.

First of all, we need to specify sources property. It’s required setting for Odi application. As index.ts file in src folder, which we choose for server-side code, we can use __dirname to set current directory.

port property is also required. It binds the server on the specified port.

Now about the following part:

    socket: true,
    static: {
         root: join(__dirname, '../../assets'),
         prefix: '/assets'
    }

We must enable sockets and set options for serving static files All files from the assets folder are available by URL with /assets prefix.

Installing Dependencies

Odi framework automatically includes only several packages that are required. All other dependencies for different features are optional, so they need to be installed only if you use a certain feature.

For example, if you are going to build a simple REST server, you don’t need GraphQL, WebSockets, SSR and other packages.

We want to have WebSockets and Templating (JSX) in our chat application. So, let’s install missing packages:

    npm install socket.io react react-dom

That’s all, Odi will automatically import it. As you can see, socket.iois used under the hood for real-time functionality. Also React packages is required for templates processing.

Now we can start writing our code :)

Application

We are going to create a web server, that renders HTML to the client, using
templates, serves files for the client (JS, CSS) and set up a real-time
communication channel using WebSockets for chat. Let’s add history to our chat. So, the last 10 messages will be saved in our system.

Message and History

Message will be pretty simple, only username and text fields. We can do it
with a simple interface, as we are not going to use a database.

    export interface Message {
        username: string;
        text: string;
    }

And history service

    @Service()
    export default class HistoryService {
        private store: Message[] = [];

        getMessages() {
            return this.store;
        }

        addMessage(message: Message) {
            if(this.store.length > 10)
                this.store.shift();

            this.store.push(message);
        }
    }

Our store is a simple array of messages. And few methods for store management. If we get more than 10 messages, we simply remove the first message from the array.

As you can see, Service decorator was used for HistoryService class to set is as a service component. Service is singleton in Dependency Injection Container. Now it can be injected into others application components.

Put all this code in history.ts file in src/services folder.

Web Socket

Create chat.socket.ts file in the src/sockets directory with the following
code.

    import { Socket, OnEvent, ISocket, Autowired } from "odi";
    import HistoryService, { Message } from "../services/history";

    @Socket('chat')
    export default class ChatSocket extends ISocket {

        @Autowired()
        history: HistoryService;

        @OnEvent('massage:send') 
        onmessage(message: Message) {
           this.history.addMessage(message); 
           this.emit('message:new', message);
        }
    }

We defined /chat namespace with handler for message:send event. If
message:send event is fired, all clients that connected to this namespace will be notified with message:new event and message data.

As you can notice Socket decorator defines namespaces. Leading slash is not required. To set up method as the handler for certain event, use OnEvent
decorator, that accepts event name as the argument.

Also, we injected HistoryService using Autowired decorator. history field
of ChatSocket class will be initialized by Odi, so you don’t need to do
anything additional.

The only thing, you can see such error from TypeScript

    [ts] Property 'history' has no initializer and is not definitely assigned in the constructor.

Odi automatically initializes injected fields, so just disable this check in
tsconfig.json

    "strictPropertyInitialization": false

Templating (JSX)

There a lot of templating processors — EJS, Jade, Pug. But there are a lot of
limitations and inconveniences with those technologies. In most cases, to have IntelliSense and code highlight for templates, you need to install an extension for IDE/Editor.

In Odi, JSX powered by React is used for templating. You can simply create components with JSX. But remember, it’s only for templates, any logic, listeners or client-side code will be ignored during rendering.
(Currently, we are working on full SSR.Hope it will be released soon)

We need to tell TypeScript compiler, that we are going to use React JSX.
In tsconfig.json

    "jsx": "react"

Layout

Let’s create our layout component layout.view.tsx that will be a wrapper for all pages. As was mentioned above, all templates will be in views folder.

    import React, { SFC } from 'react';

    export const Html: SFC = ({ children }) => (
        <html lang="en">
            <head>
                <meta charSet="UTF-8" />
                <meta name="viewport" />
                <meta httpEquiv="X-UA-Compatible" content="ie=edge"/>
                <link href="/assets/index.css" type="text/css" ... />
                <title> Simple chat </title>
            </head>
            <body>
                {children}
            </body>

            <script src="path/to/socket.io" />
            <script src="/assets/index.js" />
        </html>
    )

For socket.io-client library we can use CDN. So simply replace
path/to/socket.io in the script tag with the following link
https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.2.0/socket.io.js

Client js file was specified in the second script tag. We will create it a
little bit later in assets folder.

Chat Components

Actually, we need 3 components for our chat:

Message representation
Controls (Send button, message input, username input)
Chat container

I think we can put all these components in 1 file, chat.view.tsx

    import React from 'react';
    import { Message } from './services/history.service';

    export const ChatMessage = ({ username, text }: Message) => (
        <div>
            <b>{username}: </b>
            <span>{text}</span>
        </div>
    )

We can use Message interface as props type for ChatMessage component.

Let’s add chat controls. id attribute was used for convenience, as we are
going to use js on the client side without any libs or frameworks.

    export const ChatControlls = () => (
        <div className="message-box">
            <input placeholder="User" id="user-input" />
            <input placeholder="Message" id="message-input" />
            <button> Send </button>
        </div>
    )

And the last thing, chat wrapper.

    interface ChatProps {
        messages: Message[];
    }

    export const Chat = ({ messages }: ChatProps) => (
        <div className="chat">
            <div className="container">
              {messages.map(msg,i) => <ChatMessage key={i} {...msg} /> )}
             </div>
            <ChatControlls />
        </div>
    )

This component accepts an array of messages (our history) in props to render it on page load.

Now we can put everything together and define our page component page.view.tsx

    import React from 'react';
    import { Chat } from './chat.view';
    import { Html } from './layout.view';
    import { Message } from './services/history.service';

    interface ChatPageProps {
        history: Message[];
    }

    export const ChatPage = ({ history }: ChatPageProps) => (
        <Html>
            <Chat messages={history} />        
        </Html>
    )

That’s all about templating for our chat application. I have several lines of
CSS that I will include it in the source code, that you can find at the end of
the article.

We can move to controllers.

Controllers

Controllers serve as a simple yet powerful routing mechanism. Controller methods are mapped to web server paths. The value returned by the method is sent as the response.

In order to create a Controller, you must use the @Controller decorator and inherit the IController class. The decorator sets the component type, so the DI (dependency injection) container can detect what the class will be used for.

For our chat, we need only one controller to render a template to the client. As we are going to use JSX inside the controller file, it must have tsx file
extension.

So, let’s create render.controller.tsx in src/controllers folder.

    import React from 'react';
    import { Controller, IController, Get, Autowired } from "odi";
    import { ChatPage } from '../../views/page.view';
    import HistoryService from '../services/history.service';

    @Controller()
    export default class RenderController extends IController {

        @Autowired()
        history: HistoryService;

        @Get index() {
            return <ChatPage history={this.history.getMessages()}/>;
        }
    }

As you can see, we injected our HistoryService into history property. Also, the handler for / path with Get method was defined. We can simply return our JSX component as a result, Odi automatically detects that it’s a template and renders it as simple HTML for the client (web browser).

Starting Application

Now, we can start our application and see what we got. Let’s specify start script in package.json file:

    "scripts": {
        "start": "tsc && node build/src/index.js"
    }

Running npm start command compile our source code and run server entry file.

Let’s open the browser and check localhost:8080

As you can see, we have just empty chat without any functionality, as we did not specify the client index.js into assets folder.

Client

First of all, let’s get references for chat container and controls.

    const button = document.querySelector('button');

    const messageInput = document.querySelector('#message-input');
    const usernameInput = document.querySelector('#user-input');
    const container = document.querySelector('.container');

When a new message comes, we need to append it as a child in container
element. We need the function for creating elements that represent messages.

    function createMessage({ username, text }) {
        const element = document.createElement('div');

        element.innerHTML = `
            <b>${username}: </b>
            <span>${text}</span>
        `;

        return element;
    }

Then, let’s connect to our chat namespace and add the event handler for message:new event. When this event is fired, the message element will be appended to the container.

    const socket = io('/chat');
    socket.on('message:new', message => {
        const messageElement = createMessage(message);
        container.appendChild(messageElement);
    });

And the last step, onclinck handler for our button.

    button.onclick = () => {
        socket.emit('massage:send', { 
            text: messageInput.value, 
            username: usernameInput.value
        });

        messageInput.value = "";
    }

We are collecting data from inputs and sending it as message:send event. Also, the message input text will be cleared after every send.

Now we can refresh the page, and see what we have got.

After refreshing the page, we will have history our messaging.

Sandbox

You can check the source code and interact with the application right here:

PS

Thanks for the reading! If you like Odi, please support us with a simple start on GitHub

Odi-ts / odi

🌪🌌 Opinionated, Declarative, Idiomatic framework for building scalable, supportable and reliable enterprise applications.

Check Docs for more details.

Odi provides feature set for creation of easy supportable and scalable web applications.

Features Overview:

MVC
Full-typed DI / IoT
Authentication
WebSockets
TypeORM integration
GraphQL
AOP
SSR

For future updates check Roadmap
Got an idea, proposal or feature request? Feel free to Submit it!

🚀 Getting Started

Install npm package
npm install odi --save
Install reflect-metadata
npm install reflect-metadata --save
Import reflect-metadata (for example in index.ts):
import "reflect-metadata";

Enabled the following settings in tsconfig.json

"emitDecoratorMetadata":  true, 
"experimentalDecorators":  true

🌪 Overview

Controller

Controllers serve as a simple yet powerful routing mechanism in a minimalistic style.

@Controller('foo')
export class FooController extends IController {      
        
    @RoutePatch('{id}'

…

View on GitHub

Also, if you are looking for more information, you can check previous articles and docs:

If you have any ideas or questions, feel free to leave them! Thanks a lot! :)

Odi - server-side framework

Dan T. — Thu, 27 Dec 2018 23:58:33 +0000

Introduction

Hi guys!

I am currently working on the server-side TypeScript framework. My team already widely use this framework in various e-commerce and ERP projects. Structure and semantic were inspired by other popular frameworks like Spring and ASP.NET .

List of main goals:

Testable, supportable, scalable
Minimalistic, idiomatic, clear
Intuitive, readable, understandable
Powerful

Currently, there are a lot of possibilities:

Describing routing using controllers and decorators
Powerful, full-typed Dependency Injection
Incoming data validation (using AJV) with various set of decorators
TypeORM integration (Repositories injection, Transactional support using CLS)
Extendable JWT-based authentication

All parts of the framework are fully typed and integrated with the whole infrastructure.

For the best performance, under the hood, Fastify is used. The framework is declarative, but also avoids using decorators were it's possible. So, it's keep everything simple, clean and minimalistic.

Overview

Controller

Controllers serve as a simple yet powerful routing mechanism in a minimalistic style.

    @Controller('foo') 
    export class FooController extends IController {      

        @RoutePatch('{id}')     
        bar(id: string, payload: FooDTO) {         
            ...some updates..          
            return Ok();     
        } 

        @Get index() {
            return 'Foo';
        }
    }

So, as you see, there no need to provide any additional param decorators for injection data from the HTTP request. It's just a small controller overview, there are a lot of other possibilities.You can read more in docs.

Dependency Injection

Odi has powerful dependency injection mechanism out of the box.
(Let's imagine that we already have FooRepository)

    //foo.service.ts
    @Service()
    export class FooService {

        @Autowired()
        repository: FooRepository;

        public getFoo(id: string) {
            return this.repository.findOne(id);
        }
    }


    //foo.controller.ts
    @Controller('foo')
    export class OrderController extends IController {

        @Autowired()
        fooService: OrderService;

        @Get async '{id}' (id: string) {
            const foo = this.fooService.getFoo(id);

            if(!foo)
                return NotFound();

            return foo;
        }
    }

As you can see, all dependencies will be automatically provided to all application components.

Currently, Odi support 3 ways of injection:

By constructor
By property
By method

Classes that are not Odi components can participate in DI. You can simply define behaviour with preset properties and constructor args.


    class Pet {
        ...
    }


    define(Pet)
        .set('default', {
            constructorArgs: [...],        
            props: {...},
            type: 'singleton'
        })
        .set('special', {
            constructorArgs: [...],        
            props: {...},
            type: 'scoped'
        });

DTO

It's a common scenario when web server should validate data before processing. DTO can optimize and automate this process.

    @Data()
    export class TodoDTO {

        @MaxLength(80)
        title: string;

        @IsOptional()
        @MaxLength(255)
        desctiption: string;

}

Then, DTO class should be added as an argument for the controller method

    @Controller('todo')
    export class TodoController extends IController {

        @Autowired()
        todoService: TodoService;   

        @Post async index(payload: TodoDTO) {
            ...
        }
    }

And it's all! Odi will automatically inject the validated request body in this argument. If there are some errors during validation, 400 status code will be sent with errors description.

Odi provides a wide set for DTO description, supporting nested DTOs, arrays, enums and etc.

To Sum up

It was a small overview of some features. If you interested in more, check the Docs.

Coming Soon

AOP
GRPC integration
GraphQL
CLI
OpenAPI
and more...

Odi-ts / odi

🌪🌌 Opinionated, Declarative, Idiomatic framework for building scalable, supportable and reliable enterprise applications.

Check Docs for more details.

Odi provides feature set for creation of easy supportable and scalable web applications.

Features Overview:

MVC
Full-typed DI / IoT
Authentication
WebSockets
TypeORM integration
GraphQL
AOP
SSR

For future updates check Roadmap
Got an idea, proposal or feature request? Feel free to Submit it!

🚀 Getting Started

Install npm package
npm install odi --save
Install reflect-metadata
npm install reflect-metadata --save
Import reflect-metadata (for example in index.ts):
import "reflect-metadata";

Enabled the following settings in tsconfig.json

"emitDecoratorMetadata":  true, 
"experimentalDecorators":  true

🌪 Overview

Controller

Controllers serve as a simple yet powerful routing mechanism in a minimalistic style.

@Controller('foo')
export class FooController extends IController {      
        
    @RoutePatch('{id}'

…

View on GitHub

Docs

Also, we aim to support Deno in the future.

Difference between Nestjs

Basically, there only a few common things with Nestjs: MVC Pattern and declarative style. But there are a lot of differences, like the whole infrastructure, decorators use, dependency injection and many others. To sum up differences:

Nestjs is heavily using decorators, Odi reduces this usage to the minimum (To keep code clean and readable).
Odi provides built-in validation out of the box for HTTP data via AJV.
DI/IoT behavior is very different. There is much more magic in Odi, in few words :)
Authentication out of the box, that fully integrated with other framework modules.
Controller and WebSockets processing

In the future, it will be the big difference between all integrations and technologies, as Odi was designed from the beginning in another way than Nest.

In my sight, Nestjs is more about Spring, but our framework is more ASP :)

P.S

From the beginning, the framework was designed as opensource. I really need your feedback, it's very important for me!

P.P.S

My small kitten Nancy asking for stars on github 😄😄

DEV Community: Dan T.

Threads without efforts in Odi (Node.js)

Introduction

Project Setup

Structure

Source Files

Scripts

Threads

Task

Blocking

Consequences

Workers

Definition

Review

Check

Comparison

Limitations

Use Cases

More

Odi-ts / odi

🌪🌌 Opinionated, Declarative, Idiomatic framework for building scalable, supportable and reliable enterprise applications.

🚀 Getting Started

🌪 Overview

Controller

Building chat with Odi (Node.js)

Republish

Introduction

Project Setup

Basic Settings

Project Structure

Gettings started

Main File

Installing Dependencies

Application

Message and History

Web Socket

Templating (JSX)

Layout

Chat Components

Controllers

Starting Application

Client

Sandbox

PS

Odi-ts / odi

🌪🌌 Opinionated, Declarative, Idiomatic framework for building scalable, supportable and reliable enterprise applications.

🚀 Getting Started

🌪 Overview

Controller

Odi - server-side framework

Introduction

Overview

Controller

Dependency Injection

DTO

To Sum up

Coming Soon

Links

Odi-ts / odi

🌪🌌 Opinionated, Declarative, Idiomatic framework for building scalable, supportable and reliable enterprise applications.

🚀 Getting Started

🌪 Overview

Controller

Difference between Nestjs

P.S

P.P.S