Building an Event Landing Page Management System

Frontend: joedietrich-dev/event-page-client
Backend: joedietrich-dev/event-pages-server

Inspiration

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.

Basic Features

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

What I Used

Frontend

• React / Create React App
• React Router v6 - For client-side routing
• MUI - A UI component library
• MUI Icons - For iconography

Backend

• 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

Entities and their relationships

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.

Faker

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.

Eliminating Orphan Records

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.

End

Thanks for reading! For a walkthrough, take a look at the demo video.