mirror of
https://github.com/hoppscotch/hoppscotch.git
synced 2026-04-26 01:06:00 +03:00
[GH-ISSUE #147] Environment management and configuration #59
Labels
No labels
CodeDay
a11y
browser limited
bug
bug fix
cli
core
critical
design
desktop
discussion
docker
documentation
duplicate
enterprise
feature
feature
fosshack
future
good first issue
hacktoberfest
help wanted
i18n
invalid
major
minor
need information
need testing
not applicable to hoppscotch
not reproducible
pull-request
question
refactor
resolved
sandbox
self-host
spam
stale
testmu
wip
wont fix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hoppscotch#59
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Nachiappa on GitHub (Sep 15, 2019).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/147
Originally assigned to: @terranblake, @Nachiappa on GitHub.
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 commented on GitHub (Sep 15, 2019):
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 commented on GitHub (Sep 15, 2019):
Can i assign this to me and start working ?
@jgroom33 commented on GitHub (Sep 23, 2019):
What is the value of saving the environment as text?
@liyasthomas commented on GitHub (Sep 23, 2019):
JSON is prescribed as a standard format. For easy parsing key value pairs, filtering and iterating through arrays, etc.
@liyasthomas commented on GitHub (Sep 23, 2019):
@Nachiappa how's your progress on this?
@jgroom33 commented on GitHub (Sep 23, 2019):
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:
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 commented on GitHub (Sep 23, 2019):
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 commented on GitHub (Oct 2, 2019):
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 commented on GitHub (Oct 8, 2019):
@liyasthomas this issue looks to be somewhat stale. mind if i take over on this one?
@liyasthomas commented on GitHub (Oct 8, 2019):
@terranblake yeah sure! You can work on this 🚀
@jgroom33 commented on GitHub (Oct 8, 2019):
I think this should be combined with #188
@terranblake commented on GitHub (Oct 8, 2019):
@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 commented on GitHub (Oct 8, 2019):
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 commented on GitHub (Oct 9, 2019):
Is what I would like to approach with the following plan.
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):
Environment, with a stripped-down version of object-editor-react (In-memory for now)@terranblake commented on GitHub (Oct 9, 2019):
@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 commented on GitHub (Oct 9, 2019):
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 commented on GitHub (Oct 9, 2019):
@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 commented on GitHub (Oct 9, 2019):
I second @terranblake 's opinion 👍
@jgroom33 commented on GitHub (Oct 9, 2019):
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 commented on GitHub (Oct 15, 2019):
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@liyasthomas commented on GitHub (Oct 15, 2019):
@terranblake this milestone feature will make you a collaborator ✨
@terranblake commented on GitHub (Oct 15, 2019):
Oh my gosh, that's like the most exciting thing I've heard all month 😱
@liyasthomas commented on GitHub (Oct 15, 2019):
Then you should hold your breath while I plan on giving out donations 💰 / swags 🌈 / badges 🏷️for contributors 🎉🎉
@terranblake commented on GitHub (Oct 15, 2019):
@liyasthomas would you mind changing the name of this issue to
Environment management and configuration?To get an MVP out, I'd also like to use the same functionality used in the raw payload section
@terranblake commented on GitHub (Oct 15, 2019):
Section completed. Now for the 💪 by adding templating to everything
@terranblake commented on GitHub (Oct 15, 2019):
Do we have a plan for what we want to use for the template language? I'm familiar with liquid, but would like to try something new if other have experience with another solution. @liyasthomas @jgroom33
@jgroom33 commented on GitHub (Oct 15, 2019):
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 commented on GitHub (Oct 15, 2019):
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 commented on GitHub (Oct 15, 2019):
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:
@liyasthomas commented on GitHub (Oct 15, 2019):
@jgroom33 awesome suggestion on nunjucks 🔥
@terranblake get around nunjucks and see if it meets our requirements. async support is there 🙌🏼
@terranblake commented on GitHub (Oct 15, 2019):
@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 commented on GitHub (Oct 16, 2019):
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 commented on GitHub (Oct 16, 2019):
liquid allows you to register custom filters using the JS lib that I normally use
@NBTX commented on GitHub (Oct 25, 2019):
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 commented on GitHub (Nov 8, 2019):
@terranblake ping!
@AndrewBastin commented on GitHub (Dec 5, 2019):
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 commented on GitHub (Jan 6, 2020):
I guess env management isn't supported yet, is it? is it under development or just "paused"?
@liyasthomas commented on GitHub (Jan 6, 2020):
Pre-request env management is supported. Fully-fledged Environment management and configuration development is kinda paused.
@luixal commented on GitHub (Jan 6, 2020):
You mean, by including values here for each request?
Maybe I can give a hand in this :)
@liyasthomas commented on GitHub (Jan 6, 2020):
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 commented on GitHub (Jan 6, 2020):
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 collectionCA. In those request I'm using an env var calledhostfor storing host's ip/domain. Later on, I start working on some requests for serviceSB, in collectionSB. I also use a env var calledhost. Today, I'm working on integratingSAwithSB, which reside on different hosts... problem: they both use the same env varhost. If I can choose to use one env config for requests inCAand another once for requests inCBI'm no longer having that problem.Does it make sense to someone else?
@jgroom33 commented on GitHub (Jan 6, 2020):
IMO, This should be implemented:
@luixal the first bullet should solve your requirement.
@luixal commented on GitHub (Jan 6, 2020):
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 commented on GitHub (Jan 6, 2020):
updated to include your recommend
@JacobAnavisca commented on GitHub (Feb 23, 2020):
Just created a PR for environment management https://github.com/liyasthomas/postwoman/pull/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 commented on GitHub (Feb 24, 2020):
#591 solves this, hence closing