HarrisonHersch
8 years agoQrew Member
Re: QuickBase Architecture Considerations
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:
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.
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:
- 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.
- 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.
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.