There needs to be a way to control the version of the Data API Builder that is running on the Static Web App

[TonyLunt]

Is your feature request related to a problem? Please describe. There should be a way to specify the version of the Data API Builder to use. This would allow for graceful adoption of breaking changes. Let me know if this belongs on the Data API Builder repo instead, but it feels like a Static Web App feature.

As an example: Version 0.9.7 of the Data API Builder introduced a breaking change in how Azure SQL uniqueidentifier columns are parsed in GraphQL. Previous versions parsed these as Strings and now they are parsed as UUIDs. Given that some GraphQL mutation formats include the variable type, there is no way to gracefully know when to update your codebase to support the correct data type. Frustratingly, the SWA CLI is using a newer version than my Static Web App so I'm not able to use the same code in both places.

Describe the solution you'd like There should be an option in the static web app json config to specify the Data API Builder version and a clear way to know what versions are supported in Azure.

Describe alternatives you've considered The only alternative I see would be to host/implement the Data API Builder outside of the SWA underpinnings.

Additional context Add any other context or screenshots about the feature request here. Example

The SWA CLI with version 0.9.7 of the Data API Builder only supports this payload (there are also variables provided):

mutation UpdateProfile($id: UUID!, $item: UpdateProfileInput!) {
                        updateProfile(ID: $id, item: $item) {
                            FirstName
                            LastName
                        }
                    }

The Static Web App in Azure only supports this payload:

mutation UpdateProfile($id: String!, $item: UpdateProfileInput!) {
                        updateProfile(ID: $id, item: $item) {
                            FirstName
                            LastName
                        }
                    }

[Izzmo]

I second this. Needs to be some transparency here.

[thomasgauvin]

Thanks for the feedback, noting this as an improvement to the database connections experience.