I’m looking for someone who has successfully set up a Bubble+Xano app and pick your brain on some setup and nuances over a quick zoom call if anyone is willing.
It would be hard to go over in a text post, but the gist is:
Thanks in advance.
Xano is awesome and easy to use no doubt.
But … why go through the upkeep of two dBs?
Unless there is a compelling reason and the time/resources to keep 2 places syncd for both repository and cache data …. I would say that is an uphill struggle for sure 
Here’s the story, I’m open to suggestions:
I have a bubble app and i want to build a native mobile app (no i don’t want a wrapped web app, please don’t suggest that).
I’m using Draftbit for the front end but using bubble itself as the backend where bubble isn’t the frontend is a nightmare. This is probably an issue with every app but let’s say you have a social network with users, posts, likes, bookmarks, follows, etc.
A user data type looks like this:
And a Post data type looks like this:
Every object that is a List of X (posts, users, bookmarks, notifications) from the outside is a list of strings/ids.
If i want to query a user and display all of the posts that user would see, i pull the user data, and now i have to run a query for every single user id in their “following” list, and then a call for every single “post id” each of those users have in their List of posts, and then a query for every single User and Post IDs in each posts “Boosted By” and “Hearted By” and on and on it goes.
This is a massive, insane and recursive web of API calls. It is inefficient and complex. Bubble of course has it’s on built it way where it abstracts all of this because bubble can automatically “translate” each user ID to it’s subcomponents and just display the username ec, but from the outside all you have is a user id, it doesn’t give you the user name and all it’s details. It’s a sort of internal GraphQL type of system that isn’t offered to the outside.
It does have Backend workflows that lets you do some internal filtering like getting a list of all posts for a user and return it as a JSON but it can only do one layer deep and backend workflows API is also more limited than the main API for responses, so that doesn’t really solve the problem.
Xano has its own GraphQL type of data queries where you can make one call and behind the scenes it finds and fills in all the subcomponents you need and returns the actual data and instead of id numbers that will require more api calls, so with a single call i can return a data tree with all of the data i need and it does it really fast.
And here is the challenge. If i use Xano as the backend, now i have to use bubble less in the way it was intended and I have to make the same API calls from bubble to xano that i do from draftbit to Xano. And i lose most the ease of use of the natural language constructors in bubble when adding/editing it’s internal database.
So i was wondering if it still somehow makes sense to keep bubble’s database as is, and find an easy way also offload it to xano for drafbit’s sake, or is that more of a mess. And if it does indeed make more sense to just use Xano as the backend, what does that look like in bubble. Do i now how to make all those elaborate calls when writing data and I didn’t save any complexity?
To sum up, if i want to use bubble for the web app, and drafbit for the native app, what would be the simplest solution here?
Change your Bubble dB model to be all (or most at least) inverse 1 to 1 relationships and optimize objects to be as light as possible. This reduces lists and brings the objects you need with Xano calls.
It is counterintuitive to how many folks build apps but it actually is a practice the Bubble does surprisingly well (search light objects fast even inside RGs which will be needed intensively given this dB schema).
This may help a bit but there will be other aspects of maintaining two dBs that will flourish for sure.
My two cents.
Very interested in other’s opinions.
I’m not sure exactly what that means, what does that look like in the database?
If a user has many posts, how would that be a one to one relationship?
From what I understand I personally don’t think you should have a list of posts or ‘hearted’ list of posts on the user data type as a list. The list can’t exceed 10K (Bubble restriction) and once you go past 50-100 items, I’ve experienced that a 1:1 relationship is faster at retrieving than the list of things approach.
See my question above, how does that work/look like? Can you give a simple example of the data structure that would replace what I did?
User
Bio (text)
Post
User (user)
Inverse 1:1
To find the post you search for it using the user. The user does not see the post this is why is inversed but 1:1 from the standpoint of the post.
Sorry if the above is oversimplified. Just replying to your question.
Thanks for clarifying, now I understand what you mean.
But wouldn’t that mean I now how to query the entire database for all posts and filter for ones with that user ID?
Also there are parts that can’t be 1:1, like followers. A user follows and is followed by multiple other users, how would that work?
Hey @cmarchan
In what terms did you find Xano awesome? I’m exploring it at the minute.
How do you think it will perform on duplicating an invoice with each lines 30 times with a click of a button?
Thanks a lot!
I know you said don’t suggest a wrapped bubble app as an option but may I ask why?
With BDK tools you can run native actions and there are multi billion dollar companies that actually use wrapped versions of their websites as mobile apps (ex: cargurus).
No, you would search the entire database for all posts and constrain by the ones with the User ID, which works faster than list of things, especially when the list of things gets beyond 50-100 items.
Well I’m still unclear on how it all can be 1:1, like the example I gave of following and followers.
One method could be to create a “follow”:
Follow
Follower user unique ID (text)
Followed user unique ID (text)
or
Follow
Follower (user)
Followed (user)
The first one should be faster because it is lighter since the user object may hold additional fields
I do not claim to have all the answers. This is just a suggestion 
I know it’s different db design methodologies, i just needed it more fleshed out as I wasn’t even sure how it could look like, not how it should look like.
Thanks!
I also do not have all the answers, and I think I will have to reach out to Bubble support to get a clear and unambiguous answer on this. From my understanding the relation to an object itself, is no ‘heavier’ than using a text based field storing the unique ID…the reason being as I understand, is that the way the related object field is actually stored as regards to ‘weight’ or data load is just the unique ID anyway.
I think when we are doing a search for something that has a related field to another object, we are not retrieving all of the fields of the related object and thus ‘bloating’ the data load. I think Bubble handles this the same way they do when we have a URL parameter whose value is a unique ID of a data type and when we extract that URL parameter and indicate the type of data it is, we are not searching (this is what they do for slugs basically).
Please do share your findings on the consult with Bubble
This certainly is pivotal to app building
@petter @lottemint.md @adamhholmes @mikeloc any thoughts on whether Bubble brings-in just the id of a related object … or does it bring all of its fields onto the page?
Hey!
I use the Browser’s console network tab for checking such things.
For instance, we have tables Article and ArticleStuff:
Populating some records to these:
Making a repeating group search for the created articles:
So, we can see that the thing type field is returned as a string:
But, if you try to access at least one field of the thing field:
The system makes an extra search:
I hope that’s something you’ve been asking for. 
Hey Sergei @lottemint.md !
Darn!!!
I appreciate this huge gold nugget response! Brings about the requested guidance and beyond!
So … when we use an object’s field we are actually asking for a subsequent search to be done. Huge!!!
Now I understand why this topic has been interpreted in various ways.
So … one way to “force” for fields not be “searched for” and thus made “lighter” is to limit the ability of the developer to use them. This is when using the unique id as a text comes in. You make a “forced” search when needed! … Not inadvertently perform secondary searches by using fields in constraints or other instances.
If you want you can still use the object to obtain it as a string without loading further fields from it … but you must remember that any time you use it’s fields … you are bringing it in … or “them” in …
Many thanks again! 
