University campuses have a communication problem. Events get announced through scattered emails, bulletin boards, and word of mouth. Students miss talks they would have attended. Organizations struggle to reach their audience.
UCAB (Universidad Catolica Andres Bello) has four campuses across Venezuela. Coordinating events between them was chaos. Each campus had its own channels. Information got lost. Event organizers had no way to measure interest or track attendance.
I built EnterateUCAB to solve this. A single platform where anyone could discover what was happening across all campuses.
What EnterateUCAB Does
The platform serves two user types: event organizers and students.
Event organizers can create events with titles, descriptions, cover images, dates, and locations. They specify which campus hosts the event. The platform supports all four UCAB locations: Caracas, Los Teques, Puerto Ordaz, and Coro.
Students browse upcoming events through a card-based interface. Each card shows the event date, title, and cover image. Clicking a card opens the full event details. Logged-in users can mark attendance, letting organizers know how many people plan to show up.
The platform also has a news section. Campus organizations can publish announcements that appear alongside events. This keeps the community informed about non-event updates.
The Technical Stack
I built EnterateUCAB with Django and Django REST Framework on the backend. The frontend uses vanilla JavaScript with jQuery and Bootstrap.
The architecture follows a clean API-first approach. The Django application serves HTML templates for the frontend while exposing a REST API for all data operations. This separation made it easy to build different views for logged-in and anonymous users.
The Data Model
Three main entities drive the application: Users, Events, and News.
Users extend Django’s built-in user model with additional fields for career, campus location, and profile image. The authentication system uses email instead of username, which fits better with university accounts.
Events store all the details: title, description, cover image, date, location, and place. Each event has an author (the creator) and tracks attendance through a many-to-many relationship with users. This lets students mark which events they plan to attend.
News articles follow a similar structure but without the attendance tracking. They serve as announcements rather than schedulable activities.
The REST API
The API provides endpoints for all CRUD operations:
- User registration and authentication
- Event creation, retrieval, and deletion
- News management
- Attendance tracking
Django REST Framework handles serialization. Each model has serializers that control what data gets exposed. Some serializers show all fields for admin operations. Others expose limited fields for public views.
Token authentication secures the API. Users receive a token on login. Subsequent requests include this token in the header. The framework validates tokens automatically.
Frontend Architecture
The frontend uses a manager pattern to handle data flow. JavaScript classes wrap API calls and transform responses into usable objects.
A parser converts JSON responses into typed objects. Dates get wrapped in a helper class that provides localized formatting. Day names and months display in Spanish. This made the interface feel native to the target audience.
Card components render events and news on the home page. Each card binds a click handler that navigates to the detail view. The responsive layout adapts between mobile and desktop through Bootstrap’s grid system.
Multi-Campus Support
Supporting four campuses required careful data modeling. Each event and news item stores a location code. Users also have a preferred campus stored in their profile.
The frontend filters content by location. Students can see events from their campus or browse everything. The location names (Caracas, Los Teques, Puerto Ordaz, Coro) appear throughout the interface in Spanish.
Authentication Flow
Users can browse events without logging in. Registration requires an email, password, name, and campus selection. The signup form validates input on the client side before submission.
Login uses email and password. The API returns a token that JavaScript stores locally. Logged-in users see additional UI elements: attendance buttons, event creation forms, and profile settings.
The authentication system supports session-based login for the admin interface and token-based auth for the API. This dual approach lets administrators manage content through Django’s admin while regular users interact through the custom frontend.
Image Handling
Events and profile pictures need image storage. I integrated Cloudinary for image hosting. Users upload images through form fields. JavaScript captures the uploaded URL and stores it in the database as text.
This approach kept the Django application stateless. No local file storage meant simpler deployment and scaling.
Deployment
The application runs on Heroku with a PostgreSQL database. The Procfile configures Gunicorn as the WSGI server. WhiteNoise serves static files without needing a separate CDN.
Django-Heroku handles most of the deployment configuration automatically. It sets up the database connection, static file serving, and logging with sensible defaults.
Challenges I Faced
Date handling was tricky. JavaScript and Python handle timezones differently. Events created in one timezone could show wrong times in another. I eventually settled on storing UTC and converting in the frontend.
The responsive design took more work than expected. Bootstrap helped, but custom components like the navigation sidebar needed manual CSS for different breakpoints. Mobile users needed a hamburger menu while desktop users saw a full sidebar.
CORS gave me trouble during development. The frontend ran on a different port than the API. Django-CORS-Headers solved this by allowing cross-origin requests from the development server.
What I Learned
This was my first full-stack project with Django REST Framework. I learned how to structure APIs, handle authentication, and build a JavaScript frontend that consumes REST endpoints.
The project taught me about the gap between building something and building something useful. The technical implementation worked, but getting real adoption required thinking about user experience, communication, and campus culture.
Building for a multi-campus university showed how location affects product design. What works for one campus might not fit another. Flexibility in the data model paid off when different campuses wanted different features.
