Published Apps from App Builder doesn't support environment?

đź’¬ App Building
,
1

Hey there,

I created a small app with the new App Builder using a non-production environment, reading from Retool DB, and it works great in preview.

However, when I publish it, there’s no way to use that environment, it falls back to production, regardless of whether I append ?environment=alternative or ?_environment=alternative to the URL.

Are environments supported by App Builder?

I'm on the Business plan.

Thanks!

1 Like
Using Resource Environments with Agents / React Apps
3

Hi there, I’m on the product team here at Retool. Like you mention, we do permit toggling between resource environments while building in the new app builder. Testing on non-production data is a core building flow, and we want that to be well-supported.

At the same time, we’re trying to better understand the use cases for toggling between resource environments in the published, end user view. Would you mind sharing a bit more about your use case?

4

Hi @timofey

Sure, the use case is pretty common: letting end users test an app without touching production data.

Let's say I add a feature that I want a group of users to test and play with before releasing it to production, and without touching production data by using a mirrored dataset instead.

From your comment, it sounds like testing can only be done in the editor?

In Classic Apps, this switch can be done both in the editor and in the live app, and I think that's a great capability for avoiding disasters.

Hope it is something you might consider to add.

Best

5

That makes sense, thanks for sharing! We need to think about whether that experience fits better in the context of a published application — e.g., the final app that’s meant for end user consumption — or in the context of a “preview” mode. On that side, we’re working on adding shareable preview links, which allow builders to try out the app ahead of publishing to end users.

2 Likes
6

Hey @timofey

If such a "preview mode" allows the use of environments, that's even better, since it's something the app developer can choose to enable or disable, while the published app remains production-only, as it's expected to be aligned with production data.

Looking forward to see this feature!

1 Like
7

Hey @timofey, any update from the Retool team on implementing environment selection for the published apps built through the new App Builder?

I’ve been prototyping new tools for our internal team and not being able to give them hands-on experience with the app(s) without touching production data is HUGE miss, unfortunately.

8

Welcome to the community, @rcben! I know that we're actively tracking this and can look into the status for you. :+1:

9

Hi @timofey,

wanted to add on the use cases for switching environments.

We definitely also have the case that @abusedmedia has already mentioned - previewing/testing new versions of an app without touching production data.

On top of that, we also have the case that published retool apps (e.g., internal apps for product managers, data curators, and developers) are used to test different environment themselves. In that case we’re not previewing a new version of the retool app - instead we use the production version of the retool app to test a change in one of our environments.

Also, we embed Retool Classic Apps (e.g., within Zendesk). Our Zendesk testing environment, should then use the latest published version of the Retool App, but of course needs to connect to the testing environment to make sense of the parameters that are passed in.

Switching environments via parameter and via switcher are features in their own right, that I wouldn’t restrict to an app preview mode.

All the best,
Michael

10

Those are both really interesting (and valid) use cases, @michael_h! Thanks for sharing. I'll be sure to share this with the team. :+1:

11

Hi - is there a timeline for the ability to use context variables in the new app builder? These were used in classic apps to define different resource paths for staging and production environments, but don’t seem to be supported in the app builder.

The app builder shows the staging/production switch in the UI - but toggling it doesn’t so anything. Is that a bug? Or it’s a planned feature that will start working in some time? This is a critical feature in the classic apps to test apps on staging data before publishing it, and its absence on the new builder doesn’t look right.

12

@Darren @dvdhsu I posted this in another thread on this topic as well - this basically makes React apps worthless to us. Which leaves very slow non-AI classic app editing. Which leads to somewhere not-Retool.

I really like the new AI react apps and I get they can’t do it all out of the box but some things are so fundimental to the way people use Retool that they need to be in the base. Do you have a solution coming soon, or should we stop all work on React apps?

We have apps for setting up customers, etc that run against prod, stage and dev.

There seems to be no way to do this with React apps - or to reliably work out which environment they are pointing to.

For us, this makes React apps completely pointless. And we aren’t going to have classic for other environments and React for production. React apps are way less intensive to build but actually non-functional.

Do you have a solution coming soon, or should we stop all work on React apps?

13

Hey all,

Tanner from the product team here! Sorry for the delay in sharing an update.

We’re planning to tackle this in the coming weeks. One approach we’re considering, which would be notably different from the Classic implementation, is exposing resource environments through a custom hook (similar to currentUser()). The goal would be to give you more flexibility in how you implement and use this functionality within your apps.

We’d love feedback on this direction: would a hook-based approach serve your use cases? Are there scenarios where you think it would fall short?

We know this is a critical piece of functionality for many customers and are looking forward to getting a solution into your hands.

P.S. Because testing/qa use cases we’re mentioned, I’m excited to share that we’re also working on a Native Testing feature that should be available for beta testing in early Q4.

14

Hi @Tanner_Pierce - thanks for the reply

For us, I think:

  • Switching in code is fine - but it needs to be per app session not per query or resource.
  • Ideally, it wouldn’t replicate the current classic app issue whereby changing one browser tab to staging changes other tabs without any visual cue until data loads - this is dangerous. My ask is not to change other open apps.
  • This must be available in the published app (user selection), not just for users with editor permissions. I’m ok with adding controls, but not with this being editor-only.
  • If the app is set to a particular environment, then it needs to ensure all resources used are targeted at that environment - this shouldn’t be something I need to build into the app. Being able to explicitly override this for some use cases would be a bonus, but I suspect it probably isn't worth the complexity.
  • If we have apps that open other apps, then it must pass the same environment context to them.
  • We need to be able to add a selector that sets the environment - similar to how classic works (without the leakage)
  • We need a way for the code to know what environment the app is running against so we can control visual indicators and other behaviour. Like the classic environment variable - not what environment we asked for, but which environment we are actually in.

Happy to help test this if that helps - do you have a rough timeframe - weeks/months?

Cheers