🚫 Removing Collection Presets in v3 release

[helloanoop]

Overview

In the upcoming v3 release of Bruno, we plan to remove Collection Presets.

❓ What Are Collection Presets?

Collection presets define default values applied when creating new requests within a collection. Currently, we support two types:

1. Request Type – Sets the default request type when creating a new request.
2. Base URL – Pre-fills the Base URL field during request creation.

💡 Why Are We Deprecating This Feature?

They Are Confusing for Most Users

• Many users assume that the Base URL defined in a collection preset is used at runtime, whereas it has only ever been a default value applied once when creating a new request.
• Although selecting presets at creation time can be useful, we do not believe these settings belong at the collection level.
• Based on community interest, we’re open to exploring similar defaults at the app level instead, where they would be more intuitive and impactful.

🔄 Migration Path

No action is required.
This change affects only a UX-level configuration that was used to pre-populate fields when creating a new request. Removing Collection Presets does not impact any existing requests or runtime behavior. Everything will continue to work as before.

📅 Deprecation Timeline

• Nov 27 — In-app announcements and warnings
• Dec 15 — Removal of Post Response Variables & release of Bruno v3.

[zFlxw]

Actually, I find this feature quite useful and I cannot really see a reason to remove it, so I want to give some of my thoughts about this change.

💡 Why Are We Deprecating This Feature?
They Are Confusing for Most Users

• Many users assume that the Base URL defined in a collection preset is used at runtime, whereas it has only ever been a default value applied once when creating a new request.

I don't quite understand what's confusing about the collection-level preset tab, especially because there is a explanation text that describes it purpose kind of unambiguously. And I mean, even if there is a majority of users that misunderstands the purpose of the tab, wouldn't it be better to just rename the tab or make the explanation text more noticeable instead of removing the feature completely?

Although selecting presets at creation time can be useful, we do not believe these settings belong at the collection level.
Based on community interest, we’re open to exploring similar defaults at the app level instead, where they would be more intuitive and impactful.

That sounds interesting, but I am unsure whether that's more intuitive, though. I mean, the main purpose of a preset is to automatically fill in the base url of the used API, which should be collection-specific in most cases, as you probably won't use the same base url for every collection. So I don't really see why the feature should be on app-level, as the only feasible reason for using an app-level preset would be to fill in some variable like {{baseUrl}}, otherwise it seems pretty useless to me.

Maybe I misunderstood the points you made or I am the only one who thinks like this, but just wanted to give some thoughts to that. If I misunderstood something or you want to address my points, feel free to correct me. :)

[helloanoop]

Thanks for sharing @zFlxw

So I don't really see why the feature should be on app-level, as the only feasible reason for using an app-level preset would be to fill in some variable like {{baseUrl}}, otherwise it seems pretty useless to me.

Yeah, agree with you here that app level does not make sense at all.

We'll await for more community feedback :)

[3limin4t0r]

I fully agree. I personally use this feature quite a bit. This is especially useful when working with Swagger or any other documentation that allows you to copy part of the URL with a dedicated button. When you fill the preset with the domain (and path prefix) you can simply copy the partial path from the documentation, click "new request" and paste it after the preset. Then give the request a name and you're done.

The only thing I wish was different is that presets would also be available on folder/directory level. Some APIs have a separate endpoint for authentication/authorisation requests. In which case I might want to use .../auth/oauth as preset for my auth folder, and .../api/v2 for my api folder.

[Rich-Hopkins]

I wasn't even aware of this feature, but now that I am, it is something I would use if it wasn't going away.

[simakuutio]

Make it optional instead of removing causes least confusion.

[zFlxw]

Well, it already is an optional feature.

[codecat]

Many users assume that the Base URL defined in a collection preset is used at runtime

I don't think it's worth removing the feature entirely because of this. If this is the case, why not improve the "new request" UI instead? For example, the placeholder text "Request URL" could be changed to something like https://example.com/... to indicate that it's an absolute URL. If that's not clear enough (because it's not visible when the preset is set), could it be explained below the URL field? (See circled area in screenshot.)

we do not believe these settings belong at the collection level. [..] we’re open to exploring similar defaults at the app level instead, where they would be more intuitive and impactful.

Can you explain why this would be more intuitive? Perhaps I'm misunderstanding how this would work, but I feel like this would be backwards; I have many different collections for different projects. In fact, I think the scope of this feature could be even better if it was on folder basis instead of only collection basis, so that when I create a new request in a folder it can automatically fill in the path that all the requests within that folder share.

[zFlxw]

Can you explain why this would be more intuitive?

It's not. But Anoop commented this under my comment above:

Yeah, agree with you here that app level does not make sense at all.

[btreecat]

One way to preserve the functionality but still dep the feature would be to have a host and port variable that if populated, provide the base path for the request. The benefit would be that you could change it after creation and it would apply the new path to all existing request for the collection.

[codecat]

This is kind of how we handle it in our collection where we have several environments (development, testing, production) which all have a different base URL. So we just set the baseUrl value for each environment and use {{baseUrl}} in each URL. (Obviously, {{baseUrl}} is also in our presets base URL.)

[merzeri]

I make extensive use of this for similar purposes to @zFlxw, where different collections are used for different purposes. For instance, Azure API calls do not have the same root as the vendor APIs for our largest vendor, which is different as well from any of the many others we also use. It makes creating new requests far faster versus merely copying/pasting. And said largest vendor uses the same URLs for test AND production with the API key determining which one is accessed.

A useful option could be to allow us to set a URL prefix on collection or folder levels, so a folder overrides or extends one, but I think the preset shouldn't go away even with that.

On a similar note, I think it'd be helpful to have pre-execution scripts parsed/processed for generating code, as I found examples where a collection-level pre-script was rewriting the URL to include the base so each request only had the URL of /some-api-resource since it prefixed it with https://apisite.vendor.tld/api, but generating code would only have a URL of http://some-api-resource/.

[miscbits]

By "app level" is this a reference to a global preset or a reference to environments? I similarly want a way of having a base url that isn't the same across all my collections, but I usually use an environment for this which has the advantage of letting me change between sandbox, preprod, and dev urls pretty quickly, however there are variables that make sense to be part of the collection themselves.

Example being we have a "date" field for several calls and its nice that we can set a default for this in the collection to something like January 1, 2010 and allow users to override that in the calls. We don't necessarily want to store that default in the environments because its not part of the environment and storing the defaults in every call is more difficult than having the collection default.

Would the idea going forward be to use the Collection -> Vars tab? It seems to accomplish the same thing that presets do anyway but I am not sure if there are other differences between these that make them incompatible

[mkalb]

We also make extensive use of the “Presets” feature. Each collection has its own “Base URL.” For the most part, this is a variable that is then specified in more detail in the environment. It would be a great shame if this feature were to be removed, especially since it already exists.

[Its-treason]

I don't understand why this should be removed. We use this feature in every collection for the BaseURL. The feature should be extended to also allow setting the default HTTP-Method.

[Rich-Hopkins]

@helloanoop Is there any discussion on reversing this decision as with the other change that was proposed and cancelled?

[helloanoop]

Hey everyone, Thanks for all of your feedback. We have decided to revert our decision and not to remove this feature :)

[Rich-Hopkins]

Thank you!

[AlexanderWangY]

Yay!