SWOT Analysis

1. Strengths

1.1. Easy Development

Anyone can easily make a network system.

It's difficult to make network system because many of computers are interacting together to accomplish a common task. Therefore, the word 'perfect' is inserted on every development processes; requirements must be analyzed perfectly, use-cases must be identified perfectly, data and network architectures must be designed, perfectly and mutual interaction test must be perfectly.

However, with TGrid and Remote Function Call, you can come true the true Grid Computing. Many computers interacting with network communication are replaced by only one virtual computer. Even Business Logic code of the virtual computer is same with another Business Logic code running on a single physical computer.

Thus, you can make a network system very easily if you use the TGrid. Forget everything about the network; protocolcs and designing message structures, etc. You only concentrate on the Business Logic, the essence of what you want to make. Remeber that, as long as you use the TGrid, you're just making a single program running on a single (virtual) computer.

1.2. Safe Implementation

By compilation and type checking, you can make network system safe.

When developing a distributed processing system with network communication, one of the most embarrassing thing for developers is the run-time error. Whether network messages are correctly constructed and exactly parsed, all can be detected at the run-time, not the compile-time.

Let's assume a situation; There's a distributed processing system build by traditional method and there's a critical error on the system. Also, the critical error wouldn't be detected until the service starts. How terrible it is? To avoid such terrible situation, should we make a test program validating all of the network messages and all of the related scenarios? If compilation and type checking was supported, everything would be simple and clear.

TGrid provides exact solution about this compilation issue. TGrid has invented Remote Function Call to come true the real Grid Computing. What the Remote Function Call is? Calling functions remotly, isn't it a function call itself? Naturally, the function call is protected by TypeScript Compilter, therefore guarantees the Type Safety.

Thus, with TGrid and Remote Function Call, you can adapt compilation and type checking on the network system. It helps you to develop a network system safely and conveniently. Let's close this chapter with an example of Safey Implementation.

import { WebConnector } from "tgrid/protocols/web/WebConnector"
import { Driver } from "tgrid/components/Driver";

interface ICalculator
{
    plus(x: number, y: number): number;
    minus(x: number, y: number): number;

    multiplies(x: number, y: number): number;
    divides(x: number, y: number): number;
    divides(x: number, y: 0): never;
}

async function main(): Promise<void>
{
    //----
    // CONNECTION
    //----
    let connector: WebConnector = new WebConnector();
    await connector.connect("ws://127.0.0.1:10101");

    //----
    // CALL REMOTE FUNCTIONS
    //----
    // GET DRIVER
    let calc: Driver<ICalculator> = connector.getDriver<ICalculator>();

    // CALL FUNCTIONS REMOTELY
    console.log("1 + 6 =", await calc.plus(1, 6));
    console.log("7 * 2 =", await calc.multiplies(7, 2));

    // WOULD BE COMPILE ERRORS
    console.log("1 ? 3", await calc.pliuowjhof(1, 3));
    console.log("1 - 'second'", await calc.minus(1, "second"));
    console.log("4 / 0", await calc.divides(4, 0));
}
main();

$ tsc
src/index.ts:33:37 - error TS2339: Property 'pliuowjhof' does not exist on type 'Driver<ICalculator>'.

    console.log("1 ? 3", await calc.pliuowjhof(1, 3));

src/index.ts:34:53 - error TS2345: Argument of type '"second"' is not assignable to parameter of type 'number'.

    console.log("1 - 'second'", await calc.minus(1, "second"));

src/index.ts:35:32 - error TS2349: Cannot invoke an expression whose type lacks a call signature. Type 'never' has no compatible call signatures.

    console.log("4 / 0", await calc.divides(4, 0));

1.3. Network Refactoring

Critical changes on network systems can be resolved flexibly.

In most case of developing network distributed processing system, there can be an issue that, necessary to major change on the network system. In someday, neccessary to refactoring in network level would be come, like software refactoring.

