Go Auto

This was a large project!

A single repository holds both a Craft CMS project, which is running in headless mode, and a NextJS project. The NextJS project builds just once, and then multiple instances of it are run with different environment variables, and so fetch data associated with a different website from the Craft CMS GraphQL endpoint. A second GraphQL endpoint, which was provided by the client, is used to interact with the client’s CRM.

Most of the database queries are run from the server side – that is, the request goes from the NextJS server process to the Craft CMS server. The NextJS server process also queries Go Auto’s inventory API, which was provided by the client.

The front end also runs some GraphQL queries (in particular those which are dynamic based on the current logged-in user, and those which depend on a user input), and also communicates with the client’s CRM API. Furthermore, it fetches stock information and search results from Algolia.

The majority of content for each site is put together with the content builder pattern, meaning whoever is in charge of content for the main Go Auto site and each of the many dealership sites can build each page using a large set of predefined components, and adjust the content and settings for each one.

The GraphQL queries to fetch all the content builder data are complicated. We came across the limitations of GraphQL in building them – in particular, the fact that fragments cannot be nested within themselves means a lot of unfortunate workarounds.

Holding all of this together are a comprehensive set of Typescript types. Typescript really shined in this project!

• Data about cars comes from three different sources (Algolia results, the client-provided inventory API, and the client-provided CRM).
• Each has its own quirks.
• None of the sources are properly documented.
• None of the sources were stable during development; they changed multiple times.

Typescript definitions of the different forms the data can come in, as well as unified and minimal forms, plus functions to transform each source form to unified and minimal forms, were absolutely vital. Without all of that, the application would be rife with bugs. Instead, each time the data sources changed form I could update the types and Typescript would then tell me exactly where in the code I needed to make further changes. Thanks to the strong types, we can refactor with confidence even with a codebase this large.