Environment management and configuration

[Nachiappa]

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Postwoman should have an environment setup so that we can manage the variables between multiple requests and also it should support import/export functionalities

Describe alternatives you've considered
N/A

Additional context
Add any other context or screenshots about the feature request here.

[liyasthomas]

While working with APIs, we often need different setups for local machine, the development server, or the production API. Environments let us customize requests using variables so we can easily switch between different setups without changing requests.

We don't need to remember all those values once they are in Postwoman. We can download environments, save them as JSON files, and upload them later.

We can create, share, duplicate, export, and delete an environment. We can also import an environment as a single JSON file.

Environment and global variables are always stored as strings. If we’re storing objects/arrays, be sure to JSON.stringify() them before storing, and JSON.parse() them while retrieving.

Closely related to #139

[Nachiappa]

Can i assign this to me and start working ?

[jgroom33]

What is the value of saving the environment as text?

[liyasthomas]

JSON is prescribed as a standard format. For easy parsing key value pairs, filtering and iterating through arrays, etc.

[liyasthomas]

@Nachiappa how's your progress on this?

[jgroom33]

Imo, one of the weaknesses of postman is that all variables are stored as strings... Even if they are objects or arrays or integers.
As an example. Let's assume an environment as:

{"foo":{"bar":"baz.com","qux":"http://"}}

By storing environments as native objects, they could be referenced as:

{{foo.qux}}{{foo.bar}}

If all environments are stored as string, anything that is not a string must be preprocessed (i.e. using prescripts in postman)

Additionally, storing objects would enable a templating engine like nunjucks to be used for variable handling in requests (mildly useful) and in post body (very useful)

[Nachiappa]

I have started to store the environment variables as an value in indexeddb . Hopefully I'll able to complete by tomorrow and provide you a status. Is that fine?

[obbap1]

Are there screenshots of how this feature should be implemented? Should it be like Heroku's platform with key-value pairs or like postman where we'll have something like pw.setEnvironmentVariable("a", "b") ?

[terranblake]

@liyasthomas this issue looks to be somewhat stale. mind if i take over on this one?

[liyasthomas]

@terranblake yeah sure! You can work on this 🚀

[jgroom33]

I think this should be combined with #188

[terranblake]

@jgroom33 does the info from #188 need to be moved to this issue as a comment, or do we simply leave that one open for now?

[jgroom33]

This issue is overloaded anyway. It should probably be closed.
The import/export should be a separate issue.
If there is agreement that #188 will satisfy the original intent of this issue, then let's close this

[terranblake]

Postwoman should have an environment setup so that we can manage the variables between multiple requests

Is what I would like to approach with the following plan.

and also it should support import/export functionalities.

I think the import/export functionality can be addressed separately, or as needed once I make progress on the basics for the environment.

The plan would be the following (Steps delineate a planned PR):

1. New section e.g. Environment, with a stripped-down version of object-editor-react (In-memory for now)
2. Add basic templating support to URL and Params fields
3. Add DB to persist environment (Thinking redis, but open to suggestions)

[terranblake]

@jgroom33 I think this issue and #188 are different in that #188 sounds more like a feature for chaining requests/response together to make a workflow.

I interpreted this issue as a discussion for an implementation of a "global" environment that could be used between requests, but not dependent on a previous/next request existing. e.g. I want to specify the same token across all requests, or some garbage like that

[jgroom33]

I was thinking that an editable cache could be used to set vars. With that implementation, there would be a json with responses and anything the user wants to specify. But that wouldn't address the requirement of loading a set of vars from a file.

[terranblake]

@jgroom33 i think loading a set of variables from a file should be moved to a separate issue entirely. A simple environment can be implemented without the need for import/export functionality and should reduce the scope of this issue.

[liyasthomas]

I second @terranblake 's opinion 👍

[jgroom33]

I agree that loading the vars from a file is a good separate issue. Where does that file get loaded to? Loading it into a UI space that only handles env vars is not as flexible as loading it into a general cache.
What I would like to be considered is that a cache and an environment are roughly the same thing. Except that an environment is only expected to be used for environment variables. IMO, targeting only environment variables is a more limited approach than reading a cache that can contain both environment variables and device responses.
The cache should be a semi persistent (persisted in the UI view) data store that can be edited.
Another way to look at this is: where should the responses from a call be stored? Postman does a terrible job of this by requiring code to store the response objects into a stringified value of a user defined key.
Then there are a bunch of convoluted methods to access variables in the postman environment.
The cache can and should store both environment variables and API responses.

