Feedback on Team mode

[Stwissel]

Is your feature request related to a problem? Please describe.
A team of developers is working on a large scale API. When working on their individual branches and APIs they create API queries using Thunderclient in a few repositories. When trying to merge changes they run into merge conflicts frequently

Describe the solution you'd like
Switching persistence from file thunderclient.db to directory thunderclient.d where each entry is its own file. Collections would be directories. The property "name" could serve as file name. File content could be valid JSON

Describe alternatives you've considered
Developer team discipline

Implementation:
change how Thunderclient reads/writes files

[rangav]

Hi @Stwissel thanks for the suggestions, will think about these. I am also planning few changes to reduce diffs and conflicts.

[Stwissel]

You are welcome. Using individual files with valid Json would open the option to build a command line (think CI/CD) extension by a contributor

[nghtstr]

I have one other comment about Team mode. First, let me just say that this is really great, and has made the sharing of consumable APIs between front and backend developers really nice! One thing that has proven to be difficult is the sharing of collection variables between the team members. Right now, there has to be a massive environment to handle all of the necessary variables that we would have, but are not necessary between the collections. On that same vein, I would say the only other thing that has been a hinderance is the exclusion of parameter variables.

All things being said and done, these are minor problems that has solved a MAJOR issue that we have had. Keep up the excellent work!!

[Stwissel]

I wouldn't mind contributing code

[rangav]

@Stwissel currently core extension is not yet open for contribution by others. But we have 2 modules that are open for contribution, let me know if you are interested in contributing to these modules.

https://github.com/rangav/thunder-client-support#contribution

[Stwissel]

What modules are those?

[rangav]

• Code Snippet Generation
• Import Open API

[MelGrubb]

First of all, great work on this plug-in. I'm very impressed. For only being out in the wild a little over a month, this is incredible stuff.

I think a "team mode" would be great whether you're working on a team or not. I'll describe my use case and what I think would be required to get there. I work on a team where more than one of us may be working on a collection at the same time. With Postman, we only have import/export as a means of sharing things, and it is more convenient for us to ensure that everyone else is "clear" before we make any changes so that we can simply export the entire collection into a folder in our solution, and push it up to source control so that others can pull down the additions or changes we make. This one-at-a-time editing seems to be the only thing supported by Thunder at the moment, so it's not a loss, but it's not a gain either. For our purposes, Thunder is still basically at parity with Postman in terms of team support.

I did a quick spike, duplicating some of our Postman suite in Thunder just now, and had hoped to look in the folder where I opened VSCode and find a bunch of files that could be added to source control, but the folder remained empty, so the requests are clearly being stored somewhere else, probably off in AppData. I haven't gone looking yet.

I think there are just a few things that would hand Thunder the win for teams.

1. File-based storage of Environments, Collections, and Requests.
   If I were to add an environment or request, and it was simply represented as a file in the folder where VSCode is running, then I'd have source control by default. Cloning the repository and opening VSCode to the "Thunder" folder would pick up on the files that are already there, and you have a working test environment out of the box. Adding a new request results in a new file which gets committed and pushed. If the requests are individual files, then merges just happen seamlessly, unless of course two people edit the same request. Then someone has to merge things. Even without a team, the ability to switch branches or go back in time to a previous tag and have the environments and collections adjust appropriately would be a huge win for even solitary developer.

2. File-based storage of "secrets"
   I'd like certain things, like Auth0 secrets, to be stored separately from the rest of the variables so that we can exclude the secrets file from source control. You could try to include environment variables, as others have suggested, but this still presents a problem in that you'd have to create separate variables for each environment, and arrange your variable usage to add a prefix or suffix to choose the right one. But also, you'll end up with an explosion of environment variables. Ew. I'd suggest that if the environment can be stored in a file, then all you really need is a second section on the Environment tab for secrets. If the environment is stored in something like "uat.environment.json" then you'd create a second file like "uat.environment.secrets.json". Fiddle with the .gitignore a little and off you go.

3. Ability to include an existing request in a collection
   Once requests are file-based, there's no reason a single request file should have to exist as part of a single collection. I should be able to reuse a single request in multiple collections. Perhaps all requests should show up under an "All" collection that simply shows all the request files in the folder, but I could add them to one or more collections to support using collections to represent end-to-end testing scenarios. I would expect the request to go get an access token, for instance, to appear in virtually every collection. I know that the individual requests can be set up to get their own token, but our collection is set to do this as a separate step so that we can run requests as multiple different kinds of users.

