# Adapting a front end without downtime

https://www.sanity.io/learn/course/handling-schema-changes-confidently/adapting-a-frontend-without-downtime.md

Prepare a front end for down-time-less content migration by adapting a GROQ query with fallbacks

Let’s say that we want to do this schema and content migration without any downtime and without disrupting the work of content creators. Before deploying the change to the Studio, you can deploy a small change to the front end that makes it ready to use the new field and fall back on the old field if there is no content. In other words, this is how the workflow could look like:

* Make the content query work with content for both fields
* Deploy the frontend change
* Deploy the Studio with the deprecated and new fields
* Run a content migration to move legacy content over to the new field
* Adapt the content query to remove the assumption of the old field

This may seem like a lot, but it should be fairly straightforward in this case.

In this exercise, we will use the front end code from the [Day one content operations](https://www.sanity.io/learn/course/day-one-with-sanity-studio) course.

### Adapting the GROQ query

You must only change the query to make the front end work with content from _both_ fields: `eventType` and `format`.

1. Locate the GROQ query for the single event route.

```typescript:apps/web/src/app/events/[slug]/page.tsx
const EVENT_QUERY = `*[
  _type == "event" &&
  slug.current == $slug
][0]{
	...,
	headline->,
	venue->
}`;
```

In this query, you use the ellipsis (`…`) as a quick way to return _all_ the fields on the document, and then below, you’re “overriding” the `headline` and `venue` reference fields with the join operator (`→`) to access all the fields of these documents. This is just a quick way to get all the data into the application and start experimenting with it. For projects in production, you would usually specify all the fields you use to prevent overfetching.

Now you want to override the `eventType` data to ensure we always get data for it, regardless if the deprecated or new field is used. To do this, you can use a GROQ function called `coalesce()`

1. Update the query with the `coalesce()` function

```typescript:apps/web/src/app/events/[slug]/page.tsx
const EVENT_QUERY = `*[
  _type == "event" &&
  slug.current == $slug
][0]{
	...,
    "eventType": coalesce(format, eventType),
	headline->,
	venue->
}`;
```

What this query does now is to first look for a value for `format` and set that to the `eventType` key, if it doesn’t find a value for it, it will fallback on the value for `eventType`.

1. Confirm that the query works by setting a value for “Event format” on an event that’s different from the “Event type”

Now, your front end and your new Studio schema changes can be deployed (you don’t have to for this course) without any downtime. Your content creators can start working with the new **Event format** field, while they cannot change the old **Event type** field.