Over the past few posts, we’ve discussed several different architecture options for designing and maintaining PowerApps Solutions.
The question now becomes which one is the best that I should use every single time. Well, the beauty of architecture is that there are many different options to solve many different problems.
The easy answer is to say “It depends”, but if that was the answer for everything, there would be 17,000,000 different varieties of cars on the road so that doesn’t seem like a fair answer.
The All-In-One Solution
Nowadays, I only find myself using the All-In-One solution when I am prototyping code or doing some demos. Even starting small, I will rarely use this solution because I know at some point, the team is going to grow and we’re going to have to clean it up. In some cases, where the client has not technical team and no supporting resources, I will lean towards this solution if only for simplicity for them later on.
The Team and Feature-Based Solutions
I generally only leverage these solution types if I am already starting to work on a very large project where the team and product/features are highly distributed – i.e., the group is to the size that we we have a dedicated group to manage our core solutions that everyone builds upon. This ensures that the proper cadence is being taken to not “cross the streams” and inadvertently blow someone up.
The Component-Based Solution
You guessed it, the component based solution is my GOTO architecture for PowerApps solutions, mainly because of portability and cleaniness in implementation as well as enabling growth of the team over time.
I don’t typically consider myself a “Power Apps Configurator” but there are many people that are and they are great at it – from doing table design, business rules, client side interactions – having them build their own work in one solution (i.e., tables) and that runs at a different pace then say some of the programming, reporting or other areas of the system just makes sense and works within the construct of how the team is built.
I’ve never had a bad experience using this architecture and if anything, whenever we need to transition to another architecture (i.e., embed concepts from Feature or Team), it’s a great jumping-off point without a lot of conflict or confusion because it’s all well laid out and hasn’t locked us into anything.
In terms of flexibility and performance I find it’s integration with other systems prevents you have from “dragging” other components around.
Those are the architectures I have generally stuck to when working with clients over the years, and I have found them to be the most beneficial in defining and creating great work.