The most representative of that is the performance issue. For an example, there is a task and you estimated that the task can be done by one computer. However, when you actually started the service, the computation was so large that one computer was not enough. Thus, you should distribute the task to multiple computers. On contrary, you prepared multiple computers for a task. However, when you actually started the service, the computation was so small that just one computer is sufficient for the task. Sometimes, assigning a computer is even excessive, so you might need to merge the task into another computer.

Composite Calculator	Hierarchical Calculator

I'll explain this Network Refactoring, caused by performance issue, through an example case that is very simple and clear. In a distributed processing system, there was a computer that providing a calculator. However, when this system was actually started, amount of the computations was so enormous that the single computer couldn't afford the computations. Thus, decided to separate the computer to three computers.

• scientific: scientific calculator server
• statistics: statistics calculator server
• calculator: mainframe server
  • four arithmetic operations are computed by itself
  • scientific and statistics operations are shifted to another computers
  • and intermediates the computation results to client

If you solve this Network Refactoring by traditional method, it would be a hardcore duty. At first, you've to design a message protocol used for neetwork communication between those three computers. At next, you would write parsers for the designed network messges and reprocess the events according to the newly defined network architecture. Finally, you've to also prepare the verifications for those developments.

Things to be changed

• Network Architecture
• Message Protocol
• Event Handling
• Business Logic Code

However, if you use the TGrid and Remote Function Call, the issue can't be a problem. In the TGrid, each computer in the network system is just one object. Whether you implement the remote calculator in one computer or distribute operations to three computers, its Business Logic code must be the same, in always.

I also provide you the best example for this performance issue causing the Network Refactoring. The first demonstration code is an implementation of a single calculator server and the second demonstration code is an implementation of a system distributing operations to three servers. As you can see, although principle structure of network system has been changed, you don't need to worry about it if you're using the TGrid and Remote Function Call.

• Demonstration - Remote Object Call
• Demonstration - Object Oriented Network

2. Weaknesses

2.1. High Traffic

University in network system means the overhead, increase of traffic.

But ignore the traffic. It's vulnerable in nowadays.

TGrid has invented Remote Function Call to come true the Grid Computing, so we are enjoyings the 1. Strengths. However, if there is light, there also be the darkness. To accomplish the Remote Function Call, the data structure used by Communicator is JSON-string, who has not only high university but also high traffic.

export type Invoke = IFunction | IReturn;

export interface IFunction
{
    uid: number;
    listener: string;
    parameters: IParamter[];
}
export interface IParameter
{
    type: string;
    value: any;
}

export interface IReturn
{
    uid: number;
    success: boolean;
    value: any;
}

The most standard way to reduce data transfer in network communication is to design special data structure and use it. By designing and applying optimal and special binary structures for each feature who uses network communication, it's possible to reduce amount of data transmission dramatically. In the example below, the binary structure uses 28 bytes per a record, and general data (JSON-string) uses about 100 to 200 bytes.

struct candle
{
    long long date;
    unsigned int open;
    unsigned int close;
    unsigned int high;
    unsigned int low;
    unsigned int volume;
};

struct candle
{
    long long date;
    unsigned int open;
    unsigned int close;
    unsigned int high;
    unsigned int low;
    unsigned int volume;
};

{
    "date": "2019-01-05",
    "open": 300000,
    "close": 350000,
    "high": 370000,
    "close": 290000,
    "volume": 795041
}

However, I think so. Traffic means nothing in nowadays.

Today's network communication technology has evolved from day to day, with the ability to transfer data in GB per a second. Design and utilize special binary structures for every features to reduce amount of data transmission... Well, I don't know if it was the past who can send data only KB per a second, should we do such vulnerable optimizations in nowadays?

If me, I would just endure the traffic problem and enjoy the 1. Strengths.

2.2. Low Performance

TGrid based on script language and it makes performance to be low.

But I've prepared the alternative solutions

• Nonetheless, 1. Strengths are stronger.
• Infrastructure costs can be resolved by 3.2. Public Grid.
• Low performance can be resolved by partial optimization.
• Even if you should migrate to native language later, develop with TGrid first to make it faster and safer.