[rangav]

Hi @MelGrubb thanks for the feedback.

Please see below link for team features, that will allow you save requests, collections, env secrets into your git project folder.
https://github.com/rangav/thunder-client-support#team

To save a existing request, click save to collection menu option

[MelGrubb]

Thanks. I am new to Thunder and still finding all the parts. I'm looking into the team mode stuff now. I just wanted to be complete with a description of how I'm trying to use it. If it can already support all of my scenarios, then I think you are clearly going to win the team space.

[rangav]

@MelGrubb I think it can do most of the use cases you mentioned, but I am sure there is scope for improvements always, so let me know any further feedback after the using Thunder Client.

[MelGrubb]

I think most of my suggestions still stand. Storing entire environments and collections in a single db file would still result in git merges even if two developers were working on completely different things. If my request were in its own file, separate from "their" request, then we wouldn't have a conflict in the first place. Likewise, if they're tweaking the UAT environment while I'm adjusting something on the Test environment, we wouldn't collide there either.

Basically, just breaking things up into smaller pieces reduces the chances for a merge conflict.

Still, the existing team features already pull ahead of Postman simply for making source control passive. If I make a change and the db file shows up in git's changes, then no-one has to remember to export and tell everyone else to import. Additionally, we get the point-in-time behavior that lets someone on main have newer collections and requests than someone on a previous release branch.

[rangav]

• Splitting the requests and env into individual files still may face the same problem, if all of the team members modify the request or UAT environment, then you it will lead to same issues with git merge conflicts.
• 2nd problem is we end up with 100 of individual files in git project, which may be another problem
• also reading and updating 100 of files may lead into performance problems.

I will research further on how we can improve this.

[MelGrubb]

I realize this would be a major change, so it's not a make or break for us. We're already dealing with this because of the export/import process in Postman. It's about reducing the odds of a collision. Environment files would still be at higher risk of a collision because there are fewer of them, but they also get updated far less often. Requests are where we're more likely to have problems, so spreading them out over more files does two things. It makes it easier for Git to figure it out on its own, and it supports the idea of including a dingle request in more than one collection. Maybe you have another way of doing that and I just haven't found it yet.

I'm still in the process of transferring over our Postman collection, so I don't have a lot of experience here yet. I know Thunder can do an import, but I'm going to take this opportunity to do a clean-up pass and organize things better than they were in Postman. Also, I'm changing some of our variable names that got out of control. It's like how some people dread getting a new computer because they have the old one just how they like it. I love moving to a new computer because I get the chance to try again, but better.

Once I have our whole suite in there, I'll have a better idea of what merging the various db files looks like. If they are easily mergeable json, which it looks like they might be, then this may not be hard. It's still not something that Git might handle automatically though. A few experiments will let me know.

Thank you for this. This is great.

[MelGrubb]

As I was running this through its paces yesterday, I noticed something that could make merges easier without having to change the way the files are stored at all. The db files are just JSON, but they are stored with minimal formatting, meaning that an entire environment, collection, or request is stored on a single line. Git is terrible at this and can only point out that line 5 has a conflict. If there were an option to save the files with full formatting, then Git would have a much easier time isolating the actual change to a more specific part of the file.

The only other suggestion I have around the file contents would be to order them in some predictable way other than chronological. Chronological ordering of a file virtually guarantees merge conflicts because two team members adding completely different things to the file would both have their changes appended to the end. If the files can be ordered in some other, predictable way, then the odds of a conflict are greatly reduced. It's one of the primary reasons I like my teams to use something like ReSharper to enforce ordering in our C# files. It's not about being a neat freak. It's about reducing the odds that your change and my change will be in the same part of the file. For the Thunder files, I'd probably just order the file contents by the entries' ordinal values that you're using to sort them on-screen. It's as good a reference as any.

[rangav]

Thanks @MelGrubb for feedback, will research further about your suggestions

[MelGrubb]

One thing my team has noticed in the past two days is that the requests in the collection seem to get updated by merely opening VSCode. I can go from a clean git status to all three db files thinking they have an update by simply opening VSCode at all, without even clicking on the Thunder Client icon. If you do a diff to see what the differences are, there are none to be seen, but they still show up in the list of changes. This is only a minor inconvenience, and only happens when you load the solution in VSCode. We primarily work in full Visual Studio, so it's not a big deal really.

