Sessions in Postman


#1

Postman’s first public RFC

This would be Postman’s first public RFC! We are working on solving a whole bunch of key issues around variables, security, and UX with the notion of a session in Postman. Please read through the PDF below:

and feel free to leave your comments in the thread.


Sneak Peek


Comments: Sessions in Postman



Sensitive Information in Variables
Workflow: how to run another test in loop
#2

#3

First: My understanding is that introducing sessions are done to solve issues related to teamwork and shared workspaces. I have not used that feature, and I am commenting as one of the “other type of users” of Postman here. All of this is meant as constructive feedback.

How will this change affect users that only have 1 Workspace? I am already struggling with Postman getting rather sluggish when I have larger collections that rely on different sets of environment variables + global variables.

If I understand the suggested change, the session will be stored in the memory heap - together with the collection, environment and global variables? How do you plan to ensure that this will not introduce even slower performance in Postman?

Customizable settings: Are you slowly moving over to making Postman more customizable than it is today (in regards to changes possible to do in the Settings menu)? The two-pane view is still in beta, and has been for quite a while.

Collection runners: How will this change work together with sessions? As it stands today, if I run a collection through the collection runner; Postman itself is really sluggish. The reason for this is (seems to be) that the collection I’m running is updating a lot of environment variables.

Postman SDK/Collection version: How will this affect the sdk, introducing data types to the collection will perhaps be a breaking change? Are there any way we can prepare for this change?


#4

I think the sessions abstraction will eventually enable us to improve performance. Right now, variables are written to disk which causes an overhead. Using sessions will help tell Postman which variables are actually being used. We are putting in performance benchmark tests in the Postman app and I hope we can publish them publicly soon.

Customizable settings: Yeah. We are starting with separating our tab management layer. Panes as an abstraction will be next.

Collection runners: Will work the same way but I don’t think performance changes will be apparent right way. Sessions will make the behavior for a collection run and a request run in the builder consistent. For example we will have an option to persist a value from/to a session in the main view now. Earlier this option was only in the collection runner.

SDK/Collection version: Data types won’t be part of the first cut of sessions. We will ensure that Postman is backwards compatible by choosing sane defaults. I think that might be another thing we should post a public RFC on.


#5

Congratulations on your first RFC. I think this is a big step in the right direction to get input from the community.

I have read the document a couple of times and my first impression is that it makes sense with the objection that it is rather technical and open to interpretation in some of the points.

Since Postman is an UI tool, it would make sense to show sort of a prototype on how things could look like. I understand that this idea is in an incipient state, but what I am actually missing are a few use-cases for the sessions (prototypes actually showing how it will solve the problem).

I know that the problems mentioned need to be addressed somehow, but my concern is that variables are anyway complicated in Postman as they are. Introducing a new layer of variables (without reducing the others) can cause even more confusion. For most of the users today it is hard to understand when and how to use each type of variable that exists already (global, environment, collection, local, data).

Looking forward to a more detailed iteration of the idea.


#6

Thanks! Great feedback. This is the first public RFC that I posted and learnt a lot in the process. :slight_smile: We will share the prototypes design here soon.

There is lots of work going on in making variables easier. The goal is that sessions should not complicate anything for any use case. This won’t be an additional layer but something that spans across all scopes. The prototype will make it clearer.


#7

Thanks for the feedback guys. Here’s a sneak peak of what we want to build towards.

Would love to hear your thoughts on it. Expect an update with some of these features out soonish!


#8

#9

Hi @abhinav ,
Introducing sessions can be useful in making writing better integration tests without needing to make environment/global variables dirty (manipulating or adding n number of environment variables on the fly doesn’t look right details on one of the usecase)

My heavy vote on this :+1:

However, here are some points I think much needed:

  1. Like everyone said above: The requirement of Heap space (Memory leak, StackOverflow issues) for huge test suits having many persisting variables.
  2. Is there a future plan to make collection run in parallel (normal speed-up or enabling performance testing right within postman can be next big thing), sessions have to be more carefully built. Any static object and boom! At present, I’m suspecting, collection level variables are kind of static in nature (if not, please bear with my ignorance, not sure internal architecture wise, just guessing from a user point of view)

#10

It wasn’t clear to me how this implements the Prompt for Values request that we’ve all been wanting for quite a long time. Can you please show how that would work under your proposal?