[terranblake]

Taking a stab at this one tonight. Probably going to skip the stripped down version of object-editor-react, but will have a basic proof-of-concept by tomorrow

[jgroom33]

this is powerful: https://mozilla.github.io/nunjucks/ and is used by this: https://github.com/eykrehbein/strest
<$ $> was used for the template ending because {{}} doesn't parse well in json or yml.
Another option is to use "{{ }}"... ansible does this

[jgroom33]

Some storage reference options:
{{ environment.foo }}
vs.
{{ variables.foo }} <-- just a nomenclature change
vs.
{{ foo }} <-- store all vars specified in 'environment' as global vars

[jgroom33]

using nunjucks also allows things like this:
https://github.com/eykrehbein/strest#using-random-values-with-faker

A common set of libraries can be implemented to handle:

• random number gen
• uuid generation
• timestamps
• jsonpath lookup of a result

[liyasthomas]

@jgroom33 awesome suggestion on nunjucks 🔥

@terranblake get around nunjucks and see if it meets our requirements. async support is there 🙌🏼

[terranblake]

@jgroom33 I like the suggestion for nunjucks. It looks like it has a lot of the same features as the language that I'm suggesting Liquid.

I don't see a downside to using either, other than that the liquid language is still actively maintained, whereas nunjucks looks to be not as actively maintained.

Based on personal preference I would suggest liquid, but I think both would be great options

[jgroom33]

Looks like liquid is written in Ruby. So if you want to write any custom filters or methods, you'll need to use that language.

[terranblake]

liquid allows you to register custom filters using the JS lib that I normally use

[NBTX]

I'm not quite sure I follow the discussion here - I'm coming to this issue from #139 and #196 so I'm under the impression that we'd be discussing a scripting language for chaining and inspecting requests rather than a templating language?

[liyasthomas]

@terranblake ping!

[AndrewBastin]

I am just unpinning this issue for now, due to inactivity and so I can pin the IE support issue as its more critical and help is needed.

[luixal]

I guess env management isn't supported yet, is it? is it under development or just "paused"?

[liyasthomas]

Pre-request env management is supported. Fully-fledged Environment management and configuration development is kinda paused.

[luixal]

You mean, by including values here for each request?

Maybe I can give a hand in this :)

[liyasthomas]

Well actually yes. But once an env is set, it is stored to app's current state. And needs to manually change them for another env var. Well this sucks.

[luixal]

I think the approach (UI, mainly) used in Postman is quite good, but I will prefer env values to be global by default but also having the ability to choose en values for each collection.

I think that's better understood by example: let's say I'm working on some request for service SA. I store them in collection CA. In those request I'm using an env var called host for storing host's ip/domain. Later on, I start working on some requests for service SB, in collection SB. I also use a env var called host. Today, I'm working on integrating SA with SB, which reside on different hosts... problem: they both use the same env var host. If I can choose to use one env config for requests in CA and another once for requests in CB I'm no longer having that problem.

Does it make sense to someone else?

[jgroom33]

IMO, This should be implemented:

• Allow loading environment vars from file during app launch
• Allow import of environment vars from a file using UI
• Allow modification of the variables in the UI
• Variable storage should be an object not a string
• Variable access in path uri would be: {{ pw.env.foo | tostring }}
• Variable access in body would be: {{ pw.env.bar }}

@luixal the first bullet should solve your requirement.

[luixal]

I'm not sure about loading env vars from file. Why if you are you using just a hosted version in browser? Maybe importing vars from file to an environment would be enough.

I agree about storing env vars as an object and allowing nested vars.

Not sure about the "Allow using each variable", what do you mean @jgroom33 ?

[jgroom33]

I'm not sure about loading env vars from file. Why if you are you using just a hosted version in browser? Maybe importing vars from file to an environment would be enough.

Not sure about the "Allow using each variable", what do you mean @jgroom33 ?

updated to include your recommend

[JacobAnavisca]

Just created a PR for environment management #591
Import, export, editing, adding, deleting, and selecting are all supported. I set it as a tab next to collections and when an environment file is selected it is added to the preRequestScript and showPreRequestScript gets set to true. Hope everyone likes how it works.

[liyasthomas]

#591 solves this, hence closing