Newbie looking for help on the best application architecture for a complex app

  • 0
  • 1
  • Question
  • Updated 1 month ago
  • In Progress
Hello, I am very new to Quick Base and playing with the trial.  While under the trial I am most certainly not going to fully develop this app, but my hope is that I can find a platform in a way to make an ERP system for my company.  Basically a hybrid of an architectural firm and contractor in one so we need to manage projects from design through opening day.  Many phases, many deliverables, etc.  One of my goals is to take what is now independent systems and combine into one:

Project Management Software
CRM
Expense Tracking
Communication Tools
File Storage (for project related material) 
Etc.


So my question is do I develop all of this one application or will that be cumbersome?  Should i build a Contact Manager App, an Opportunity Manager App, a Project Management App and share data or build all under one master application?  

The architecture of Quick Base seams to support individual apps, but most people through forum seem to say one big app.

Currently we are 50 employees and expecting to go through a nice growth period.  But we have a long time until we are in the hundreds count (although certainly hope to get their one day!)

Thanks in advance

Photo of Jay White

Jay White

  • 130 Points 100 badge 2x thumb

Posted 1 month ago

  • 0
  • 1
It's hard to give a blanket answer. Everyone is different in how they want their organization to work. You could certainly build one big app - and you'd be just fine. You could also build a 'hub and spoke' idea, where you have different apps that are all isolated into smaller chunks/specific purposes - and then you use Quick Base syncs or automations to make them all talk to one another so it still acts like one big system. 

The nice part of one big app is that it's all in one place. No one has to worry about 'where' some information might be or where they have to go for it, its just in one place etc. The backdrop to that is that you have everything going on in one place, so you have to be more careful with development as your changes might have big impacts once you go to production. 

The advantage of having smaller apps - is that it reduces some of the complexity, especially when it comes to user management. If you think about a true ERP - you'll have 100 people with generic or specific job functions. Since each would be siloed - some people could be in some apps but not others. With one big app - you have to be constantly checking and re-checking permissions - and you end up with a big list of roles to account for people who have abnormal job functions or are kind of floaters and just do a lot of things. 

Others on this forum may have a different answer, but personally, I would suggest segmenting it all out. The development lifecycle and user management controls of having different apps makes managing everything easier in the long run. Especially if you're planning for growth - going in with the hub-and-spoke mindset will help in later adoption for 'simple' or one-off apps that you can put together quickly that may not be part of your true ERP system, but can make a difference for small teams. If everyone is used to smaller, more specific apps, their adoption is usually better.


Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base
Photo of Jay White

Jay White

  • 130 Points 100 badge 2x thumb
Thanks Chayce,

I really do buy into the simplicity of future development if nothing else.  For example one major component of the app is going to be to maintain a database of contacts, the contact manager.  That seems to me like it would be a fairly simple system to quickly build out and keeping it isolated could be a real benefit.

I noticed your quick base sync note....  Would I need to sync data or can I just reference tables across apps?  Just wanted to ensure there is no significant performance loss in doing that.  It seems like that would work well on my end but not sure if that creates security issues or otherwise.
Photo of AustinK

AustinK

  • 1,004 Points 1k badge 2x thumb
One thing to keep in mind is depending on how you connect your apps it can cause them to actually share the same resources on the system. So while you may have split them out it doesn't matter because using one app will cause the other to run alongside it. Basically it looks like 2 apps but it is one large one.

There are many different ways to link your apps or the data within them and they all have their pros and cons. Do some research into the different methods and see which one makes the most sense for you. Some of the methods can even block your ability to sandbox an app, if that is important to you then you need to make sure you pick the right method. The link below is a great resource.

https://community.quickbase.com/quickbase/topics/sharing-data-across-quick-base-apps-part-1-cross-app-relationships-table-to-table-imports-and-sync
Photo of Jay White

Jay White

  • 130 Points 100 badge 2x thumb
Austin, so I did read this thread and it didnt quite help me all the way through.  The downside of cross application data I can see is managing the security as well as navigation.  I would think a single app is better in that regard.  However, the complexity of developing a single app will certainly be significant.

