Table of Contents
- Overview
- Samples
- Front-end Samples
- Admin Site Samples
- Report Site Samples
- Architectural Overview
- Technologies/ Frameworks
- Infrastructure
- Future Improvements
Overview
I have been helping my dad who is organising the 3rd biggest running event in Greece, the Poseidon Athens Half Marathon and Parallel Races, by putting together a registration capability. This article is describing all the technical aspects of this effort.
The effort has been originally started in 2019, in line for the 2020 event, but Covid hit and all the running events in Greece got postponed by two years, so it eventually went live at the end of 2021 in line for the 2022 event which successfully took place in the middle of past April.
Samples
Front-end Samples
Although the registrations for 2023 are currently closed on the main public front end in preparation for the 2023 event, here are some screenshots from the test site:
Following that page comes a secured payment page that forwards the request via the registration-server to a confirmation or rejection page.
Admin Site Samples
All the below are sample dummy data in the test environment
Report Site Samples
All the below are sample dummy data in the test environment
Architectural Overview
In short, there is a public Front-end for the registration forms that consumes and directly interacts exclusively with a public Back-end component. The latter component is also responsible for scheduling jobs and email notification sendouts. To support Organisation members activities there are two additional components: the Admin site that is an authenticated/authorised view of all the data and the Report site for anything regarding reports and analytics. Finally, there is also a standalone tool that is responsible of parsing exclusively group registrations received via a customised excel spreadsheet.
Technologies/ Frameworks
The public Front-end has been built using the Create React App npx command. Multiple Ant Design components have been utilised especially the Form component capabilities. For internalisation the i18next React library has been used while for routing, the React Router has been used with the HashRouter variant.
The public Back-end has been built using Spring Boot exposing Rest Endpoints. For Database connectivity Hibernate has been used. The Spring Scheduling capabilities have been utilised for sending the email notifications while Apache Camel Barcode component has been used to generate the QR code on the email notifications. For the generation of the PDF attachment on the email, the iText library has been used.
For the creation of the private Admin site, the JHipster generator has been used to bootstrap the project in its React variant. With its Liquibase embedded capabilities, it is the master for the database generation and future changes application. Special care has been taken to maintain the script written in JDL (JHipster Domain Language) utilising the excellent JDL Studio Visualiser. The Authentication capability has been enhanced to allow some new more granular roles that are guarding certain functionalities.
The private Report site has been built as a single application where the backend endpoints are served via Spring Boot while the frontend code is served via React components. Special care has been taken to construct it in a generic fashion in that everything that appears takes the form of tiles that are showing some diagram or numerical value along with some icon and a download report link. For the visualisation part the Ant Design Charts have been used. For the Database connectivity the Jooq library has been utilised.
Infrastructure
The overall infrastructure can be summarised on the below diagram:
The code repositories are all hosted in GitHub while CI/CD has been setup as GitHub Action triggering AWS CodePipeline
All of the backend applications (registrations-server) as well as the standalone applications with both frontend and backend code (registrations-report and registrations-admin) have been deployed into AWS Elastic Beanstalk which is AWS’s PaaS solution sitting on top of their AWS EC2 solution.
Each one of the application has been deployed twice, representing Test and Production environments, each having their configurations injected.
The registrations-client front-end codebase also triggers via GitHub actions AWS CodePipeline, but this time gets deployed in AWS Amplify solution. In particular there is a main branch for Test deployment while there exist a prod branch for the Production deployment. Aside from making it very easy to deploy front end codebases, AWS Amplify is also giving out of the box an Amazon Certificate on the autogenerated domain or the explicitly owned and associated domain.
For the registrations-server public application in particular, the Load Balancing capabilities of Elastic Beanstalk have been utilised to auto-scale (up or down) based on a Network traffic threshold strategy.
This setup is bringing two additional benefits: Firstly it makes it very easy to associate a domain and/or certificate to the Load Balancer and secondly it makes it equally easy to do the same on subdomains.
For that reason via AWS Route 53 a domain has been acquired: stc-events-registrations-server.org and underneath it two subdomains have been setup: test.stc-events-registrations-server.org and prod.stc-events-registrations-server.org, each being setup via DNS records to forward directly to the Load Balanced AWS Elastic Beanstalk instance as it is shown below:
Having this setup is also giving out-of-the-box a certificate associated at the Load Balancer level.
Future Improvements
- Transition to a more generic and dynamic, metadata-based configuration where more than one registration forms could be accommodated. In such an implementation the front-end registration code will be quite thin and all the metadata configuration about what is to be displayed and how will be coming from the back-end. That would facilitate setting up future registration events effortlessly without the need to write any line of code.
- Decoupling the public back-end from scheduling activities that should be residing to a dedicated standalone other back-end application responsible exclusively for batch operations.
- Although Card Payment is supported currently via Cardlink, invoicing is still issued manually. In a future improvement, invoice will also be generated automatically and instantly at the point of purchase.
- Enhancing the Group Registrations capability. Currently it is accommodated via Excel spreadsheets that are sent out to Organisations and received back, being parsed later via a standalone tool. The nature of Excel is limited in terms of form handling so quality of data is lacking introducing delays in processing group registration requests. This functionality will be migrated to a web-based solution where the registration will be happening online.
Software dev ramblings 