Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add cut-down route object database #398

Merged
merged 13 commits into from
Apr 25, 2019

Conversation

mikkokar
Copy link
Contributor

This pull request:

  • Adds simplistic routing object database. it is almost a stub only at the moment, but it will be gaining more features as we implement application routing in terms of routing objects.
  • Renames routing related classes for better consistency.
  • Refactors the pipeline builder code to simplify (fingers crossed) the codebase.

@mikkokar mikkokar requested review from dvlato and kvosper April 12, 2019 14:26

/**
*
* A glorified map with extra features, like tagging objects
Copy link
Contributor

Choose a reason for hiding this comment

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

The comment describes extra features, but actually this interface provides a more restricted feature set than java.util.Map - it only provides equivalents to get and put, but with a non-generic key type.

The interface comment should only describe the interface itself, not its implementations.

import static com.hotels.styx.api.configuration.ConfigurationContextResolver.EMPTY_CONFIGURATION_CONTEXT_RESOLVER;

/**
* Built in interceptors.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* Built in interceptors.
* Provides a list of interceptors that are required by the Styx HTTP pipeline for core functionality.

/**
* Built in interceptors.
*/
public final class BuiltInInterceptors {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
public final class BuiltInInterceptors {
final class BuiltInInterceptors {

Environment environment,
Map<String, StyxService> services,
List<NamedPlugin> plugins) {
this.routeDb = routeDb;
Copy link
Contributor

Choose a reason for hiding this comment

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

Null checks please.

}

private HttpHandler configuredPipeline(RoutingObjectFactory routingObjectFactory) {
HttpPipelineFactory pipelineBuilder;
Copy link
Contributor

Choose a reason for hiding this comment

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

Please combine declaration and assignment.

* Styx Route Database.
*/
class StyxObjectStore<T> : ObjectStore<T> {
val objects = ConcurrentHashMap<String, Record<T>>();
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
val objects = ConcurrentHashMap<String, Record<T>>();
private val objects = ConcurrentHashMap<String, Record<T>>();

import reactor.core.publisher.Mono
import java.util.Optional

class RoutingObjectFactoryTest : StringSpec({
Copy link
Contributor

Choose a reason for hiding this comment

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

Please merge/rebase from change to proxy's pom.xml to mark kotlin test sources appropriately.

every { routeObjectStore.get("aHandler") } returns Optional.of(RoutingObjectRecord("name", setOf(), mockk(), mockHandler))

"Builds a new handler as per RoutingObjectDefinition" {
val routeDef = RoutingObjectDefinition("handler-def", "DelegateHandler", mockk<JsonNode>())
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
val routeDef = RoutingObjectDefinition("handler-def", "DelegateHandler", mockk<JsonNode>())
val routeDef = RoutingObjectDefinition("handler-def", "DelegateHandler", mockk())

mapOf())

val routeObjectStore = mockk<StyxObjectStore<RoutingObjectRecord>>()
every { routeObjectStore.get("secureHandler") } returns Optional.of(RoutingObjectRecord("secureHandler", setOf(), mockk(), HttpHandler { _, _ -> Eventual.of(response(OK).header("source", "secure").build()) }))
Copy link
Contributor

Choose a reason for hiding this comment

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

These two lines beginning with every are quite long (and with quite a variety of things in them). Perhaps they could be arranged differently?

} returns HttpHandler {_, _ -> Eventual.of(response(OK).build())}

val router = ConditionRouter.ConfigFactory().build(listOf("config", "config"), builtinsFactory, config)
""".trimIndent()))

verify {
builtinsFactory.build(listOf("config", "config", "routes", "destination[0]"), any())
Copy link
Contributor

Choose a reason for hiding this comment

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

The syntax for referring to parents here looks a little confusing to me. Wouldn't it make more sense for the [0] to be attached to the routes rather than the destination, since routes contains an array, whereas the destination is a field within each array item?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Possibly.

However, there is only one possible route attribute in the attribute containment hierarchy. OTOH there are two different destination attributes. The error message simply means "first destination attribute" or "second destination attribute".

By the way I'm investigating to see if the attribute parentage path could be removed altogether.

Either way, a change to this behaviour would be a separate enhancement, as it bit out of scope.

public HttpHandler create(StyxServerComponents config) {
boolean requestTracking = environment.configuration().get("requestTracking", Boolean.class).orElse(false);

List<HttpInterceptor> internalInterceptors = internalStyxInterceptors(environment.styxConfig());
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we inline this?

private final JsonNode config;

public RouteHandlerDefinition(String name, String type, JsonNode config) {
public RoutingObjectDefinition(String name, String type, List<String> tags, JsonNode config) {
this.name = name;
Copy link
Contributor

Choose a reason for hiding this comment

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

is name nullable? It's initialized to an empty string in the Builder...

private final boolean requestTracking;

@VisibleForTesting
public RoutingObjectFactory(
Copy link
Contributor

Choose a reason for hiding this comment

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

Can this be visible at package level/protected? I haven't checked.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It needs to be public because it is used in tests from couple of other packages: c.h.s.routing.config, and c.h.s.routing.handlers.

@@ -42,6 +43,8 @@ class BackendServiceProxyTest : StringSpec({
val baRequest = LiveHttpRequest.get("/ba/x").build()

val environment = Environment.Builder().build()
val context = RoutingContext(environment = environment).get()
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should specify when we are going to use named parameters (see other methods below that would potentially benefit from them).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean "specify when we are going to use ..." as in coding guidelines?

@mikkokar mikkokar force-pushed the refactor-styx-routing2 branch from b4a1b67 to ff1bf0e Compare April 23, 2019 14:01
@mikkokar mikkokar changed the title Add stub route object database Add cut-down route object database Apr 25, 2019
@mikkokar mikkokar merged commit 112c800 into ExpediaGroup:master Apr 25, 2019
@mikkokar mikkokar deleted the refactor-styx-routing2 branch April 25, 2019 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants