Forum Discussion
EvanMartinez
5 years agoModerator
Hi Mike,
I just wanted to chime in and share a few resources we have that touch base on Best Practices around sharing data across apps. It goes into the various options and what their pros and cons are, minus Pipelines which came out after this guide.
Sharing Data Across Quick Base Apps: Part 1 Cross App Relationships, Table to Table Imports, and Sync
Sharing Data Across Quick Base Apps: Part 2 Quick Base Actions, Webhooks, Automations, and 3rd Party Integrations.
Quick Base Memory Calculations
How we built Quick Base to scale and you can too!
As the other commenters have mentioned as an app gains in complexity and usage there is an increased chance of it needing more power and therefore having performance issues. Using methods like Sync, Automations, or Pipelines can help you avoid having apps directly connected but still be able to pass data back and forth and where possible it is a good best practice. In cases where I want to connect apps using these methods and still want to make it easy for users to move back and forth I have added buttons to the app dashboards that direct them to the right app/table to submit a form and buttons on the form to help them move back if needed. This way you can have a unified feeling experience but have ways to move data and users around. I hope those resources are helpful.
------------------------------
Evan Martinez
Community Marketing Manager
Quick Base
------------------------------
I just wanted to chime in and share a few resources we have that touch base on Best Practices around sharing data across apps. It goes into the various options and what their pros and cons are, minus Pipelines which came out after this guide.
Sharing Data Across Quick Base Apps: Part 1 Cross App Relationships, Table to Table Imports, and Sync
Sharing Data Across Quick Base Apps: Part 2 Quick Base Actions, Webhooks, Automations, and 3rd Party Integrations.
Quick Base Memory Calculations
How we built Quick Base to scale and you can too!
As the other commenters have mentioned as an app gains in complexity and usage there is an increased chance of it needing more power and therefore having performance issues. Using methods like Sync, Automations, or Pipelines can help you avoid having apps directly connected but still be able to pass data back and forth and where possible it is a good best practice. In cases where I want to connect apps using these methods and still want to make it easy for users to move back and forth I have added buttons to the app dashboards that direct them to the right app/table to submit a form and buttons on the form to help them move back if needed. This way you can have a unified feeling experience but have ways to move data and users around. I hope those resources are helpful.
------------------------------
Evan Martinez
Community Marketing Manager
Quick Base
------------------------------
SystemAdmin4
5 years agoQrew Member
Hi Evan
These resources are excellent - thanks for sharing.
Could I ask you to clarify a point you make in the first document referencing the table to table imports, specifically:
Is this basically saying that the depency and sharing of resources only occurs for the duration of the import (ie when it is actually executing the import)?
So in my use case, I refresh my slave tables over night when there is almost no usage on either my master or slave app, so the shared resources and any performance issue on either app would not be an issue.
Sorry if it seems like I'm basically asking the same question repeatedly, but I don't want to go rebuilding the way our apps work if I've simply misunderstood the nature of the dependency.
Thanks
David
------------------------------
dmlaycock2000 dmlaycock2000
------------------------------
These resources are excellent - thanks for sharing.
Could I ask you to clarify a point you make in the first document referencing the table to table imports, specifically:
"TTIs create dependencies between applications when executed. Executing TTIs result in the share of system resources. "
Is this basically saying that the depency and sharing of resources only occurs for the duration of the import (ie when it is actually executing the import)?
So in my use case, I refresh my slave tables over night when there is almost no usage on either my master or slave app, so the shared resources and any performance issue on either app would not be an issue.
Sorry if it seems like I'm basically asking the same question repeatedly, but I don't want to go rebuilding the way our apps work if I've simply misunderstood the nature of the dependency.
Thanks
David
------------------------------
dmlaycock2000 dmlaycock2000
------------------------------