Vely makes it possible to leverage the power of C in your web applications.
[Vely][1] combines high performance and the low footprint of C with the ease of use and improved safety of languages like PHP. It's free and open source software, licensed under GPLv3 and LGPL 3 for libraries, so you can even build commercial software with it.
### Using Vely for SaaS
You can use Vely to create a multitenant web application that you can run on the Internet as Software-as-a-Service (SaaS). Each user has a completely separate data space from any other.
In this example web application, a user can sign up for a notebook service to create notes and then view and delete them. It demonstrates several technology integrations in just 310 lines of code across seven source files. The technologies include:
- MariaDB
- Web browser
- Apache
- Unix sockets
#### How it works
Here's how the application works from a user's perspective. A code walk-through follows the images.
The app allows a user to create a new login by specifying an email address and password. You can style these any way you like, such as with CSS:
![Create a user account][2]
Verify the user's email:
![Verify the user's email address][3]
Each user logs in with their unique username and password:
![The user logs in][4]
Once logged in, a user can add a note:
![The user can add a note][5]
A user can get a list of notes:
![User lists notes][6]
The app asks for confirmation before deleting a note:
![The app asks for confirmation before deleting a note][7]
After the user confirms, the note is deleted:
![After confirmation, the note is deleted][8]
#### Setup prerequisites
Follow the installation instructions on [Vely.dev][9]. It's a quick process that uses standard packaging tools, such as DNF, APT, Pacman, or Zypper.
Because they are part of this example, you must install Apache as a web server and MariaDB as a database.
After installing Vely, turn on syntax highlighting in Vim if you're using it:
```
vv -m
```
#### Get the source code
The source code for this demonstration SaaS app is part of the Vely installation. It's a good idea to create a separate source code directory for each application (and you can name it whatever you like). In this case, unpacking the source code does that for you:
```
$ tar xvf $(vv -o)/examples/multitenant_SaaS.tar.gz
$ cd multitenant_SaaS
```
By default, the application is named `multitenant_SaaS`, but you can call it anything (if you do that, change it everywhere).
### Set up the application
The very first step is to create an application. It's simple to do with Vely's `vf` utility:
```
$ sudo vf -i-u $(whoami) multitenant_SaaS
```
This command creates a new application home (`/var/lib/vv/multitenant_SaaS`) and performs the application setup for you. Mostly, that means creating various subdirectories in the home folder and assigning privileges. In this case, only the current user (the result of `whoami`) owns the directories, with 0700 privileges, which ensures that no one else has access to the files.
### Set up the database
Before doing any coding, you need a place to store the information used by the application. First, create a MariaDB database called `db_multitenant_SaaS`, owned by the user `vely` with password `your_password`. You can change any of these values, but remember to change them everywhere during this example.
Then create database objects (tables and records and so on) in the database:
```
USE db_multitenant_SaaS;
SOURCE setup.sql;
exit
```
### Connect Vely to a database
To let Vely know where your database is and how to log into it, create a database config file named `db_multitenant_SaaS`. (This is the name used by the database statements in the source code, so if you change it, make sure you change it everywhere.)
Vely uses native MariaDB database connectivity, so you can specify any options that a given database lets you:
```
$ echo'[client]
user=vely
password=your_password
database=db_multitenant_SaaS
protocol=TCP
host=127.0.0.1
port=3306'> db_multitenant_SaaS
```
### Build the application
Use the `vv` utility to make the application, using the `--db` option to specify the MariaDB database and the database config file:
```
$ vv -q--db=mariadb:db_multitenant_SaaS
```
### Start the application server
To start the application server for your web application, use the `vf` FastCGI process manager. The application server uses a Unix socket to communicate with the web server (creating a reverse proxy):
```
$ vf -w3 multitenant_SaaS
```
This starts three daemon processes to serve the incoming requests. You can also start an adaptive server that increases the number of processes to serve more requests and gradually reduce the number of processes when they're not needed:
```
$ vf multitenant_SaaS
```
See `vf` for more options to help you achieve the best performance.
When you need to stop your application server, use the `-m quit` option:
```
$ vf -m quit multitenant_SaaS
```
### Set up the web server
This is a web application, so the application needs a web server. This example uses Apache by way of a Unix socket listener.
#### 1. Set up Apache
To configure Apache as a reverse proxy and connect your application to it, you need to enable FastCGI proxy support, which generally means using the `proxy` and `proxy_fcgi` modules.
For Fedora systems (or others, like Arch) enable the `proxy` and `proxy_fcgi` modules by adding (or uncommenting) the appropriate **LoadModule** directives in the `/etc/httpd/conf/httpd.conf` Apache configuration file.
For Debian, Ubuntu, and similar systems, enable the `proxy` and `proxy_fcgi` modules:
```
$ sudo a2enmod proxy
$ sudo a2enmod proxy_fcgi
```
For OpenSUSE, add these lines to the end of `/etc/apache2/httpd.conf`:
Finally, restart Apache. On Fedora and similar systems, as well as Arch Linux:
```
$ sudo systemctl restart httpd
```
On Debian and Debian-based systems, as well as OpenSUSE:
```
$ sudo systemctl restart apache2
```
### Set up local mail
This example uses email as a part of its function. If your server can already send email, you can skip this. Otherwise, you can use local mail (`myuser@localhost`) just to test it out. To do that, install Sendmail.
On Fedora and similar:
```
$ sudo dnf installsendmail
$ sudo systemctl start sendmail
```
On Debian systems (like Ubuntu):
```
$ sudo apt installsendmail
$ sudo systemctl start sendmail
```
When the application sends an email to a local user, such as `OS_user@localhost`, then you can verify that the email was sent by looking at `/var/mail/` (the "mail spool").
### Access the application server from the browser
Assuming you're running the application locally, use `http://127.0.0.1/multitenant_SaaS?req=notes&action=begin` to access your application server from your web browser. If you're running this on a live server on the Internet, you may need to adjust your firewall settings to allow HTTP traffic.
### Source code
This example application contains seven source files. You can review the code yourself (remember, it's just 310 lines across these files), but here's an overview of each one.
#### SQL setup (setup.sql)
The two tables created are:
- **users**: Information about each user. Each user in the **users** table has its own unique ID (**userId** column) along with other information such as email address and whether it's verified. There's also a hashed password. An actual password is never stored in plain text (or otherwise); a one-way hash is used to check the password.
- **notes**: Notes entered by the user. The **notes** table contains the notes, each along with **userId** column that states which user owns them. The **userId** column's value matches the namesake column from **users** table. This way, every note clearly belongs to a single user.
CREATEUNIQUEINDEXIFNOTEXISTS users1 ON users (email);
```
#### Run-time data (login.h)
To properly display the Login, Sign Up, and Logout links, you need some flags that are available anywhere in the application. Also, the application uses cookies to maintain a session, so this needs to be available anywhere, for example, to verify that the session is valid. Every request sent to the application is confirmed that way. Only requests that come with verifiable cookies are permitted.
So to that effect, you have a **global_request_data** type `reqdata` (request data) and in it there's `sess_userId` (ID of user) and `sess_id` (user's current session ID). You also have rather self-explanatory flags that help render pages:
```
#ifndef _VV_LOGIN
#define _VV_LOGIN
typedef struct s_reqdata {
bool displayed_logout; // true if Logout link displayed
bool is_logged_in; // true if session verified logged-in
char *sess_userId; // user ID of current session
char *sess_id; // session ID
} reqdata;
void login_or_signup ();
#endif
```
#### Session checking and session data (_before.vely)
Vely has a notion of a **before_request_handler**. The code you write executes before any other code that handles a request. To do this, all you need is to write this code in a file named `_before.vely`, and the rest is automatically handled.
Anything that a SaaS application does, such as handling requests sent to an application, must be validated for security. This way, the application knows whether the caller has the permissions needed to perform an action.
Checking for permission is done here in a before-request handler. That way, whatever other code you have handling a request, you already have the session information.
To keep session data (like session ID and user ID) available anywhere in your code, you use **global_request_data**. It's just a generic pointer (**void***) to memory that any code that handles requests can access. This is perfect for handling sessions, as shown below:
```
#include "vely.h"
#include "login.h"
// _before() is a before-request-handler. It always executes before
// any other code that handles a request. It's a good place for any
// kind of request-wide setting or data initialization
void _before() {
// Output HTTP header
out-header default
reqdata *rd; // this is global request data, see login.h
// allocate memory for global request data, will be automatically deallocated
// at the end of request
new-mem rd size sizeof(reqdata)
// initialize flags
rd->displayed_logout = false;
rd->is_logged_in = false;
// set the data we created to be global request data, accessible
// from any code that handles a request
set-req data rd
// check if session exists (based on cookies from the client)
// this executes before any other request-handling code, making it
// easier to just have session information ready
_check_session ();
}
```
#### Checking if the session is valid (_check_session.vely)
One of the most important tasks in a multitenant SaaS application is to check (as soon as possible) if the session is valid by checking whether a user is logged in. It's done by getting the session ID and user ID cookies from the client (such as a web browser) and checking these against the database where sessions are stored:
```
#include "vely.h"
#include "login.h"
// Check if session is valid
void _check_session () {
// Get global request data
reqdata *rd;
get-req data to rd
// Get cookies from user browser
get-cookie rd->sess_userId="sess_userId"
get-cookie rd->sess_id="sess_id"
if (rd->sess_id[0] != 0) {
// Check if session ID is correct for given user ID
char *email;
run-query @db_multitenant_SaaS = "select email from users where userId='%s' and session='%s'" output email : rd->sess_userId, rd->sess_id row-count define rcount
#### Signing up, Logging in, Logging out (login.vely)
The basis of any multitenant system is the ability for a user to sign up, log in, and log out. Typically, signing up involves verifying the email address; more often than not, the same email address is used as a username. That's the case here.
There are several subrequests implemented here that are necessary to perform the functionality:
- When Signing Up a new user, display the HTML form to collect the information. The URL request signature for this is `req=login&action=newuser`.
- As a response to the Sign Up form, create a new user. The URL request signature is `req=login&action=createuser`. The **input-param** signal obtains an **email** and **pwd** POST form fields. The password value is a one-way hash, and an email verification token is created as a random five-digit number. These are inserted into the **users** table, creating a new user. A verification email is sent, and the user is prompted to read the email and enter the code.
- Verify the email by entering the verification code sent to that email. The URL request signature is `req=login&action=verify`.
- Display a Login form for the user to log in. The URL request signature is `req=login` (for instance, `action` is empty.)
- Log in by verifying the email address (username) and password. The URL request signature is `req=login&action=login`.
- Logout at the user's request. The URL request signature is `req=login&action=logout`.
- Landing page for the application. The URL request signature is `req=login&action=begin`.
- If the user is currently logged in, go to the application's landing page.
With this tutorial, you can create any multitenant SaaS application you want. The multitenant-processing module above (`login.vely`) calls the **_show_home()** function, which can house any code of yours. This example code shows the Notes application, but it could be anything. The **_show_home()** function calls any code you wish and is a general-purpose multitenant application plug-in:
```
#include "vely.h"
void _show_home() {
notes();
exit-request
}
```
#### Notes application (notes.vely)
The application is able to add, list, and delete any given note:
```
#include "vely.h"
#include "login.h"
// Notes application in a multitenant Cloud
void notes () {
// get global request data
reqdata *rd;
get-req data to rd
// If session invalid, display Login or Signup
if (!rd->is_logged_in) {
login_or_signup();
}
// Greet the user
@<h1>Welcome to Notes!</h1><hr/>
// If not logged in, exit - this ensures security verification of user's identity
if (!rd->is_logged_in) {
exit-request
}
// Get URL parameter that tells Notes what to do
input-param subreq
// Display actions that Notes can do (add or list notes)
@Are you sure you want to delete a note? Use Back button to go back, or <ahref="https://opensource.com/?req=notes&subreq=delete_note¬e_id=%3C%3Cp-out%20note_id%3E%3E">delete note now</a>.
}
// Delete a note
else if (!strcmp (subreq, "delete_note")) {
input-param note_id
// Delete note
run-query @db_multitenant_SaaS = "delete from notes where noteId='%s' and userId='%s'" : note_id, rd->sess_userId affected-rows define arows no-loop error define errnote
Vely makes it possible to leverage the power of C in your web applications. A multitenant SaaS application is a prime example of a use case that benefits from that. Take a look at the code examples, write some code, and give Vely a try.
