Skip to content

Commit

Permalink
Add README.md files
Browse files Browse the repository at this point in the history
  • Loading branch information
juliusstoerrle committed Oct 27, 2024
1 parent 455524d commit 154a7a6
Show file tree
Hide file tree
Showing 2 changed files with 76 additions and 0 deletions.
34 changes: 34 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# Event Pager

This project provides a webservice exposing a webbased GUI and API to dispatch messages to various transport including IntelPage hardware. The project was created to span a text based communication network across events for distribution of critical information to members of large event teams, which can both utilise independently operated services (IntelPage analog pager) and widely availble channels (phone networks, internet). For smaller events the project can run standalone on small hardware, for large events the service can be integrated into sso/user federation and montitoring environments.

## Features (Planned)

- Hirarchical message receiver structure to align with your requirements (groups, roles, people)
- Mutli page web application to serve as a cross platform GUI
- HTTP API to send messages from third systems
- Easily extend with custom transports
- Track message status (send, received, errors)
- Local or OIDC user authentication
- First party support for IntelPage hardware pagers
- Observability through OpenTelemetry instrumentation

### Performance
The project is planned to run without issues for 500 users, of which 100 are sending 10 messages per day on average (1000 incoming messages) to avg. 5 channels (50000 outgoing messages) each.
Efficency depends highly on the efficency of your transports and its important to optimize your recipient structure for higher throughput of incoming messages.

## Repository Structure

The main service is a Symfony PHP project located in the `webservice/` folder. The folder contains a README.md providing more details on the service.
The project root includes global configuration files and Docker Compose files to run the project.

## Contributing

Please check the README.md of each component for details on how to develop. Your contributions in the form of bug reports & triaging, documentation improvements, addition of further transports, bugfixes, test cases or new features are welcome.
We recommend to start your contribution by creating an issue to allow for discussion. Smaller fixes, documentation and new test cases can be contributed through a pull request without a prior issue.

Please consider the licence of this project and the Developer Certificate of Origin (https://maps.app.goo.gl/m4YGS3pn3r6TfrSh7) for your contributions.

## Security

As the project is not production ready, please disclose vulnerabilites through GitHub issues.
42 changes: 42 additions & 0 deletions webservice/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# Event Pager Webservice

A webservice exposing a webbased GUI and API to dispatch messages to various transport including IntelPage hardware.

## Development

To contribute code to this project, please clone or fork the repository. In addition, please activate MFA for your GitHub account and configure code signing.

After cloning the project, you may start the docker compose file in the project root directory to start the service. Please use `docker exec php bash` to enter the docker container. All dependencies should have been installed through composer during the intial build of the container.

To run our test suites, you may execute one of the folloing commands in the `/webservice` folder (`/app` in the container).

Before committing ensure all tests pass, your contribution is covered by new tests if applicable and the following composer scripts executed without an error:

- composer run code:style:check (if error is found run `composer run code:style:fix`)
- composer run code:sa:check

### Information on the project for developers

We consider stability to be more important than new features.

This has two main consequences:
- Code must be tested thoroughly
- Code must be structured to allow for extension with minimal impact to existing behaviour

To build on a great foundation we are utilizing the Symfony framework including Doctrine as ORM and Twig for templating. For testing this project uses PHPUnit. Please check the respective documentations for details on their APIs and inner workings.

The project does deviate from the generic symfony structure of the src/ folder to support a better mdoule/domain based software architecture loosly inspired by hexagonal architecture. This means 3 layers (View, Core, Infrastructure), each with different modules to seperate domains and concerns.

#### Frontend / Web GUI

The frontend is based on TWIG templates (HTML) with AssetMapper and Symfony UX

#### Testing

All tests are inside the tests/ folder, mirroring the structure of the src/ folder. Tests use attributes to assign themselfs to a group, as follows:

- Unit Tests (group: unit) - DTOs, Entities, Services
- Integration Tests (group: integration) - Services
- Application Tests (group: application) - e.g. Controllers, Commands
- End-to-End Tests (group: webgui) - Tests using a real browser

0 comments on commit 154a7a6

Please sign in to comment.