Questions about v4 of the framework.
Closed this issue · 12 comments
Note. In order not to generate many tickets, here I will write all the questions that arise about the engine, open and close as needed.
1. The old version has a GLOBAL (or G for short) property that returns an object. It was very convenient to set global variables or functions in definitions, which are often used in different places in the project, precisely because of the shorthand. For example:
G.regexLogin = /^.*[a-zа-я]+.*$/gmi;
For some reason, the new version does not have it. Is it possible to return this property?
2. The documentation says the following about threads:
threads are using unix socket (they don't work on Windows)
Surely there are advantages to using this protocol. But I don't understand what the problem is in implementing something similar for Windows?
Nodejs has a nice off-the-shelf cross-platform solution for this:
https://nodejs.org/api/worker_threads.html
In my commercial project (parser of text files), this module works great on Windows - when using it, the file processing time is reduced by almost 10 times.
Due to the nature of my activity, I have to use Windows to launch my projects. And I think that there are many like me. Moreover, with such a restriction, you cut off some of the potential users of your excellent engine, which means that the popularity / commercial potential will also suffer because of this.
Considering that the minimum requirements of the v4 specify exactly the 14th version of nodejs, then there should be no problems with the implementation. Yes, it is possible that not all the advantages of the unix socket will be implemented, but it is still better than nothing.
I am even ready to help in the implementation of this mechanism, if you find it difficult to allocate time for this.
Hi,
- The old version has a GLOBAL (or G for short) property that returns an object. It was very convenient to set global variables or functions in definitions, which are often used in different places in the project, precisely because of the shorthand.
Total.js 4 contains global helper variables too:
REPOMAINFUNCDEF(it contains some internal settings)
So you can easily use each one.
Surely there are advantages to using this protocol. But I don't understand what the problem is in implementing something similar for Windows?
I don't think so that you can provide threads via worker_threads. That's a bit complicated because the main thread is that a proxy server and child processes use a clustered http server (I can't send a raw request to a worker, that's not possible). Yes, threads can be provided without a unix socket, but there is a problem with IP and PORT association. So threads can work without a unix socket, but I need to modify them.
-
Thank you. This issue has been resolved.
-
Perhaps I do not fully understand the meaning and function of threads in Total.js. Are you talking about proxy and IP and port associations - that is, it is essentially an analogue of NGINX, only completely written in node.js?
If the answer is yes, then I agree with you. I faced this myself when setting up several projects on one IP Windows.
Although it seems to me that with the development of threads in node.js, this issue will be resolved in the future. It may already be solved, but it requires a lot of work and testing.
Then it seems to me that the help can indicate that for Windows the only alternative at the moment is NGINX. This will be useful, especially for beginners who are faced with a similar problem, as I once faced. I can drop my settings as an example for reference. -
Where has the SOURCE method gone? I have a lot of logic written in it, but in the fourth version it is not at all. And I have to rewrite a lot of code. The method was very convenient.
Can I get it back? or is there a similar alternative?
Are you talking about proxy and IP and port associations - that is, it is essentially an analogue of NGINX, only completely written in node.js?
Not quite. App with the threads need a reverse proxy too, but the app contains another reverse proxy to threads, and threads are independent clustered apps. Therefore Total.js uses a unix socket due to performance and minimal configuration for communication. I don't recommend to use Windows for providing of Total.js apps, but most of app wills work.
SOURCE()method exists in Total.js 4, but it's hidden from docs because I don't want developers to use it. I recommend dividing the code into schemas.
2. So my first understanding was partly correct.
independent clustered apps
do I understand correctly that these are essentially separate processes? That is, the meaning of a unix socket is to assign an ip and a port to the process, judging by your code from the screen?
https://i.vgy.me/brpap0.png
If so, then in threads this problem is solvable. Including the reverse interaction between threads and the parent thread is already in fact embedded in the module, although it is not obvious. Here are some examples here or here.
The bottom line is that threads in a node.js are not separate processes, but just separate sections of memory. And that's why their control and interaction is so much easier. It is easy for threads to transfer any data, as it is easy to get back from them.
The idea is that the ip and port can be simply passed to the thread as data. Next, you can write a function for checking compliance with the port and ip. Since a stream can return any data, validation shouldn't be difficult either. In an OS with unix support, you can leave unix sockets, for all other OS you can use threads.
I understand the dislike of developers for Windows, but there are those who are forced to use it or those who are more comfortable with it than Unix systems. And the main idea of Total.js - is not to have dependencies, but now the framework turns out (albeit partially) depends on the OS.
3. You are right. The SOURCE method is indeed in the system. But it doesn't work:
https://i.vgy.me/PirGDI.png
There is no error when switching to the v3. That is, the problem is in v4.
do I understand correctly that these are essentially separate processes? That is, the meaning of a unix socket is to assign an ip and a port to the process, judging by your code from the screen?
Exactly. I don't think so that Node.js Worker can handle requests. Therefore I used a unix socket. I don't want to dislike any developers, but some cases are complicated to optimize. I wrote you yesterday, then I can provide these threads on Windows, but I must find a logical way for IP:PORT. I'm open for it, and I fully agree with you.
You are right. The SOURCE method is indeed in the system. But it doesn't work:
Sorry, my mistake. I have fixed that problem. Please update your Total.js 4 from NPM. npm install total4 --> version total4@0.0.27
BTW: I need a little bit of time for implementing threads in Windows. Maybe I'll look into it next month.
BTW: I need a little bit of time for implementing threads in Windows. Maybe I'll look into it next month.
2. Thank you very much for your understanding and answers.
I am glad that you are ready to take the time to this issue. But since the percentage of those using Windows is not high, I dare not rush you, and I am ready to wait as long as necessary.
Moreover, I am ready to take the time and share my thoughts on this matter. And to get confused, I propose to open a new question on this topic. There I will share my ideas in the form of code in the coming weeks (as time permits). But since I poorly understand the insides of Total.js, you will need answers, comments and criticism. I am also ready to comment on your vision.
3. Thanks for the promptness. Everything is working.
Since now schemes and routes have become more universal (especially with regard to websockets), over time I will completely switch to using schemes. This is indeed the more correct approach.
4. In the v3, there was a promise method in database queries. It was really easy to use, especially to avoid the callback tree in large project functions.
In the v4 this doesn't work: https://i.vgy.me/zfvQSK.png
Can it be returned? or what is the alternative? I have many implementations with this method and would not like to use callbacks. This is terribly inconvenient.
-
Yes, good approach. Schemas are very powerful and cleaner. You can build them with help of AppBuilder: www.totaljs.com/appbuilder
-
I have returned it, can you test it?
$ npm install total4@betaWe don't use promises.
3. My colleague and I have already checked it out - cool stuff!
4. Yes. Everything seems to work. Thank you for efficiency!
But I still wonder why you don't use promises?
Async/await is a modern syntax and approach to programming, at least eliminates one big problem - the callback tree.
In my project, this is exactly the solution to the problem in the methods of generating large reports, where the sequence of calling some data from the database is needed. And the readability of the code is greatly simplified.
What approach are you using?
Async/await is a modern syntax and approach to programming, at least eliminates one big problem - the callback tree.
I agree, but really we don't need it now. For example, reading of some DB in the schemas/controllers:
// $ can be Schema/Operation/Task or Controller
NOSQL('users').list().callback($.callback);or
// $ can be Schema/Operation/Task or Controller
NOSQL('users').one().id($.id).error(404).callback($.callback);or our DBMS module:
var builder = DBMS().find('tbl_product');
builder.fields('id,name,price,dtcreated');
builder.take(10);
builder.sort('dtcreated');
builder.callback($.callback);or advanced usage:
var db = DBMS();
db.modify('tbl_user', model).id($.id);
db.error(404);
db.read('tbl_user').id($.id);
db.callback($.done(true));I'm closing issue.