Are there any resources to speak to the downsides of a single large application?  We currently have 50 employees so for hte foreseeable future I cannot see us being concerned with 100+ employees.  Of course that could happen one day.  But I am not sure how taxing we really would be on a single application system.  Just not sure how to gauge that.
Jay - to provide more context - Quick Base loads your application when you open it. When you have cross-app relationships - Quick Base also then goes and loads those applications from memory too. So basically if you have 5 connected apps - and you open one - Quick Base sees that and loads all 5 for you regardless of which you opened so it operates in practice kind of like one big app as far as the work Quick base has to perform. So in regards to size and complexity - they're comparable. Based on 50 - 100 users - unless you're loading millions of records across your system - this probably won't be an issue. 

As for security - it's not really any different whether its in one app or several. You still have full control over what permissions users should or shouldn't have to certain fields/tables etc. As I mentioned before - my experience has been that when everyone is in a single app you end up creating one off roles and overly complicated permission sets to account for specific use cases where different people in similar roles in your company need to do specific / unique things in your system. Think about if you have resource data somewhere. If you break it into its own app - you can only allow certain people to view and manage it in that one app. But if its in the same app - you might have some users who all perform the same daily function - but also have some HR responsibilities and they're the only person on that team who can see the resource data. Things like that necessitate a broader role set in a single application. Certainly not a technical issue - just an annoyance to have to manage a lot of roles.

You're correct though - navigation can be a little odd if people don't always know where information is stored in some cases if everything isn't in the same app

Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base
You can certainly use cross-app relationships. By the time I realized I left that out of my answer - I was unable to edit. Its certainly a feature to use when setting up this kind of environment

Chayce Duncan | Technical Lead
(720) 739-1406 | chayceduncan@quandarycg.com
Quandary Knowledge Base
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 69,724 Points 50k badge 2x thumb
Another factor to consider is that when the user opens the app they will land on a dashboard. And of course they can only land on one dashboard for a given app. Yes they can have buttons to take them to different dashboards.

But if you have different apps it does mean that you may have a better opportunity to land users on a relevant dashboard. If you have users which use an app for servers quite different purposes then it’s hard to know what dashboard to land them on.
Photo of Jay White

Jay White

  • 130 Points 100 badge 2x thumb
Oh wow this is a great point and might point me in another direction.  I do want different users to have different initial views.  So I cannot configure it based on role?  It is based on app?

For example I want all users to see their tasks throughout the entire system, but I want Project Managers to see Project Status on their home page, Sales team to see sales pipeline and opportunities, designers to see project status for what they are working on etc.

I cannot create different dashboards based on roles?

Thanks again for the help, this is really great for getting started!
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 69,724 Points 50k badge 2x thumb
You can definitely assign Roles as to which dashboard they land on so that is no problem.

The point I was making it was that if a user is using an app for multiple quite different purposes then you have to decide which dashboard you’re going to land them on.

I guess it depends how pigeonholed you’re going to make your Roles. You don’t want to go to crazy on the number of Roles because it stars to make you crazy in assigning which Roles users belong in and maintaining these Roles.

.Roles come up in dynamic form rules and in permissions so you do not want an app that has 20 Roles.
Photo of QuickBaseCoach App Dev./Training

QuickBaseCoach App Dev./Training, Champion

  • 69,724 Points 50k badge 2x thumb
Roles also o control which tables the user sees in the table bar.

Often you try to design apps to not show users tables they need not be concerned with. But in the same way that you assign a user to see a particular dashboard, you also end up assigning a user to see a particular set of table bar icons.

So when a user is in a job perhaps at a higher level where they are needing to do multiple functions then it becomes impossible to control which table bar icons they will see.

When it comes to actual permissions, the system looks through all the rules and assigns the user at the most permissions possible.

But when it comes to The dashboard of course they can only land on one dashboard and similarly they will see the table bar icons for the highest priority role they are assigned to.

The Roles themselves can be dragged and dropped to sequence their priority and that is how the system desides which dashboard or which set of table icons to show for her user who is in multiple roles.

The roles themselves can be dragged and dropped to sequence their priority and that is how the system decides which dashboard or which set of table icons to show for a user who is in multiple Roles. .