# Campus visit system architecture

## Technology selection

### Client side: Vue, HTML, CSS, TypeScript

The client-side application is envisioned as a single-page web app, which will run in Vue 3.  The two main alternatives (Angular and React) were ruled out because of lack of developer familiarity with these.  The complexity of this application rules out JQuery; it will take much less code to develop in Vue.

According to some cursory research, TypeScsript is much better suited over JavaScript when developing in Vue 3, and should only take a few hours to learn, given familiarity with JavaScript.  Of course, HTML and CSS go with the territory.

### Server side: Node.js, Express, SQLite

Speed and developer familiarity were the main rationale for selecting Node.js and Express.  Website files and AJAX requests can both be handled fine with these technologies.

For a database engine, SQLite was compared with MySQL, as both are free.  According to the SQLite documentation, it should be able to handle upwards of 100,000 hits per day for a web application.  The main speed limitation in SQLite is with write transactions (especially concurrent ones), but given the small number of users (no more than a dozen) and infrequent requests (estimated at less than 100 per day), SQLite would be well within performance bounds and will probably outperform MySQL due to its simpler structure.  It is also expected to be simpler to configure and deploy.  Thus, SQLite was chosen over MySQL.

#### Backups

SQLite works based on a single database file and it has built-in functionality for making a backup, so it will be straightforward to schedule automatic backups.  For simplicity of deployment, the plan is to implement this in the Node.js server script itself.

### Client-server data communication: JSON over AJAX

JSON will be used for client-server data communication (e.g. visit and user data).  It is standard and integrates easily between Node/Express and client-side JavaScript.  AJAX is choosen as a default over WebSockets because server pushes are not strictly necessary.  For example, although it would be nice for a faculty committment to appear immediately on the coordinator's screen, it may not be worth the extra development time and email already serves this purpose.

## Feasibility

## File formats

## Major database tables

There will only need to be 3 main database tables: Users, Visits, and Committments.  These tables will implement the internal model supposed in the user interface document.  There will also be a table for storing configuration data; see https://stackoverflow.com/questions/2300356/using-a-single-row-configuration-table-in-sql-server-database-bad-idea for a discussion of two possible implementations of the configuration table.

## Performance

## Scalability

## Internationalization

## Security

## Error processing

## Fault tolerance