Expand all | Collapse all

QuickBase Architecture Considerations

QuickBaseCoach Dev./Training05-10-2017 23:17

  • 1.  QuickBase Architecture Considerations

    Posted 05-10-2017 02:42
    So, I'm new to QuickBase, and I'm trying to understand the true intent of this 'codeless' application.  

    I have a complex set of data interactions that I must control, and I'm wondering if I should try to design all of my concerns so that they fit under the scope of one master application with many tables and links, or is QuickBase set up in a way that promotes the creation of multiple small apps, that are tied together into one network through many app links?

    Can anyone point me to some information that might help me down my path of discovery?

    Sorry to be brief, but I didn't want to bother anyone with unnecessary information.  I'm happy to provide details or examples of my use-case if necessary.  

    Thanks in advance,


  • 2.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 02:52
    This sounds like 1 app to me with many tables and relationships. I have apps with 50 tables. If the app is basically doing one function which is highly integrated and the users are all doing a part if that integrated process, then I suggest 1app.

    While you can have what are called cross app relationships, meaning that one app can look up data from another apps table, typically you would only do that when the other app is really doing a separate function, but you corrrectly don't want to manually duplicate information like a customer list or item list.

  • 3.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 02:54
    In my experience It is much easier and easier to maintain in one application.  When you have things in different apps, you have to have the users in all apps, and generally speaking it makes it harder to keep track of.

    I've built apps that have 40+ tables for very complex workflows and information.

    I'm curious, what is your use case or industry that you are trying to solve this for?

  • 4.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:21
    My company is a non-profit organization that has members located throughout my state.  These groups (roughly 2000) are organized in a variety of ways.  One primary aspect of my app or apps will be to organize these groups and their constituents and properties in an easily accessible way to my group's employees or other internal actors.

    The other primary concern involves the variety of stakeholders we interact with in order to conduct business.  These groups (roughly 20) all have initiatives they require we meet in order to satisfy their concerns.  We represent our ability to meet these requirements through a variety of reports that track our involvement with our member groups.  Many of these objectives are redundant, but all stakeholders have their own scope or perspective concerning the work we do, i.e. - 'Create Jobs', 'Educate', 'Conserve', 'Train', etc.. so our reports must be tailored to any given objective.

    So, I have quite a task in front of me, and QuickBase is the tool I was given.  I'm new at the moment, but I'm sure if I pull this off, I'll be QuickBase GrandMaster, or whatever similar title they have.  :)

    I dunno if this helps, but I felt inclined to share.

    Thanks again,


  • 5.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:42
    You'll just want to map out the process and possibly built some simple test apss to get the hang of things before you dive head long into it. 

    Maybe pick one part of the business and solve for that first, then expand from there.

    p.s. have you ever been to a Biscuit game?  I used to play for them back in the day.

  • 6.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:50
    Are you serious?!  Absolutely!  The fireworks over the river are one of m'kids (and, admittedly, my) favorite things!  


    What a small world.  Well, I guess.  I haven't looked at your profile to see where you are.  Maybe you're still near?

    Also,  I will definitely start small. Thank you for the advice.  



  • 7.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:53
    I retired last summer and moved to Utah, but Montgomery will always have a spot for me.  Who knows when I'll make it back there.


  • 8.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:58
    This was in 2014

  • 9.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 04:02
    Well the kids and I probably did a little yelling for you (or at you) back in the day.  ;)

    This is just great!  I can't wait to show the kids in the AM.  I can't imagine how fun it was being down on the diamond.

    Pretty crazy running into you this way. 


  • 10.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 04:34

    Here are the kids at one game in 2013. Perhaps you were there. ;)


  • 11.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:07
    Can you tell me what issues you've encountered with apps containing 40+ tables?  If QuickBase can handle it, I'm game, but I am leary of a monolithic app, with logic becoming so complex that you can't fix anything without breaking everything else.

    On the other hand, I'm not trying to add undue complexity to my life.  If the multiple-app-structure is more expensive and less useful, than I'll take my chances with the monolith. 

    I'm just trying to understand the abilities of QuickBase and the ramifications of my decisions before I commit to them, but I'm (of course) in a hurry to get in and complete some objectives.



  • 12.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:29
    If you have complex logic then you have complex logic.

    Breaking up that Logic into multiple applications just makes it even more complicated to figure out what is connected to what. . Hence one app is better than multiple apps.

  • 13.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:36
    Thanks for your time.  I believe you are right.  I guess the only reason to go the microservice route vs monolithic route would be scalability, and I don't think I'll have that concern on this venture. (famous last words..)  

    I'm going the monolithic way.  I'll be happy to let you know how it goes once I'm fully-involved.  Also, I'm sure I'll have many questions along the way.

    Thank you again for taking time to help us newbies along.



  • 14.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 03:41
    QuickBase will be able to scale to meet the needs of your type of data and we are here to help you get your relationships set up. There are several of us on the Forum who revel in complicated Relationships. .

  • 15.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 22:42
    We run our whole company (a website development and Internet marketing firm) on one single app with 71 tables and growing. Everything is connected to everything. Honestly, I don't know why anyone would want to create multiple "apps" when everything needs to be integrated. That's how you cut through departmental silos. QuickBase is totally fine in helping you encapsulate, encode and manage the complexities of your business logic. Honestly, the only thing I've run into that is hard is the arbitrary but hard limit of a single table being limited to 500 mb. But that would apply regardless of whether you architected your app as one or many. I think you will have it be ultimately more complex if you have multiple apps.

  • 16.  RE: QuickBase Architecture Considerations

    Posted 05-10-2017 23:17
    I agree!

  • 17.  RE: QuickBase Architecture Considerations

    Posted 05-15-2017 12:30
    I've had applications span 150+ tables and 6,000+ fields. From a performance standpoint, Quick Base will have more challenges with complexity than size. For example, one table with 400mb of data could in theory load faster than a table with 40mb of table that has 20 looping relationships all driving the same formula.

    I mostly agree with the sentiments here about putting things in one app but there are a few things on the other side of the fence:
    1. Change management. If the apps were separate and you had access to the Quick Base sandbox, it could in theory be more simplistic to manage changes and deployments. The sandbox is limited but can be useful. Separating the apps, even without the sandbox might make it easier for you to manage changes, expectations, requests, etc.
    2. Security. Depending on role configuration, you might find it easier to separate apps to ensure segregation of data. For example, an HR app should almost always be separate given the sensitive nature. When you add a role or a table in the main app, you run the risk of Quick Base automatically granting some permissions in the name of simplicity. This is one of the risks associated with the use of everyone on the internet - you can accidentally open up a whole lot of data.
    Cross-apps also force the apps on the same cluster in Quick Base land, so that is something to consider. Usually not a big deal unless you get into huge apps. Table-to-table imports do the same thing - but only temporarily. This cluster-forcing just limits Quick Base's ability to automatically move apps around based on performance. Where this becomes a problem is when you have huge apps all connected. I've seen an environment with 46 cross apps when the whole chain was considered, meaning the mothership connected something like 6 apps, then each of those had a child and some had another child. That created serious performance issues. In these cases, you might want to consider duplicating the data to avoid the cross app which sounds bad, but might be worth the tradeoff.

    In the end, Quick Base doesn't really have any "modules", so the distinction of monolith vs microservices is limited. It is really just all fields and tables. Meaning, if you have 4 tables, 5 relationships and 30 fields all tied to your inventory calculations, nothing truly in Quick Base groups those together into a module or function.

    Where you really want to be careful is in enhancements (JavaScript, Zapier, Workato, .NET, PHP...) - that is where SOA vs Monolith comes into play.