EG Booking System – Part 1: Switching to Next.js

#

The Engestofte Julemarked booking system started as a standard React application. While the initial prototype worked, it became clear that a larger project would benefit from a stronger structure and better built-in features.

Why Next.js?

#

The main reasons for switching were:

• File-based routing
• Better performance through server-side rendering
• Built-in image and font optimization
• Clearer project structure

As more features were planned, Next.js felt like a better long-term choice than continuing with a basic React setup.

New Structure

#

The new frontend was created in a separate project called frontend-next and follows the App Router structure:

app/         - Pages and routing
components/  - Reusable UI components
context/     - Shared state management
public/      - Static assets

This provides a cleaner foundation for future development.

What Stayed the Same

#

The backend remains unchanged:

• Express.js
• PostgreSQL

Only the frontend layer was migrated, allowing the application structure to improve without affecting the API or database.

What I Learned

#

This migration showed how important project structure becomes as an application grows.

React was great for quickly building a prototype, but Next.js provides a more scalable foundation and removes a lot of manual setup.

It also highlighted the value of separating frontend and backend responsibilities. Because the backend was already isolated, migrating the frontend was much easier than expected.

Next Steps

#

With the new frontend in place, development can focus on building features rather than restructuring the application.

Upcoming work includes:

• Interactive stand selection
• Venue maps and floor plans
• Exhibitor application forms
• Admin approval workflows
• AI-assisted stand recommendations