Skip to content

Add support for adding base-route for Runtime#1506

Merged
ayush3797 merged 270 commits intomainfrom
dev/agarwalayush/baseRouteForREST
Jul 17, 2023
Merged

Add support for adding base-route for Runtime#1506
ayush3797 merged 270 commits intomainfrom
dev/agarwalayush/baseRouteForREST

Conversation

@ayush3797
Copy link
Copy Markdown
Contributor

@ayush3797 ayush3797 commented May 18, 2023

Why make this change?

SWA or any other front end can interact with DAB using a path-based routing mechanism, where they may use a path (base-route) to redirect requests to DAB (refer to the bug encountered: #1420). This base-route gets stripped off when the request lands at DAB. Consequently, DAB is not even aware of anything like a base-route being used by the front end.
This poses a problem in generation of the nextLink, where the nextLink which DAB generates, does not contain the base-route and consequently when the front end receives the next request, it does not find the base route in the request URL and hence, has no idea where to redirect the request to.

Using the newly added option to configure base route for rest requests via the config (CLI option - --runtime.base-route), the front-end like SWA can make DAB aware that they are using a base route to redirect requests to DAB. DAB can then accordingly account for the base route while generating the nextLink for paginated responses.

What is this change?

  1. Added feature to specify base-route in global runtime settings in the config which can be via CLI as well using --runtime.base-route option in the dab init command. By default, it will be initialized as null. When the base-route is a non-empty string, it will be included in the generated nextLink. This feature is only supported when authentication provider == StaticWebApps. We throw an exception when base-route is configured for non-SWA providers.
  2. Extended functionality of Utils.IsApiPathValid(string? apiPath, ApiType apiType) method to Utils.IsUriComponentValid(string? uriComponent) because similar validations are required for api properties: rest.path/ runtime.base-route/ graphql.path, all of which are part of the request URI.
  3. Renamed RuntimeConfigValidator.ValidateRestPathForRelationalDbs() to RuntimeConfigValidator.ValidateRestURI().
  4. Renamed RuntimeConfigValidator.ValidateGraphQLPath() to RuntimeConfigValidator.ValidateGraphQLURI() so that we follow same convention between rest and gql.

Q&A

  1. Will this require updating an already created configuration file?
    No, the existing config file will work perfectly fine. The base-route is totally an optional feature.
  2. Will a default value be implicitly used if the new base path config property is not set?
    The default value for the base-route is null. This essentially means that base-route will not come into the picture.
  3. What is the default value and does the value differ between dev/prod swa/non-swa?
    The default value will be same irrespective of dev/prod/swa/non-swa environment and equal to null.

So to say, the change is not a breaking change and we are totally backwards compatible.

How was this tested?

  • Integration Tests - Was added to ConfigurationTests.cs to assert that the generated nextLink contains the base-route.
  • Unit tests - were added to ConfigValidationUnitTests.cs to confirm that we throw proper exceptions when runtime base-route is formatted incorrectly (contains reserved characters or doesn't start with a '/') or when base-route is configured for non-SWA authentication providers.

Removed some tests that weren't testing the CLI but dependencies (such as CommandLineParser or ILogger)
…them simpler and clearer with the new object structure
Moved logic for Entities defaults to RuntimeEntities rather than deserialiser, as that is a more logical place. We always pass that type around, so we can assume the ctor ran, but we aren't always assuming the deserialiser ran (such as what happens with tests)
Moving to a model where we load the config initially from disk and then generate an in-memory provider using an edited version of the config for the tests
Had introduced a regression that meant custom file names weren't supported on the engine directly. Now that can be passed to the RuntimeConfigLoader, otherwise the default filename is used. This means we're more flexible on the name of the file (useful in tests)
Singular/Plural were collapsed one level early, needed to nest them on a Type property
- Removing shared state as it can cause conflicts
- Better modeling of a config for the tests, and swapping in mock services
- Fixing the lookup for entities with the @model directive
Had forgotten to remove some old code in the deserializer of RuntimeEntities as well
Copy link
Copy Markdown
Collaborator

@Aniruddh25 Aniruddh25 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extended functionality of Utils.IsApiPathValid(string? apiPath, ApiType apiType) method to Utils.IsURIComponentValid(string? uriComponent, ApiType apiType, string apiProperty) because similar validations are required for api properties: rest.path/ rest.base-route/ graphql.path, all of which are part of the request URI.

This description needs to be fixed.

Comment thread src/Config/ObjectModel/RuntimeOptions.cs Outdated
@ayush3797
Copy link
Copy Markdown
Contributor Author

As per discussion with Ani over call:

  1. We would do the validation that the base-route can be non-empty only for SWA.
  2. We won't document/include this base-route option in the schema. This feature is only for system configuration and not for customers.

Copy link
Copy Markdown
Contributor

@seantleonard seantleonard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few suggestions but otherwise thanks for addressing the non-swa scenario validation and adding tests!

Comment thread src/Core/Configurations/RuntimeConfigValidator.cs
Comment thread src/Config/ObjectModel/AuthenticationOptions.cs Outdated
Comment thread src/Cli/ConfigGenerator.cs Outdated
Comment thread src/Core/Configurations/RuntimeConfigValidator.cs
Comment thread src/Service.Tests/Unittests/ConfigValidationUnitTests.cs
Copy link
Copy Markdown
Contributor

@seantleonard seantleonard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feedback on latest updates.

Comment thread src/Cli/ConfigGenerator.cs Outdated
Comment thread src/Cli.Tests/EndToEndTests.cs Outdated
Comment thread src/Cli.Tests/EndToEndTests.cs Outdated
Comment thread src/Cli.Tests/EndToEndTests.cs Outdated
Comment thread src/Service.Tests/Unittests/ConfigValidationUnitTests.cs
Comment thread src/Cli.Tests/EndToEndTests.cs Outdated
Comment thread src/Cli.Tests/EndToEndTests.cs Outdated
Comment thread src/Cli.Tests/EndToEndTests.cs
@ayush3797 ayush3797 requested a review from seantleonard July 14, 2023 18:23
Comment thread src/Core/Configurations/RuntimeConfigValidator.cs Outdated
Comment thread src/Service.Tests/Unittests/ConfigValidationUnitTests.cs
Comment thread src/Config/ObjectModel/AuthenticationOptions.cs Outdated
Comment thread src/Service.Tests/Unittests/ConfigValidationUnitTests.cs Outdated
@ayush3797 ayush3797 enabled auto-merge (squash) July 17, 2023 06:13
@ayush3797 ayush3797 disabled auto-merge July 17, 2023 06:17
@ayush3797 ayush3797 enabled auto-merge (squash) July 17, 2023 06:20
@ayush3797 ayush3797 merged commit fc257d4 into main Jul 17, 2023
@ayush3797 ayush3797 deleted the dev/agarwalayush/baseRouteForREST branch July 17, 2023 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working enhancement New feature or request

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

[Bug]: Wrong NextLink if using with Azure Static Web Apps

6 participants