Vely logo what is  |  why  |  install  |  tutorials  |  examples  |  documentation  |  license  |  about
Current release 10.4.36 (Beta). This page last updated on Jul 01 2022

Vely architecture


Architecture overview

A Vely program works as a request-reply processor. It can be either an application server or a command-line program that processes GET and POST HTTP requests.

When it is an application server, it runs as FastCGI (FCGI) server processes that clients access through reverse proxies (typically web servers like Apache or Nginx). Any number of such Vely FCGI processes can run, including a dynamic number determined by the request load (ranging from 0 resident processes to any maximum number specified). Each Vely FCGI process handles one request at a time, and any number of such processes work in parallel, which means code and libraries used do not have to be thread-safe. Vely application layer is separate from the presentation (eg. web server) and data (eg. database) layers. These layers can run on multiple tiers, separated not only functionally, but physically as well (meaning they can run on different real or virtual hardware), improving scalability, reliability and security.

When a Vely application runs in the command_line, a request is handled by a single execution of a compiled program. This option may be suitable for batch jobs, for use in shell scripts, as well as any other situation where it is more useful or convenient to execute a command-line program. Note that a command-line program can double as CGI (Common Gateway Interface) programs as well; this option may be suitable when high performance is not needed, or for other reasons.

A Vely program can access database, internet/network and file system.

Execution flowchart

Before the very first request a Vely program serves, startup code in optional _startup.v executes. Every request must have a "req" input parameter (here, its value is "do_something"). Before handling this request, an optional before-request handler in _before.v executes. Vely's request dispatcher will route the request to a function with the same name (in this case "void do_something()") that must reside in a file with the same name (which is do_something.v). After the code in that file executes, an after-request handler in _after.v executes (optional). This concludes request processing. Note that any .v file name that starts with an underscore is a non-request file, that is, it doesn't process any requests and its code is used in other .v files.

Performance and stability

Vely applications are native executables by design. This approach avoids performance loss associated with other schemes, such as byte-code, interpreters and similar. Consequently, small memory footprint is achieved with minimal code overhead and by using on-demand dynamic libraries whenever possible; less memory consumption and higher performance allow for better scaling in high-demand environments, with cloud applications and IOT (Internet of Things) being an example.

FastCGI server processes generally stay up across any number of requests, increasing response time. The balance between the number of processes and the memory usage during high request loads can be achieved with adaptive feature of vf, Vely's FastCGI process manager. Since Vely processes running in parallel are single-threaded, programming with Vely does not present challenges of thread-based programming and increases run-time stability.

Vely supports use of prepared database queries with true automatic unlimited reuse across any number of requests; database connections are persistent and stay connected for the life of the server process.  

As far as stability, Vely language_constructs are designed for safety, ease of use, encapsulation and to some extent abstraction of tasks required, making it more difficult to write unstable code. memory_handling includes memory tracking and garbage collection, preventing memory leaks which can be fatal to long running processes. Request-processing and process daemon-izing infrastructure is included. Where possible, use Vely construct and infrastructure instead of pure C in order to get the most of stability enhancing benefits.

From source code to server

All Vely code is in .v files, which contain C code with Vely used freely within. To create an executable program, vv utility will preprocess .v files into 100% C code, and link it. Linkage uses various libraries (database, internet etc.), and those are dynamically linked only if needed, keeping the executable the smallest possible. When code changes, Vely FCGI manager (vf) will restart the server (optional).

Vely programs are built in a single command-line step, and ready to use immediately (see vv). Flexible architecture means the exact same source code can run both as a server application (such as web application back-end) and a command-line program.

Read more about how_vely_works.


General ( quality_control   vely_removal   rename_files   vely   vf   vv   how_vely_works   vely_architecture   vely_SELinux   deploying_application  )  SEE ALL (documentation)

Copyright (c) 2017-2022 DaSoftver LLC. Vely is a trademark of Dasoftver LLC. The software and information herein are provided "AS IS" and without any warranties or guarantees of any kind. This web page is licensed under CC-BY-SA-4.0.