Throughout the course of this summer, I worked on FOSSASIA's Open Event project for GSoC.
Majority of my work was done on the server side, i.e, on Open Event Server. The Open Event API Server enables organizers to manage events ranging from concerts to conferences, meet-ups, lecture series and much more. It offers features for events with several tracks and venues. Features also include subtle options like access and discount codes, session tracks, microlocations and so on.
The version 1 of the Open Event Project (Eventyay) has its backend and frontend tightly coupled with each other. This resulted in the project being very difficult to maintain. Since the project ecosystem also consists of other components like Open Event Android, Open Event Orga App, Open Event Webapp and Open Event iOS; interacting with data among these components was becoming more and more difficult in this tightly coupled system. Thus, last year, it was broken (i.e decoupled) into separate frontend and backend systems. The main goal of this year's GSoC was to build further on this decoupling and get the project to its stable version 2, which will be a fully functional, working and modularized system.
The API server followed the JSON API specification. Primarily, the following aspects were required to be done well by the server:
- Consistent data values throughout different endpoints
- Proper authorization, data leaks have to be avoided
- Proper relationship definitions
- Filtering
- Pagination
- Sorting
For Open Event Server, the API framework was chosen to be Flask-REST-JSONAPI. It allowed us to build on top of Flask, which is the framework used to implement all the business logic in the server, and it fulfilled all the above requirements. For the API documentation, API-blueprint was used. API-blueprint is a powerful high-level API description language for web APIs. API documentation is one of the most important parts of any API system. In order to ensure that the API documentation remained updated with the backend implementation of the API, Dredd was used as the API testing framework for this project.
Throughout the final part of GSoC, I also worked on the frontend part of the Open Event Ecosystem, aka Open Event Frontend. This client-side part is implemented in the emberJS JavaScript framework. Based on pre-defined data models and relations, emberJS can automatically figure out the correct API endpoint to call, among other functionalities. For the UI/UX of the frontend, Semantic UI framework is used to ensure the development of a robust and responsive UI.
Community Bonding:
- Started by fixing existing documentation bugs
- Fixed bugs regarding initial user permissions
Phase 1:
- Fixed bugs regarding URL structure of static files stored on the server
- Performed frequent database migrations, to adapt the database to more endpoints being implemented, as well as to fix bugs
- Worked on fixing bugs regarding inconsistent relationships between different API components
Phase 2:
- Implemented relationship between discount codes and tickets: this was a crucial requirement, but while implementing, I discovered a bug in the underlying API library, i.e Flask-REST-JSONAPI which hindered progress on this implementation. So I had to open an issue regarding this in the upstream library and also perform necessary modifications in the forked library used by the Open Event Server. This enabled me to complete the implementation.
- Implemented different endpoints related to sending emails, also fixed bugs related to some email APIs; especially adapted the lower-level email-sending function (which used Sendgrid) to the latest Sendgrid API.
Phase 3:
- Continued work on email sending endpoints
- Fixed more bugs in the server, related to superfluous permissions and API inconsistencies
- In phase 3, most of my work was done on the frontend, unlike the previous 2 phases, where all of my work was on the server
- Implemented user verification on the frontend
- Fixed various bugs on the frontend
- Worked on implementing the scheduler, where organizers can schedule sessions of their events conveniently. The fullcalendar library was used in the implementation
Thanks for creating this! It was a lot of help.