Lately I had a situation where a customer needed Tulip to send a different value between dev/test and prod environment via query parameters. While that sounds easy, the current features don’t allow to easily do that.
Environment allows to use different certificates, hostnames, ports, headers and authentications. However, I couldn’t find anything that would allow to do the same for query parameters in a simple manner. The only way I can think of is tedious (dynamically try to find out which environment we are in from an app ( App info variable: connector environment (Production | Test | Development) - Product Suggestions - Tulip Community), set a variable value depending on that and send the value via a connector function input…). This would have to be done everytime we call the connector function that needs this…
I suggest to add connector environment variables. The idea would be to allow the user to define a set of keys and values per environment, just like HTTP headers. However, these values would not be sent automatically. They could be refered to in any connector function via the dollar syntax or another. For example, we would have $My input name$ for inputs and an alternative syntax for variables, e.g. $var$My variable$ or using another character, e.g. #My variable#.
This is a new idea, but not a bad one. Just to make sure I understand, you want different keys across environments? Or is it a combination of keys and values that differ across environments?
What is shared across environments, vs what is configured at each environment is something that the product is quite opinionated on right now (we don’t allow users to select this). For example, you cannot use a different path in different environments, or payload encoding, or output parsing, etc. We have known that we eventually want to make this more flexible, but need to do it carefully. Query parameters are function level (not connector level) so we cannot rely on adding this to the environment configuration, meaning we would need a new pattern at the function level for things that are not shared across environments (right now everything is shared across all environments).
The other path we have considered is enabling the ability to define connector-level variables that can be used for anything within the function builder, and can be set at the environment level, this would allow you to dynamically populate this content that has been statically set in environment configuration.
In any case, I have made a feature reqest for this,
Thanks for sharing.
Those are all good questions and remarks! The way I envisioned this was:
to define a set of keys that is the same for all environments.
Each environment would then have the ability to define its own values for all those keys.
Finally, at the connector function level, the key could be referenced (in the path, in query parameters etc. anywhere desired). But the value that would actually be used would depend on the current environment.
And more importantly, if the key is referenced in the function, it would be for all environments. This makes the function definition unique for all environments.
Long story short, I think I’ve just described what you said here:
The other path we have considered is enabling the ability to define connector-level variables that can be used for anything within the function builder, and can be set at the environment level, this would allow you to dynamically populate this content that has been statically set in environment configuration.
Also, I totally understand the product team’s will not to expose sharing mode options directly to the user. The degree of confusion this would bring is more than enough to justify this to me.