However, the act of running the tests does make changes to the tunderEnvironment.db file since I'm using the Tests to store values from one test for use in a later one. For instance, an early folder consists of requests for Auth0 tokens which are then used to authenticate subsequent requests. Since we altered an environment variable, we've altered the file.

This might also be solved by a separate "thunderEnvironment.secrets.db" or "thunderEnvironment.local.db" file. I could leave the majority of the environment variables in the main file, but the tests could store the results in something other than the environment so that we don't alter it during the run. Forgive me if something like this exists already and I've somehow overlooked it. This is a whole new tool for me, and I'm still exploring.

[rangav]

Hi @MelGrubb In v1.8.0 we separated activity requests into separate file thunderActivity.db, based on feedback there were some optimisations done at the vscode extension launch.

[MelGrubb]

I'm not sure I follow. Can this be leveraged somehow for the tests to store results in something that doesn't end up in the environment file? I've seen the Activity tab, and the message that "Your activity will appear here...", and expected that maybe a history of requests would appear here, but so far nothing has. Note: I suppose this is probably because I don't have "Show Activity From Collection" selected. Based on the documentation, it's a way to import cURL statements though, isn't it? How does that help me leverage values from one response in another request?

Maybe if I explain my test suite better it will help. Since the collection runner executes the requests in order from top to bottom, our first folder of tests gathers some Auth0 tokens and stores them in environment variables. Our Postman suite did the same thing. Later folders try requests using a variety of tokens. A test may try to execute anonymously, or with an expired token, and expect a failure. A test may execute as a system admin and expect a different level of detail than when executed using a low-level user's token. Taking this idea further, a set of tests may add a new item through our API, and then store its Id, taken from the response, so that the next test can try to retrieve that same item. The test after that may alter or delete that item and so on. This Id will never be of any use to anyone because the resource it belongs to is "doomed" and will be cleaned up by the time the entire test suite has finished. Saving it off to source control is just noise in the history. What I need is a place to store that value that doesn't end up in the environment file, or goes to a different environment file that I'll simply exclude from source control. Perhaps instead of storing it in "environment", it could store it in a "local" file instead, or in the environment file that would have been used if I'd never selected "Load from Project".

[rangav]

Import Curl Cmd/Ctrl + u or use Menu option Import Curl
https://github.com/rangav/thunder-client-support#import

Activity:
To see activity from collection requests enable setting Show Activity From Collection

Environment:
When you run tests and selected set env variable, then it will update env variable from values in response, so will change thunderEnvironment.db file, this is how most users expect it to work.

Adding more env files will complicate things more I think.

As an alternative You can just undo changes on file thunderEnvironment.db when you finished testing

[MelGrubb]

For 90% of the tests, sure, but there will always be things you don't want in source control. For instance, the Auth0 ClientId is fine, but the ClientSecret should not be in source control, but will be required for me to make authentication calls to Auth0 to get a token. It's in the Environment file for now because it has to go somewhere, but ideally I'd like a separate "somewhere" for it to go. The simplest and most easily understood solution I can think of is a "local" equivalent of "environment". In the tests, instead of setting an environment variable, I'd set a local variable with the understanding that it won't end up in the environment file. Now, it could just be another file alongside environment.db, or it could be stored off in AppData or wherever Thunder was putting the environment.db file before I said "Load From Project".

What you've said does give me an idea though. I could add another folder at the end of the tests to "clean up" by emptying out the things I've stored along the way. This could take care of highly-volatile items like the tokens or arbitrary Ids that were generated during the tests, but keeping it up to date would be highly manual and wouldn't address the problem of true secrets like passwords and API keys that I want to keep out of source control.

[rangav]

I think what you suggested like clean up might be a good option for you.

We also have option to link to .env file in your workspace from v1.8.0

Some users add thunderEnvironment.db to gitIgnore

[MelGrubb]

I was going to ignore the file, but then we're back to a manual process of passing a file around to sync up actual substantive changes. For instance, if we add a new integration with an external service like Zendesk, for example, then I have to send around a new environment file to everybody that contains the new items required to communicate with it. Ideally, the main environment file would contain the url, and any non-secret pieces of information that the tests will need. I'd still have to send around the actual secret values like an API key or password if I want to keep them out of source control, of course, but non-secret changes could still flow out to the team passively. More importantly, I'd argue that non-secret values should be in source control because their changes over time or across branches are important.

