1. APAAS, a "runtime" system that can be deployed externally:
(The vast majority are in this category, including the mendix ones.)
Most of the modules have been formed and done, a bit like a collection of SaaS (the difference is that it can be deployed externally), with its own user and permission management modules; It provides an interface for external programs to call, and cannot generate (can be exported and deployed) its own ability to design modules (specific models), which is often called "model-driven", and solves the problem of rapid development of "in-domain applications".
2. Generative system:
(It seems that there are only two, IVX and CodeW**E).
It has its own "in-house programming language" and has done the generation and conversion between languages, and has done editors, interpreters, converters, etc. to complete this step.
"Graphical Programming" - the internal programming language "- the high-level language JS j**a".
This kind of platform already has the attributes of a programming language, and the completeness of its functions will be better. If the component design is flexible and the IDE is fully integrated, it can bring a significant improvement in programming efficiency and can support the development of almost all scenarios and systems.
3. APAAS, "runtime" but not externally deployed:
There are also some such systems, which feel no different from SaaS, may be richer in use scenarios, and support multi-tenant management. Of course, the more mature and fixed the system, the less flexible it is, but it is often easier and simpler to use the features that have already been developed.
One of the sinkholes: it is impossible to achieve "zero background knowledge", and ** background is also required
In fact, this is also the name of "low", and it is also the core of the "low" paradoxThe background knowledge required is actually the same as that of programmers who use high-level languages today, and even the ability requirements are not lower。The biggest obstacle to this comes from the "new entrants", that is, new developers, because the learning cycle is almost the same as the existing programmers, and even have to learn a low-level platform framework, so that the "learning cost" is too high, and its own benefits are limited (if it only accelerates the development efficiency of the system in some scenarios), so it is not opened well by new developers. This means that there is no "source of life", so it is difficult to say that this kind of APAAS platform has a good prospect.
Tiankeng 2: There is no unified standard in the industry, and it cannot be exported**, which means that the platform is locked
As mentioned earlier, there is little benefit to developers from this type of platform. Next, I personally think that for the "enterprise" of Apaas users, it will also "do more harm than good".
First of all, the low-level Apaas platform is different from the traditional SaaS platform, and the low-level Apaas requires continuous R&D investment, while the SaaS is "used up and gone", which is really not good, and you can also take the SaaS-related data down and then pack it away.
Apaas does not have an actual industry standard (and it is impossible), and it cannot be exported, so all the R&D precipitation is locked into the platform. The *** feeling here is as important as the SaaS application can ** data, which is a minimum requirement.
In addition, because it cannot be exported, the previous "R&D management form", "mature product launch process" and "management" may have to be adjusted, which is actually a very costly process.
Just digging a pit and not burying it is to add trouble to everyone! So, it's not that there is no solution, and it's relatively mature.
In fact, the second type mentioned above is a good solution, strictly speaking, this product is not considered "low**" more like a graphical programming language, but it doesn't matter, it's called so in China).
Recommend two products: IVX and NetEase's CodeW**e, which are the "most generic" platforms available in China. I won't evaluate which one is good, everyone can try it, but I can list some evaluation criteria that I think are reasonable, and you can experience it for yourself.
First, the generation ability of **:
1) Completeness:
There are as few sub-tools as possible, so that all ** can be generated; Otherwise, there is ** inside the tool, and the ** of the tool itself must not be put in, which means that the integrity of the generation system will be greatly affected; Is it possible to compile and run it separately?
2) Generate ** language:
It is best to use the ones that are common to everyone, such as front-end js, back-end j**a, and it would be better if it can also be supported, such as python and node, etc.;
3) Readability:
This is actually very important, otherwise if there is any unexpected situation, it still cannot be modified; The following is a screenshot of the background j**a** automatically generated by a low** platform (it is still relatively clear, each service is individually encapsulated, and there are detailed notes).
2. IDE integration capabilities:
To put it simply:
One-stop management! (All the R&D process is best installed in the IDE, no need to jump out, everything is done).
Fewer clicks! (For example, it is better not to have drawing, drawing is actually a very inefficient type of operation, with low information capacity and slow operation).
Fewer windows! (These are the costs).
Large information capacity! (It is best to have a larger information capacity and less white space in the area of generation and expression ** such as logical expression).
Definite control! (For example, it is better to control the logic in one place, and it is not good to control the logic in multiple places, which is easy to mess up and make mistakes).
3. Actual development efficiency
How long do I have to wait for a preview?
How long does it take to compile?
How long does debug take? How efficient is commissioning?
Fourth, operational efficiency
This is a core parameter, but I think that for general systems, in fact, this parameter is not so sensitive, not to have a difference of several times or more, a few milliseconds or less than 20% of the performance is actually not very sensitive.
There is also a very important point".Whether the decoupling of background runtime resources and generation is implemented”！In fact, the main bottlenecks are in database access and complex calculations, etc., these are the core problems solved by "cloud computing", I think "low" or "graphical programming language" does not need to solve these problems again (and can't be done), it is enough to use cloud computing to solve these problems. Therefore, I advocate the decoupling of "** and runtime resources", which has low cost and good effect, but it cannot meet the needs of background R&D personnel to "show off their skills".
Low ** itself is just a concept from abroad, the core or to see if it can help you solve the problem?
If you're a beginner? See "Can you learn quickly?" Can you do anything after you learn it? Can you make money? ”
If you're a company owner? See if you can improve efficiency? How much does it cost? What are the risks in the later stage? ”
If you're a programmer? Look at "Build** Quality? Operational efficiency? Readability? ", whether it is the direction of development"...
In addition, we don't have to beat you to death with a stick, the concept is always the concept, and the product is very different! Sometimes "the concept has limitations, and the breakthrough in the product goes far beyond the concept itself"; Sometimes "the concept is very good, but the product is rubbish, which makes everyone misunderstand their own advanced concept".
In short, try more new technologies and products, and jump out of the "fixed thinking and model", you may not find surprises, but at least you will not be abandoned by the times.