[Feature Request] Please consider this idea instead of deprecating the "Base URL" field.

[jHumeLPL]

So, I understand you are deprecating this feature because some users have claimed it causes confusion, but I have to say, deprecating it is not the right call in my opinion. By removing this feature, it makes the Infinity plugin much more difficult to work with, not easier.

Instead of finding and pasting the Base URL in one time, I'll now have to find and paste it in for every query on every panel I use it on. This can be especially annoying when it's a data source I don't use often, as I now have to go find that information somewhere.

My idea:

The only reason this feature currently causes confusion is because, when using the data source in the Query Editor, it shows a blank URL box, even though we may have the Base URL set in the Data Source config. This has tripped me up before because it'll be a data source I configured months or years ago, so I won't remember that I've actually already set the Base URL. I just see a blank URL box so I figure I need to put it in there.

If you just bring the Base URL configured in the Data Source into the Query Editor (with maybe a message saying "Base URL configured in Data Source"), then it wouldn't be confusing. We could then either leave it as is, or overwrite it for this instance of the source. Not sure how difficult that would be to code, but I've seen some other plugins that do something similar, so I hope it wouldn't be too hard.

Same with Headers and Request Parameters. If any of them are set in the Data Source config, that should be seen in the Query Editor so that we don't accidentally set one in the Query Editor that is already set in the Data Source config.

As it is now, I don't even use the Base URL field because I'm afraid you will remove it one day and all my panels will break. I know you said you don't plan to now, but if that changes 1, 2, or more years down the road, I won't remember any of this and I'll be completely confused as to why a bunch of my panels suddenly broke.

Please consider my solution above or, at the very least, if you truly don't plan to actually remove the feature, maybe just change the message from it being deprecated to it being recommended not to use it since the URL field will still be blank in the Query Editor and it may cause confusion.

[keeks5]

Why is this being deprecated?
I was thinking to use this plugin, but because of this limitation I will not consider it.

Why? Imagine you have 100 dashboards that use different API calls. Now at some point the host is migrated to another location etc. And the URL changes. Meaning you would have to go and manually update all those dashboards. Instead changing one URL (the base URL) of your queries.

There should be such possibility to define, maybe even multiple base URLs. Then you would not need to add multiple data sources for each host.

[bram-tv]

Why is this being deprecated? I was thinking to use this plugin, but because of this limitation I will not consider it.

It was deprecated in commit de201ab which was done for #120.
Other related discussions:

• Why is BASE_URL in datasource config deprecated #212
• Why base url is deprecated? #698

[bram-tv]

If you just bring the Base URL configured in the Data Source into the Query Editor (with maybe a message saying "Base URL configured in Data Source"), then it wouldn't be confusing. We could then either leave it as is, or overwrite it for this instance of the source. Not sure how difficult that would be to code, but I've seen some other plugins that do something similar, so I hope it wouldn't be too hard.

Alternative ideas:

• when a Base URL is configured then show the actual base url before the field (i.e. instead of showing "URL <input field>" show: https://the_actual_base_url/<input field>)
• when a Base URL is configured then use the word Path instead of URL (i.e. instead of showing "URL <input field>" show: Path <input field>)
• automatically do the right thing:
  • when the Query-URL starts with a protocl (i.e. http:/, https://, ...) then use it as-is
  • when the Query-URL does not start with a protocol then prepend the base url

[canob]

Another big problem of deprecating "Base URL": if you want to use a Grafana Datasource Variable with Infinity, for example, to switch between different SaaS products API sources in the same table, with this deprecation, you cannot, because you don´t have the URL configured previously in the datasource.
This is really annoying, and, at the end, it is opposed to the "natural" idea of a Data Source in Grafana, which I think it is that when you "reach" Explore in Grafana, you already have the authentication access to the Data Source configured (that includes headers, query params, and URL in this case), and you can start accessing the data immediately.

[canob]

I can add to my comment that the Base URL is not working as expected if you try to use it, by not completing the URL in the Explore Panel:
If you not complete the URL in the Explore Panel, Infinity is going to use your Base URL + the example URL, https://raw.githubusercontent.com/grafana/grafana-infinity-datasource/main/testdata/users.json, + the configured URL Params:

As a workaround, you can add a SPACE in the URL, and is going to work:

[keeks5]

Can't we have both options? To define the base URL or not in the data source configuration?

Just migrated 3 dashboards that used the old GraphQL DS (depricated due to angular) --> Infinity. And while doing it I had 29 times to copy paste the "base" URL path for the queries on panels and variables. Really annoying. Please add the base URL possibility back :)

[digrich]

Over time, we have built a stack to provision data sources dynamically by changing the data source configurations in one place and using them across dashboards. This approach is commonly used with most data sources, where we define the base URL and configure supported cookies. Not having support for both of these features would be a big hurdle in adopting the Infinity Data Source.

For us, having base URL and support for allowed cookies is very important.