Example: We split out our Auth0 tenancy not too long ago, and added a new environment. Most of the Auth0 configuration values are not secret, and I want everyone to have them. I only want the ClientSecret value to be excluded from thunderEnvironment.db, and it's easy enough to communicate that with the team through other means (e.g. "go slap this value in your local values"). More importantly though, when I switch to the current release branch, those values need to be different because it isn't up to date with the tenancy changes that we made. I need that branch to continue using the old values so that team members working on the stabilized release branch aren't tied to what the v.next team is doing.

I have a workaround for now, but the all-or-nothing approach of either loading the entire environment from the project folder or not poses some challenges. Not every value is appropriate for inclusion in the repo, but the gain from putting 90% of them in there is huge. It was one of the major headaches of Postman. Without paying a subscription, there was no way to collaborate on the test suite beyond a team size of three. I advocated for subscribing, but that's not my call. I don't pay the bills. What you have is simpler and easier, integrates with tools the team is already using, and solves a number of our headaches. I can't wait to see what's next. I'm just letting you know that, for team usage, I think the ability to sequester off certain values into something other than "Environment" would be huge.

[MelGrubb]

I dug through the documentation trying to figure out the .env file thing, but didn't get far. I don't quite grok their purpose. The Import/Export section of the docs just says "Import of .env files also supported, select Import from Env tab and choose .env file", but that's the only mention of ".env".

Could I put certain values in a .env file and that would keep them separate? Maybe this is what I'm looking for. I just don't understand its usage based on the docs.

[rangav]

When you open environment tab, you will see option like below to link to .env file, so you don't need to create variables again in TC.

alternative option is Import .env option will import variables from .env file

[MelGrubb]

Yes, but where is the explanation of what this does? What format does the file need to be? It seems to want me to select an existing file, but I don't have one. Maybe this is simple, and it's just a documentation thing. Basically, my question is "What does this thing do?"

Also, wouldn't this still be an all-or-nothing thing? Just in a different file?

[rangav]

Users will save secrets in .env file in their projects or local machine, then they can link to those files from TC

Format:
key=value

https://medium.com/the-node-js-collection/making-your-node-js-work-everywhere-with-environment-variables-2da8cdf6e786

[MelGrubb]

It looks like the .env files solve my secrets problem. I can define the passwords or API keys in the .env file, and they seem to load up just fine at runtime, but are not written to. I presume that's the intended behavior though, and that .env files should not be written to by the runner. That would have been nice as a place to stash the transient data that I don't want in source control, but I understand that's not what they're meant for. Still, I can use this for half of my problem.

I would still like to request some kind of local or in-memory storage if possible so that using the results of one request in a subsequent request doesn't have to involve the environment file. Maybe a slightly different syntax is all that is needed. You already have system variables like {{#guid}}, so could something like {{!token}} or {{$token}} work for stashing an in-memory-only value for use later in the same run (of Thunder, not of the collection)?

[rangav]

Yes thats the intended behaviour, extension will only read .env files not write values.

Where do you store your secrets currently like client id, client secret to get token or any other secrets.
OR you are not all saving any secrets in environments?

Yeah will think of you suggestion to store in-memory only not in env file.

[rangav]

FYI - you can also read this comment about .env files
#74 (comment)

[MelGrubb]

Thanks. That clears some things up, although I seem to have adopted the "wrong" naming convention. Unfortunately, I've been storing the secrets in the environment variables for lack of a better place to put them until now. I'll be migrating the secrets to non-source-controlled .env files.

The only thing left is where to store transient values that aren't necessarily secret, but also don't belong in source control like tokens or the results of tests. Whether they go in a separate local file similar to the environment file or whether they go in memory makes no real difference to me. If it's in a file, which I would gitignore, then it can survive cycling the app, but that's the only real benefit.

[rangav]

Hi @MelGrubb as you suggested local env variables, and set env variable with local scope.

Are these local variables available to all requests in all collections?

[MelGrubb]

I could make an argument for either. I would like them to be scoped to an environment so that when I switch from Test to UAT, for instance, I get the UAT version of the user tokens. That might be confusing though. If they were truly "local" values, then I guess I would expect them to be global to the application. If they could be viewed as "Transient Environment Variables", then I would expect them to be scoped to the environment, but not saved in the environment file.

