This is an open sourced ticketing system. Given my background worked in multiple ticketing company, this project is built completely with my spare time. I were trying to leverage latest Java technologies to build it as I found there are quite a lot out of dated technologies being used in the ticketing business making it as an old-fashioned technology.
Ticketing can be with emerging technologies! So it ship with:
- Pure cloud-native and Kubernetes way to package and deployment
- Latest spring boot and spring security technologies
- In memory SQL database based on Java, distributed if needed
This project is open-sourced under the license of Apache 2.0 (https://www.apache.org/licenses/). Please feel free to raise one issue or join me to contribute it.
This project can be built directly with command as simple as follows
mvn clean package
or if we wanted to build via Docker
docker build
Using java -jar or docker run to start the ticketing system.
The back office UI will be listening at port of %HOST%/8080 and APIs will be available at %HOST/api. Specified to API, you can download the swagger spec (OpenAPI v3) via endpoint of /api/swagger. There are two profiles for development and production, the development profile uses Apache Derby as persistence layer, whereas the production profile uses CockroachDB (compliance with PostgreSQL).
Development mode (Derby as in memory database, swagger enabled, security disabled)
java -Dspring.profiles.active=dev -jar jticket-VERSION.jar
Production mode (CockroachDB as in memory database, swagger disabled, security enabled)
java -Dspring.profiles.active=production -jar jticket-VERSION.jar
As they are both in-memory SQL database, we could feel the power of database without adding too much redundant cache and way to keep consistence in application logic. This is the right way to use technologies I believe!
We assume following roles in the context of JTicket.
- Operator: On behalf the event organizer, maintain and design the venue and seat layout, supply the metadata of event and session, define the pricing of a given seat at venue, area or seat level.
- Customer: The audience of the event, will check the overview and make seat selection and then place order to buy a ticket for one or more seats.
- Attendant: Could be a human or a gateway equipment. Check the evidence of attendance (mostly a QR code) on a ticket before approving the ticket holder to enter the venue for a event.
- PaymentAgent: A system handles the payment and cash-in from customer, expect to trigger API of JTicket upon a successful payment for a given order. Out of the scope of JTicket.
| Name | OAuth2 Scope |
|---|---|
| Operator | template:write, event:write, venue:read, seat:read |
| Customer | event:read, order:write |
| Attendant | event:write |
| PaymentAgent | order:write |
There is build-in mechanism based on crowd in production environment. The back-office will therefore require authentication to function, whereas API require HTTP-BASIC auth to be used as well.
There is no complex clustering configuration of scaling out the system as we are leveraging the in-memory database as the only sharing points among working nodes. So as long as we can make Ignite cluster running good, JTicket cluster will work great accordingly.
De-couple from atlassian crowd which has concerns on working together with Apache license. Instead, integrating with standard OIDC with one example integration of auth0.