Testing environment and production

Ask us anything
1

Hello,
I am getting ready to publish our site soon.

I need to think through how to set up a testing environment.

What is the best practice for this on the WeWeb side?

I’ve thought about creating a variable called “is_test_enviornment”.

Then, inside all of our API endpoints for CRUD, set them if/then based on that variable.

I could then work on the site with the is_test_enviornment set to true, then change it to false, then publish.

Any thoughts/best practices here?

Thank you.

2 Likes
2

To be honest, we don’t have best practices for now (we’re working on the staging environment right now, that’s a big issue for our users).

Most of our users copy the app and change the URLs to the staging ones in the copy, but I assume what you’re doing would work too :wink:

1 Like
3

Thanks Quentin. I like the approach of the copy more. That removed any ability to accidentally hit the publish button by accident as well.

Do they then just copy/paste changes into the production environment, then publish?

4

Ah yeah I forgot about the new pricing. Send me your workspace ID by DM and we’ll give you 2 live apps :wink:

5

@Quentin is this still the best approach for handling a staging environment?

6

@Quentin I also need a staging environment too. Would it be possible to have two apps for my project but pricing remain the same?

7

@caffeinatedwes I think it still is atm :wink:

@tjmcdonough we’re currently working on a new pricing and the staging env, we’ll keep you posted!

2 Likes
8

@Quentin Thanks!

9

@kevinwasie, did you use Xano’s branching feature as well by chance?

@Quentin how does WeWeb’s native Xano integration handle branching? I’m guessing with the current integration that WeWeb always use the live branch. Is there any way to use a non-live branch in a project?

Here’s how I’m currently thinking through an ideal setup—

Live/production environment

  • My WeWeb app is live on a specific domain
  • WeWeb uses my live Xano API by default

Testing environment

  • I think I would need an additional custom domain so I can copy the live project, publish it to “dev.testing.mywebsite.com” (or something similar), and begin making edits and publishing those edits to dev.testing.mywebsite.com so I can test them in a “real” environment.
  • When I’m ready to go live with this version, I would need to remove the live WeWeb’s domain and add it to the new WeWeb app.
  • Ideally, there would be a setting on the WeWeb<>Xano integration (under Xano in the plugin settings) to configure WeWeb to work alongside Xano’s versioning logic. IE, I could select which version I would want to use, and if I selected one of my non-live branches (such as branch v2), WeWeb would add :v2 to all API endpoints

From what I can tell, everything above is possible except for the bolded “Ideally…” component, but I’d love to hear from someone on the WeWeb team to confirm (or suggest a different route).

10

Hey @Quentin, circling back here :nerd_face:

11

Adding the need to the roadmap for Xano. In the meantime, I suggest using the REST API plugin and concatenate based on a variable containing the API base URL, and change it when in prod.

(As you can see in the CRM template)

1 Like
12

Thank you, @Quentin

(As you can see in the CRM template)

I’ve found the documentation, but not the actual template.

Do I need to reach out via support to get access?

13

You’ve got access to it when creating a new project :wink:

CleanShot 2022-10-12 at 17.32.33

1 Like
14

Thank you!

15

Hi friends! Is moving from the Xano plugin to the REST plugin still the recommended way to manage working across branches with Xano as backend? Or is there another way to work with/hack the plugin so we can keep using those nice picklists?

1 Like
16

You can use the headers configuration to switch between Xano instances →
CleanShot 2023-05-24 at 18.40.54

17

@Quentin does this allow working with different branches? It reads as just changing the data source.

Branches manage different code, while the data source is different tables. It’s the former that I would like to test if possible.

1 Like
18

You’re right! We plan on adding support to Xano branches in the plugin in the following weeks.

2 Likes
19

@Quentin as @caffeinatedwes mentioned above… it would be ideal to have WW staging environment deployed onto a custom URL – any chance this is on roadmap as part of branch updates?

for us, this is necessary due to how GraphQL endpoints are hit. we utilize two backends - Xano and custom in-house via GraphQL.

  • Ideally, we have one WeWeb project (lets say “internal admin”)
  • Xano integration: WW editor => configured to hit Xano dev branch and db; WW staging => hit Xano staging branch and db; WW production => Xano production branch and db
  • We’d want to configure env variable for GQL queries from WW to set request URLs by environment (WW editor => GQL dev, WW staging => GQL staging, WW production => GQL prod)
  • Last, we’d set both WeWeb production and staging URLs (ie. staging.admin.com … production.admin.com)

can you let me know if this will be possible? trying to avoid needing to copy/recreate new WW environments to ‘carry over’ and deploy changes – especially because updating the production domain then becomes a bit tricky within WW (unless I’ve been doing it wrong).

thanks for all you guys do!

1 Like