We last rebuilt the main event registration page at athleteReg in 2019. Seven years ago feels like “just yesterday” to me (especially when there was a pandemic thrown in!), but on the internet, seven years is a lifetime. With a new generation of frameworks and tools available to us, we’ve upgraded nearly every part of the technology that goes into serving a registration page.
The end result for event directors is simple: your registration page looks better, loads faster, and works better with everything else at Outside.
Looking Better
As the most widely used front-end UI framework on the internet today, React was the obvious choice for modern interface development that requires speed, flexibility, stability, and interoperability. Its massive ecosystem, constant updates, and huge developer community makes it a tool we can rely on to meet all our needs, now and in the future. There are times where innovation and taking risks makes sense… and a front-end framework isn’t one of them. We want to use something that works well and everyone else uses – and 70% of sites that use a Javascript framework front-end, use React.
Another major change since 2019 is that we’re now part of the greater Outside Interactive ecosystem, and guess what – the front-end technology of choice across the company is React. So we can borrow components from other teams, and the components we build for our registration page can play nicely with almost everything else at Outside now as well – lowering the barrier to cross-team and cross-product features. While we aren’t exactly at the “embed a registration widget in a Trailforks map” level of integration yet… the technology is ready.
Loading Faster
Javascript web components (aka “React”) need to get data from web services, and because our old registration page was all server-side rendered, we didn’t have any perfectly suitable web services just sitting around, waiting for a call from the front-end. Instead of trying to extend our existing web service offerings for this purpose, we took it as an opportunity to build new ones that matched how modern front‑end applications actually behave. Using GraphQL, we can return exactly the data our React components need, without dragging along legacy content from the old backend, and access our data with a standardized language that’s both flexible and efficient. Our GraphQL implementation is built with the Hot Chocolate framework and Apollo supergraph router.
Speaking of supergraphs – since many teams at Outside use GraphQL to access data, putting our new services on the Outside graph means that other teams can now query event data in parallel with everything else at Outside, giving us easy and efficient cross-team collaboration and opening the door to event data showing up elsewhere in the Outside network.
The End Result
Our registration page looks better, loads faster, works better with everything else at Outside, and just might be future-proof enough that THIS TIME we can go eight, or even ten years, before replacing all of them with a new generation of web technology!
2008 called. It wants its website back.
Just for fun, a look way back at how far we’ve come.