2.2.1. Script Language

The full name of Tgrid is the TypeScript Grid Computing Framework, which is based on the TypeScript. And compilation result of the TypeScript is the JavaScript file, which is obviously a script language. Also, all of the programmers may know that, script language is slower than native language. Thus, Grid Computing system made with TGrid is slower than that made with native.

So we should consider something when creating the Grid Computing system, whether 1. Strengths of the TGrid can offset the disadvantage Low Performance caused by the script language.

Of course, if there's not the performance issue in your network system, or if you are tending to implement the Grid Computing system not to distribute great operations but only by business logic like blockchain, you don't need to worry anything. Just close your eyes and select the TGrid and Remote Function Call.

2.2.2. Partial Optimization

On the other hand, I never have given up the Low Performance issue without any alternative solution. The increasing infrastructure costs by Low Performance can be resolved by the 3.2. Public Grid. I'll benchmark it laster, but in my suggestion, the costs may not only be just resolved but also be decreased dramatically.

Also, there is another way to solve the Low Performance issue. Performance tuning starts from where the expected improvement is greatest. You don't have write all the program codes in C++. Write most of the program codes in TypeScript and implement with native language somewhere operations are concentrated (In NodeJS, interact with C++ directly and in Web Borwser, use Web Assembly).

2.2.3. Full Migration

Although you want to make the entire Grid Computing system in C++. I still recommend you to use the TGrid and TSTL. I'm not saying you "The Low Performance issue is nothing when comparing with 1. Strengths. Even the Low Performance issue can be resolved by 2.2.2. Partial Optimization, so ignore the issue".

Desining and implementing a Grid Computing system, with native language like C++, from the beginning is extremely difficult. Not only it is difficult to develop, but it is also impossible to guarantee stability and the development terms would be infinitely long. If what you're trying to make is for distributing extra-large computations, the difficulty level of development would uprise even rather than the Blockchain System, Steps to the Hell.

So I recommend you. First, develop quickly and safely through the TGrid and Remote Function Call. At next, proceed your service quickly with focusing on the Business Logic. After confirming that the service is running stable, go ahead and proceed with the Full Migration. As there already has been the stable system, you just need to migrate them to C++ considering syntax.

In my experience, when developing a Grid Computing system in a native language, it was much efficient to using the migration strategy I've mentioned. The development terms was much shorter and system was much safer.

Meanwhile, it's also possible to build a Grid Computing system with TGrid first and understand something later; the Full Migration was not required at all, no performance issue or the issue can resolved by 2.2.2. Partial Optimization. In such case, should we sigh and say "We were so lucky"?

2.3. Low Background

TGrid is a young project, so its background is shallow.

I'll try my best to overcome it. Please support me a lot.

TGRid is a new framework just created. So no matter how plausible and roundbreaking the Remote Function Call is, number of projects using the TGrid is extremely small. Except for demo projects of tutorial or commercial projects that I've made, the number would be much smaller. Thus, there are not enough commnities that can share informations and knowhows about the TGrid.

The blockchain project as an example, how can the blockchain can be easily developed by the TGrid, but havent't most of the blockchain projects been developed by the traditional method? It's hard to determine whether blockchain development using the Remote Function Call is easier than referencing legacy projects built by traditional method or not.

But if you are building a blockchain project with a new kin of business logic, I condidently recommend you that TGrid is much easier.

It's the well known truth that TGrid is a new borned project and it has shallow background in today. I feel sad but there's no amazing way resolve the problem. The only way to reolsve it is to keep trying best for a long time. I believe that the Remote Function Call would soon be the new trend of network system development. I believe that this is the future and would keep the development, so please help me a lot.

In someday, TGrid will become famous. Maybe it doesn't take long.

3. Opportunities

3.1. Blockchain

Detailed Content: Appendix > Blockchain

With TGrid, you can develop Blockchain easily.

