20
Building an Event Landing Page Management System
Frontend: joedietrich-dev/event-page-client
Backend: joedietrich-dev/event-pages-server
I was inspired to build this when I was tasked with repeatedly hand-coding landing pages in simple html. This was inefficient in terms of time spent and meant I was the only person around able to maintain the pages or make any changes. I set out to create a proof-of-concept / MVP event page builder. It has nearly all the entities I need to build those hand-coded pages.
This is the backend for a simple proof-of-concept event page creator. It is designed to let you build events with:
- Hosts
- Honorees
- Panels & Panelists
- Sponsors of different levels
- React / Create React App
- React Router v6 - For client-side routing
- MUI - A UI component library
- MUI Icons - For iconography
- Sinatra - a domain-specific language used to build the API framework for the app
- ActiveRecord - Rails' ORM, here used with Sinatra to map the Ruby classes to the database
- SQLite - the database engine used in this project
- Rake - to run commands on the command line
- Faker - used to build out seed data
Before I built out the migrations for the database, I sat down and planned the data structure. Below is a diagram of the different tables in the application's database and their relationships to one another.
Before I started building out the front end of the application, I knew I needed data to work with. Having real-looking data helps in the design process, and using Faker means you don't need to build out your database by hand.
Faker has a large number of different generators you can use to make your data more realistic or even if you just want to get a little more creative. I used and would recommend the:
- Company generator - for company names
- Lorem generator - for lorem ipsum placeholder text
- Number generator - for years
- Nation and Hobby generators - for somewhat sensical sounding event names (e.g. 2022 Malaysian Drumming Awards)
- Hipster and GreekPhilosopher generators - for English (or English-adjacent) text placeholders
- Name and Job generators - for people's names and job titles
All of these together helped me create reasonable placeholder data, which you can see in the demo video.
When I started building the interface for the app, I realized that deleting certain entities, like events or panels, could leave orphaned records. These were records that could not logically exist independently of their parent entities - especially the linking records between the panels and panelists and events and sponsors. I didn't want this, since orphaned records are just taking up space, at best, and could cause unexpected behavior at worst.
I solved this problem by setting the dependent: :destroy
option on some of my models' associations.
class Panel < ActiveRecord::Base
belongs_to :event
has_many :panel_panelists, dependent: :destroy
has_many :panelists, through: :panel_panelists
has_many :panel_sponsors, dependent: :destroy
has_many :sponsors, through: :panel_sponsors
end
Take the Panel
class as an example. A panel belongs to an event, and has many panelists and sponsors through linking models. When a panel is deleted, the panelists and sponsors should remain, since they can be associated with many panels. The linking records, panel_panelists
and panel_sponsors
are unique to the panel being deleted. With dependent: :destroy
, those records are deleted along with the panel.
Thanks for reading! For a walkthrough, take a look at the demo video.
20