Just making them global solves the problem of source-control "noise" in the simplest way possible, but with some additional mental bookkeeping on the part of the user. Scoping them to the environment is obviously more work on Thunder's end of things, but is more intuitive for the user. It could be presented as a second list on the environments UI labelled "transient variables" or something.

Global = short-term fix
Scoped = longer-term goal?

[rangav]

Thanks your feedback is noted, will wait for few other users feedback.

[jwmickey]

Hi, just getting started with ThunderClient. So far it is working great for sharing with teams except for one problem.

When using auth in a request, OAuth in my example, the access token is saved in thunderclient.db. I can keep the client id and client secret in the global environment, but the access token is tied to the request and we cannot have these in git. It would be great if these could be kept in memory or in a separate file.

This would also help in that the file would not be changed because the modified timestamp of the request would not change - which IMO should not change because of a token being generated since the request hasn't really changed, only the temporary credential.

Perhaps a thundercredentials.db file which might look like:

{
  "containerId":"abc123...", 
  "credentials": {
    "oauth2": {
      "accessToken": "xzy987..."
    }
  }
}

[rangav]

Hi @jwmickey thanks for the feedback, your feedback is noted.

Also you save the token in environment and use variable {{token}}

[jwmickey]

Thanks for the quick reply!

I'm using environment variables to store the oauth client id and client secret. What I cannot control with env's is the access token that is generated on the Auth tab of a request. When you click "Generate Token", this updates the "Access Token" field in the OAuth section, which is automatically saved to thunderclient.db.

In order to use {{token}} I would have to make a manual request to get the access token and save it using setTo(), but this means we cannot take advantage of the built-in auth tools.

[rangav]

If you want to use auth tab and generate token then you need to manually copy the token to env and use the variable

The other option is if you make separate request then you use set env variable functionality, which will auto save to environment variable

You can use any of above depending your convenience

[rangav]

Local Environment feature is now implemented in v1.10.0
https://github.com/rangav/thunder-client-support/releases/tag/v1.10.0

please let me know if any feedback

[rangav]

Hi all, just want to give an update of upcoming changes on database file format to address git merge issues.

There is a new dedicated issue for this #500, you can join the discussion there.

Current record format ( single line )

{"containerId":"","sortNum":0,"headers":[{"name":"Accept","value":"*/*"},{"name":"User-Agent","value":"Thunder Client (https://www.thunderclient.com)"}],"colId":"history","name":"https://www.thunderclient.com/welcome","url":"https://www.thunderclient.com/welcome","method":"GET","modified":"2022-04-02T10:10:08.795Z","created":"2022-04-02T10:09:42.038Z","_id":"49a0f878-fbcc-4212-a9fb-66b7b2b23f3c","params":[],"tests":[]}

New record format ( multiline indented ):

{
    "_id": "fcf7ed39-6a4c-47d9-b9fc-cfb9102a76de",
    "colId": "history",
    "name": "https://www.thunderclient.com/welcome",
    "url": "https://www.thunderclient.com/welcome",
    "method": "GET",
    "containerId": "",
    "sortNum": 0,
    "created": "2022-03-31T18:34:47.819Z",
    "modified": "2022-04-02T10:10:04.092Z",
    "headers": [
      {
        "name": "Accept",
        "value": "*/*"
      },
      {
        "name": "User-Agent",
        "value": "Thunder Client (https://www.thunderclient.com)"
      }
    ],
    "params": [],
    "tests": []
}

[rangav]

The new database format mentioned above is now published to marketplace as release version v1.16.0

See all features and bugs fixed here
https://github.com/rangav/thunder-client-support/releases/tag/v1.16.0

Let me know your feedback.

[max-mykhailenko]

Do you plan to split database to multiple files? There are a lot of conflict when 10 backend developers working inside one collection and it's super hard to resolve conflict in files that takes 14k rows. Maybe you can also suggest some smart git settings that prevents it?

Compared to useBruno one big JSON file doesn't look very promising

[rangav]

Hi @max-mykhailenko Thanks for the feedback.

Can you share more details of the issue your team is facing using the below form
https://www.thunderclient.com/contact

[rangav]

@max-mykhailenko created a new feature request for this #1507