It's a famous story that difficulty of developing blockchain is very high. Not only because of the high wages of the blockchain developers, but also from a technical point of view, blockchain is actually very difficult to implement. But, if you ask me what is such difficult, I will answer that not Business Logic but Network System*.

The Network System used by blockchain is a type of great distributed processing system, conostructed by millions of computers interacting with network communication. The great distributed processing systems like the blockchain always present us the tremendous difficulties. The word 'perfect' is inserted on every development processes; requirements must be analyzed perfectly, use-cases must be identified perfectly, data and network architectures must be designed, perfectly and mutual interaction test must be perfectly.

On contrary, Business Logic of the blockchain is not such difficult. Core elements of the blockchain are, as the name suggest, the first is 'Block' and the second is 'Chain'. The 'Block' is about defining and storing data and the 'Chain' is about policy that how to reach to an agreement when writing data to the 'Block'.

Let's assume that you are developing the 'Block' and 'Chain' as a program running only on a single computer. In this case, you just need to design the data structure and implement code storing the data on disk. Also, you would analyze the requirements (policy) and implement them. Those skills are just the essentials for programmers. In other word, Business Logic of blockchain is something that any skilled programmers can implement.

• To develop the Block and Chain:
  • Ability to design Data Structure
  • Ability to store Data on Device
  • Ability to analyze policy (requirements)
  • Ability to implement them

Do you remember? With TGrid and Remote Function Call, you can come true the true Grid Computing. Many computers interacting with network communication are replaced by only one virtual computer. Even Business Logic code of the virtual computer is same with another Business Logic code running on a single physical computer.

Thus, if you adapt the TGrid and Remote Function Call, difficulty of the blockchain development would be dropped to the level of Business Logic. Forget complex Network System and just focus on the essence of what you want to develop; the [Business Logic](blockchain.md.

3.2. Public Grid

Related Project: Tutorial > Projects > Grid Market

With TGrid, you can procure resources for Grid Computing from unspecified crowds, very easily and inexpensively.

When composing traditional Grid Computing, of course, many computers should be prepared. As the number of computers required increases, so does the infrastructure and costs associated with procuring them. Also, you've to install programs and configure settings for the network communication on the prepared computers. Such duties increase your efforts and let you to be tired. Is it so nature?

However, TGrid even can economize such costs and efforts dramatically. You can procure resources for Grid Computing from the unspecified crowds. Those unspecified crowds do not need to prepare anything like installing some program or configuring some setting. The only need those unspecified crowds is just connecting to special URL by Internet Browser.

The program that each Supplier should run is provided by the Consumer as JavaScript code. Each Supplier would act its role by the JavaScript code. Of course, interactions with Supplier and Consumer (or with a third-party computer) would use the Remote Function Call, so they are just one virtual computer.

Base language of the TGrid is TypeScript and compilation result of the TypeScript is the JavaScript file. As JavaScript is a type of script language, it can be executed dinamiccaly. Therefore, the Supplier can execute the program by script code delivered by the Consumer.

Grid Market is one of the most typical example case for the Public Grid, a demo project for tutorial learning. In this demo project, Consumer also procures resources from the Suppliers for composing the Grid Computing system. Supplier also provides its resources just by connecting to the special URL by Internet Browser, too. Of course, in the Grid Market, the program that Supplier would run still comes from the Consumer.

However, there's a special thing about the Grid Market, it is that there is a cost for the Consumer to procure the Suppliers' resources. Also, intermediary Market exists and it charges fee for mediation between the Consumer and Supplier.

• Market: Intermediary market for the Suppliers and Consumers.
• Consumer: Purchase resources from the *Suppliers.
• Supplier: Sells its own resources to the Consumer.

3.3. Market Expansions

The Grid Computing market would be grown up day by day.

The future belongs to those who prepare. Prepare the future by TGrid and Remote Function Call. Also, I hope you to hold some changes from the future.

4. Threats

What can threat the TGrid Remote Function Call? Writing the Swot Analysis, I don't have any idea yet. If you have any idea, please inform me.

• https://github.com/samchon/tgrid/issues