Technical Story: [description | ticket/issue URL]

Context and Problem Statement¶

The current search relies on dated vuejs code and client-side-rendering, it also has some performance issues and relies on loading all of the trips and filtering client-side. This data comes from a process executed via cron job every half hour and it's used by the client to render the UI.

This architecture has some huge drawbacks:

• Limited SEO and Shareability

Due to everything being client-side rendered, we can't use rich meta tags for shared links. Because filters are all in client state, the current filters can't be shared. The server has no idea what the page should look like.

• Performance Bottleneck

Current implementation results on old vuejs code that has to fetch and parse the JSON and do all filtering client side to then render all of the UI.

• Inflexibile

The current setup hinders our ability to quickly iterate and experiment with new features, especially enhancing trip search, because the code is not easily tested.

• Hard to maintain

The dated vue.js code and design of the current setup makes the code hard to maintain and blocks us from doing cool stuff like URL parameterisation without duplicating functionality and engineering ourselves into an even bigger mess.

• Does not reflect data modelling

The source of truth for trips is now the adventure manager, with the booking engine only really relevant for availability. The current process of generating JSON based on a mixture of booking engine information and wordpress data has a very limited lifespan and would need to be reimplemented in the case of a replatform anyway. Defining most trip related materials in the adventure manager is a more sensible trajectory and the current system does not allow for that without writing tons more PHP/vue code.

Decision Drivers¶

• We want to be able to have URL parameters
• We want our search pages to be sharable
• We want to enable make more complex improvements at pace
• We want to raise our dev standards in line with our other projects

Considered Options¶

• Introduce an API & Rebuild search in React
• Incremental refactor of existing code
• Third-Party Ecommerce Integration
• Rebuild search in React

Decision Outcome¶

Chosen option:

Rebuild in React, because it lets us improve the experience in the short term and empower us to implement more complex behaviours in the future with confidence and also remove a lot of friction in any future migration paths. We forego

Positive Consequences¶

• Shareability Enhancements

We can leverage routing in react to make filter state sync with the URL to make pages shareable.

• Better performance & UX

We can render a skeleton and rebuild with page load and CLS in mind, currently the vue solution waits for the all trips JSON to be loaded before rendering a page structure which leads to a poor first experience in most cases, we can render a page skeleton and show a loading state which will reduce layout shift and improve the first load experience.

• Better development workflow

If our code follows similar principles and tech to other projects such as the Adventure Manager and our app, we can ensure a consistent experience both on user experience and as engineers and leverage common design philosophies more easily in the future.

• Phased Approach

We can use the existing JSON as a basis without disrupting other functionality that relies on it, rebuild the client and do refinement - then take a more targeted approach to replace the CRON job once the interface is well defined.

• Dev portability

The rest of the tech team is generally familiar with TypeScript / React, this means there's less knowledge transfer and headaches involved for future engineers that might need to work on search.

Negative Consequences ¶

• Development Effort

Rebuilding the existing search functionality is a lot of development effort which would be hard to justify in isolation if we weren't introducing new functionality.

• Temporary Complexity

Replacing search does not replace other vuejs functionality which also relies on the JSON, so we'd need to modernize those other parts to fully remove the cron job, which would then present a great opportunity for adding an API. Until we do this there will be some additional complexity maintaining both.

Pros and Cons of the Options ¶

Introduce an API & Rebuild search in React¶

This involves dumping the existing vuejs code for the all trips page and rebuilding it in react. We'd build a new API for trip search leveraging elasticsearch to return trips from our search parameters and use this same API on the page to return meta tags based on the URL parameters, enabling shareable links and SEO optimizations on search. Using react and fetching the results server side also would improve page load experience, using modern react with well tested code paves the way for us to be more ambitious in our UX experiments and optimize conversion, and finally having an API leveraging elasticsearch allows us to eventually leverage much richer information (potentially realtime) for more relevant results.

• Good, because we can finally have better SEO on trip search
• Good, because we can have shareable links
• Good, because we will have more confidence in our code
• Good, because it enables us to do more complex UX experiments

• Good, because it moves towards growth stack being more aligned with the rest of tech

• Bad, because it's a lot of dev effort
• Bad, because it would need to be done in stages and this brings temporary complexity
• Bad, because we could deal with the client portion in isolation to avoid overwhelming ourselves

Incremental refactor of existing code¶

We could update the vuejs code to do URL parameterisation and write some additional PHP code to parse the URL and filter the JSON for rich meta tags.

• Good, because we still get better SEO and shareable links

• Good, because it's less disruptive than a full rewrite

• Bad, because we would duplicate functionality without an API
• Bad, because we still have a data issue
• Bad, because we don't get any substantial maintainability wins
• Bad, because we it doesn't enable more complex UX experiments

Third-Party Ecommerce Integration¶

Plugins for wordpress that have product/search functionality might be better than what we can build ourselves in a reasonable timeframe. It might not be purpose built, but with some dev effort to integrate properly it might yield short term benefits. It doesn't give it the level of control that our existing solution offers though, so it may even be a step backwards.

• Good, because it might offer quick wins in terms of improvements

• Good, because it's very little dev effort

• Bad, because customization might require lots of effort
• Bad, because it might actually make experiments more difficult
• Bad, because replatforming could undo any work we do here
• Bad, because we are reliant on more third party systems
• Bad, because there may be additional ongoing costs involved
• Bad, because we'd wish to use our own checkout and this might present too many challenges (booking.flashpack.com)

Rebuild search in React¶

This involves dumping the existing vuejs code for the all trips page and rebuilding it in react. We'd keep the existing JSON for now and revisit in the future, enabling shareable links but foregoing any further SEO optimizations on search for now. Using a page skeleton and better strategy for first load will reduce the huge amount of CLS, improving perceptible page load experience and using modern react with well tested code paves the way for us to be more ambitious in our UX experiments and optimize conversion.

• Good, because we deal with the client portion in isolation to avoid overwhelming ourselves
• Good, because we can have shareable links
• Good, because we will have more confidence in our code
• Good, because it enables us to do more complex UX experiments

• Good, because it moves towards growth stack being more aligned with the rest of tech

• Bad, because it doesn't meaningfully improve SEO on trip search

Links ¶

• [Link type](link to adr)
• …