LyticsConfiguration should allow for setting a custom baseURL and path.

[markhayden]

In the case of some of our more private deployment options, the endpoint for data collection may require a different URL. As such, we should leave the https://api.lytics.io... address as the default but allow for a baseURL and collectionEndpoint to be explicitly set during initialization if I want those to go to a completely different endpoint. However, it should be assumed that the payload is strict and can't be changed.

This also aids in testing, as I can point to a local proxy and expose the actual calls for validation before sending them to the actual collect API.

It looks like in the source we currently handle base and path in different areas so outlined them as separate above but if its easier / better to define a full collection URL for any reason we could go that direction as well.

Lytics.shared.start { configuration in
     configuration.baseURL = "https://mycustomdomain.com"
     configuraiton.collectionEndpoint = "/c/tacos/collect"

[markhayden]

[mgacy]

@markhayden do you anticipate the SDKs calling any other endpoints in the future and if how much freedom should the user be given in remapping endpoints?

1. Will they all have the same base URL?
2. If the collection endpoint is changed to https://mycustomdomain.com/c/tacos/collect/{stream} could the personalization endpoint be changed to https://mycustomdomain.com/some/totally/random/endpoint/{user_id}/?

[markhayden]

That's a great question. we'll definitely be calling other endpoints eventually, such as the personalization endpoint in your example.

As far as flexibility for MVP and probably the foreseeable future I think we can safely say the domain will always match for all of the API calls and then the path/params is going to be fixed (in that json collect will always be the same path regardless of where its hosted...and it will always use the stream name as the last section of the path...etc.)

One of the ways I'd want to use the config is to hit my local API. In that case my domain would be an ngrok tunnel (https://markcool.ngrok.com) or something like that but then the path matches the production API. This would allow for staging and all of that as well.

[mgacy]

@markhayden do you want to separate the specification of a base URL and subsequent path like:

Lytics.shared.start(apiToken: "at.xxx") { configuration in
     configuration.baseURL = URL(string: "https://mycustomdomain.com")!
     configuraiton.apiPath = "/c/tacos"
}

or simply do something like:

Lytics.shared.start(apiToken: "at.xxx") { configuration in
     configuration.apiURL = URL(string: "https://mycustomdomain.com/c/tacos")!
}

[markhayden]

Let's talk about this today during our standup. There is a similar ticket in the android repo and I am not sure I have a strong preference. Something about a single collection URL seems to be the simplest approach and ultimately probably the most flexible like we've done over on the android side.

https://github.com/lytics/android-sdk/issues/29

[jemerick]

When I was implementing this I did think of this kind of approach where there is Endpoint class in which you could specify the base URL and customize the paths:

data class Endpoint(
    val baseUrl: String = "https://api.lytics.io",
    val collectionPath: String = "/collect/json/",
    val personalizationPath: String = "/default/asdf/asdf/"
) {
    fun buildCollectionUrl(stream: String): String {
        return "$baseUrl$collectionPath$stream"
    }
}

Then you would just need to do apiEndpoint = Endpoint() for the default config (or really we just set this as the default in the config and the user doesn't need to set it at all)

or update just the domain: Endpoint(baseUrl = "https://ngrok.com/asdf")

or you could customize all the paths and base URL. This would also allow the customer to extend this class and implement a custom build URL path method to construct the collection or personalization URLs.

[mgacy]

That is more flexible than the current approach in the iOS version and it sounds like there aren't plans to add any more than a handful of endpoints. What are your thoughts, @markhayden ?