JCloud software design
JCloud is written in C++ under Linux POSIX, which is often compatible with other POSIX based OS'. Some core code may also include code for other OS' (Windows, Mac).
The primary target is x64, but all code should also work with ARM64.
Current standard is C++17. This means code must be able to be compile under this standard, not that new functionality in this standard is used.
External libraries may also be written in C.
Historically, there was often a mix of C and C++ code in projects. Include-files therefore typically had file extension .h regardless of C or C++.
The build environment use GNU makefiles. The makefiles are written for threaded compilation (make -j).
An application is usually either a service, a client/tool or a web page.
We do not develop X / GUI applications, only web.
Services
A service often accept requests from users. It may also initiate requests. The file structure is typically
- Makefile - compiles all files in source-folder implicit
- main.c - entrypoint for main() which blocks until service is exiting or fails
- include folder
- source folder
- README of some sort
A service should support shutting down gracefully with TERM signal and then return an exit code of EXIT_SUCCESS.
Any other exit code shall be classified as a failure. Service failures will cause JService to alert the monitoring system and restart the service.
Service bootstrap configuration
Most services use a database to retrieve/store data, which may also include some service configuration.
In order to connect to this database and get other data, the service loads a bootstrap configuration file first using JModule_Config.
These files are plaintext files with "key value"-lines.
A service usually holds an object containing bootstrap configuration and database pools. It is often called Context or RootContext.
Existing J Modules
The following is a list of some of the different core ABI modules that exists
Functionality
| Module name
| Comment
|
DNS client queries
| libjmodule_dns
| Supports async, sync, DNS and DNS-TLS
|
Authentication
| libjmodule_jid
|
|
Monitoring
| libjmodule_loke
| Use it for services only
|
SQL
| libjmodule_sql
| Supports mySQL, postgreSQL and MSSQL |
Bootstrap config
| libjmodule_config
|
|
JNFS
| libjmodule_jnfs
| File storage
|
TLS certificates
| libjmodule_tls
|
|
24SevenOffice
| libjmodule_24sevenoffice
| ERP/CRM system frequently used
|
Mail sending
| libjmodule_sendmail
| Client SMTP connector
|
Statistics
| libjmodule_stats
| Store and retrieve time based statistics
|
|
|
|
TCP based services
Some services listen on TCP/TLS and use a proprietary protocol, often based on text lines. It could also be that this protocol is based on a RFC.
Unless it is a RFC we these days prefer using jhttp/REST unless it is not viable for the service.
There is existing j-code for dealing with TCP/TLS based services, both asynchronous and synchronous.
HTTPS/REST based services
There is a project called jhttp which includes the entire http-stack as a stand-alone application called httpd. It is modular and can load engines which will deal with the actual http-requests.
Several such engines exist and is used depending on the project. There is also an engine for general purpose webserver with php support called webcdn used by webhosting customers.
It is a good idea to use jhttp in new projects for REST-support.
It is also possible to compile jhttp directly into an application, skipping the separate httpd application.
Client tools
Sometimes a service comes with client tools for doing tasks or other type of jobs. Perhaps a cleanup task
The structure of such applications are limited and could contain only the main file.
Web pages
Web pages are based on jhttp and an engine which again typically loads a dynamic HTTP::Page so-object when requested by a client.
These pages come in different sizes and shapes, rest-based and not.