Best practices for using Collections vs Requests+variable?

[elyseholladay]

When building Workflows and pages, we can either a) add and fetch a Collection, or b) make a Request, and store the returned data in a variable.

What do we consider best practice for using one vs the other? I’d love to read some docs on the nuances here. For ex., is it Collections if the data stays the same across navigation? Requests and vars if it’s just for that page or after an action, not on page load? Requests only for APIs not in your database?

Right now I’m kind of mix-and-matching, and it’s not super clear to me what is ideal.

[Broberto]

I think you’re mixing stuff up a little bit, and it is alright, WeWeb’s endless possibilities tend to be a little confusing in the beginning.

Fetching a Collection means in other words making a Request and storing the returned data. You can create variables and modify them or bind data to them (you can also bind data from collections to them). Also Workflows are your business logic, while pages are just a way of displaying them.

You get your for example REST API Requests as a collection. And you also get your Database data (after you request it) in a Collection. I’d suggest you play with it and find out how it all interconnects and what works for you If you hit a wall on the way, you can always ask here.

Use Case: I’m fetching data from my database as a Collection, I don’t like how the data is formatted, I get an array of records, where I have

[id, job_name, date, address, company_name, part_of_the_day]
[id, job_name, date, address, company_name, part_of_the_day]
[id, job_name, date, address, company_name, part_of_the_day]
[id, job_name, date, address, company_name, part_of_the_day]
...

I’d like this data in a format so I have an array of records, but sorted by part of the day and date like this

[date, part_of_the_day]
 {id, job_name, address, company_name}
 {id, job_name, address, company_name}
[date, part_of_the_day]
 {id, job_name, address, company_name}
 {id, job_name, address, company_name}
...

I’d set a variable where I would bind the data from the collection and manipulate it via Bind → Formula / JavaScript

[elyseholladay]

Yes, I’m clear on all that.

A Collection is a request which automatically stores the data in a Collection; but in a workflow you can also do a Xano Request, which returns data (which is not into a Collection, but can be stored in a variable.)

For example, in this screenshot I have an page load workflow.

I want to get the Job record from the id param of the page. This is a collection.

Then, I want to query my Matches table, to get an array of the matches that are related to that job record.

At this step, is it better to use a Collection? If so, why? Or a Xano add-on to attach the matches in the original job Collection fetch?

I store them in step 3 in a matches array.

Then for each match in that array, I need to request a single match record to get the details of each item and return that. Again, collection or request like I am doing here?

Making my Xano API have add-ons for the Job + the related matches AND all their data seems messy, because I don’t always need the returned Job object to have matches.

Are there best practices around when to use Collections specifically vs making a Request to your db in a Workflow and storing the data in a variable?

[Broberto]

I see, this is Xano and seems to work differently, didn’t know you’re talking about this one. I’m not a big fan of Xano haha, seems overcomplicated and expensive to me. In Supabase you have filters for this, I think. You’d get a collection where records match [your id] by reference, not via many calls to endpoints like this. Hopefully someone experienced in Xano can share their view

Now that I’m looking at it, you have select in Supabase too, but I never had to use it honestly. I usually go with collections for any queries to Supabase (Database). Maybe my workflows are too Simple

[Broberto]

My best guess would be, to use Collections for big stuff, like lists of data, properties, jobs. And use variables for small stuff like searching for data in a modal or something similar. You can bring both with you on navigation, the only difference is that you can have the variables stored in Local Storage which might be a cool feature, if you want to persist your data to some point.

[elyseholladay]

In my experience, Xano and Supabase work generally the same way. I haven’t used Supabase with WeWeb, but in code, when you do a filter:

const { data, error } = await supabase
  .from('cities')
  .select('name, country_id')
  .eq('name', 'The Shire')    // Correct

you’re saying, “get me only the cities that are named The Shire and only return the name and country id.”

In Xano, you can do this by editing the API endpoint to return specific items or only on a certain join or filter.

Again, in some cases this is what I want: a Collection that is only returning say, a job record. But in some cases I want the job record to include matches. I can make a different Xano endpoint for jobs-with-matches, but that seems messy.

I could make a collection for Matches that takes in a parameter, but as far as I can tell, when you use a Fetch Collection in a WeWeb workflow, you can’t pass in the value of the param you need there. (Am I wrong about this?) I mean, my Single Job Collection needs a job_id to send to Xano, and the Collection itself has that job_id field, but in a Workflow I can’t set the value of that job_id. But you can do a Xano Request and send the params you want.

[Broberto]

Yeah, in Supabase you do this via Filtering within the Supabase Plugin (when you fetch a collection), you can do joins via advanced too. No need to go to Xano and create endpoints there. As you said, creating many endpoints seems messy yeah. If I need to get a job where id is … I do something like this, where I filter it within the collection.

[aurelie]

Collection is a “special” variable. It holds some common features, so you do not have to do it yourself

• Easy configuration with plugins (exploring your DB for example, instead of finding yourself the correct REST url)
• Pagination
• State (isFetched/isFetching) for loader
• Possibly automatic fetch on each page

Like any “assisted” tools, its making common usecases easier, and in exchange may do special usecase less easy.

[AJAW]

Btw is it possible to update collection manually? Sometimes I need to manipulate a collection to update a variable without refetching it. What I do now is store the collection in a variable but it seems that it should be possible.

[aurelie]

The only way to update a collection for now is to refetch it, so if you need partial update, it must be on a variable.

[felipegranado]

Hi @elyseholladay !

If I understand your question, I also went through this recently.

Generally, those who came from Bubble have a little difficulty, because when we create an API call, we define whether it is an action call or a data call. In WeWeb/Xano there is no such distinction and “everything is exposed” to us.

Currently I have to create all GET calls in Collections and POST and PATCH calls as a workflow, creating the parameters and linking them with the necessary parameters of the call.

I don’t know if this was the topic of the question, but I thought it would be interesting to share this vision.

Best Regards,

[Cedric]

Hi @elyseholladay, This is a great question and I’d be interested to hear your feedback since you posted this several months ago.

We started out using Weweb collections for most API requests, due to the benefits that @aurelie pointed out. However one of our clients webapps was getting progressively slower. Eventually we figured it was due to the ever increasing amount of collections/data. Yes we were using backend pagination and limiting the number of records ~10 etc. but with dozens of collections, and in our case all the functionality is available on one page (chats, notifications, notes, calls, etc.)
so without the user being required to switch the page - those collections won’t clear.

So we recently did some ruthless updates and now we cache very little data in collections. It improved our load times from like 25s to ~4s (yeah it was bad )

The ability to clear a collection through a workflow would resolve this.

The other limitation with collections is the inability to do a partial update, which would be super useful…

But yeah, I love Weweb, so please don’t take it as criticism