How on earth do you do client and server-side architecture in Power Apps I hear you ask, well I'm talking LowCode hear so it's a little different. To get the same representation in Power Apps we have to leverage the platforms other tools, as you may now have guessed that's Power Automate.
With Power Apps there are 2 ways to connect to API's, directly through connectors in the app and connectors in a flow called by the app. There is very little difference in these connectors, as they are both authenticated to the logged in user, yet I often find Power Automate used when it adds no value. My reasoning is a skill gap in Power Apps (as Power Automate is NoCode vs Power Apps LowCode most people pick it up quicker).
Power App connectors should always be your default solution, but there are a few reasons why in some scenarios I would recommend server/flow side.
1. Additional Connectors
The most obvious one and the one that causes most people to delegate a connection to a flow. Some connectors simply don't work in Power Apps, the Azure Cosmos DB connector is a good example.
2. 202 Posts
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed.
As you can see a 202 code is when you delegate the process so it can run asynchronously. The app sends a request to the flow, the flow accepts it and continues, meanwhile the app can continue without waiting for the process to complete. This is a must for long process that can seriously degrade the user experience, sometimes making them think the app has frozen.
If the user needs to know the process has completed then you can add a job complete entry to a table/list, the app on a timer cycle can then periodically check the entry.
3. Filtered Permissions
This is an interesting one, and generally required by security.
As I said before apps and flows called by the app, use the logged in users' credentials. This means if you do an outlook action in the app then it does it to the user's outlook account. The problem you get is with how Microsoft has configured these connections permissions. Instead of being granular and giving these least privileges necessary, it forces the user to give highest possible privileges.
As an example, say you have an app that reads events in your calendar, the user doesn't just give read access to their calendar, but read, write, delete to emails, calendar, and contacts.
From a security point of view this often won't fly, so what's the solution? Well it turns out that not all flows called by the app have to use the user's credentials, you can leverage child flows power apps V2 connector to delegate to a service accounts credentials. I've written an article here explaining how (in this example it's to delegate access to a SharePoint list but its same principle for any connection).
since V2 of the power app connector a child flows is no longer needed
Using the server/flow side here means we can remove the requirement for the user to share unnecessary privileges. The caveat is that we don't access the users accounts, so we can't do things like add event to their calendar. But in most cases this isn't exactly necessary e.g.
- Add event to calendar - Service Account creates event and adds user
- Sends email - Service Account sends and cc's user
And if it is critical, like edit a file on your OneDrive, security generally will accept full privileges, it's all about the necessity of the privilege.
There are other scenarios and benefits for going flow e.g.
- Easier for multiple dev's to work on large projects
- Reusable logic across multiple apps
- Easier updates/debugging
but the reasons to go with Power App connectors when possible are abundant,
- Simpler deployments
- Generally quicker in app responses
- Simpler build
just to name a few.
As with all Power App development, a good design review and plan is critical. Understanding benefits for different solutions is key to creating a scalable and sustainable app. Additionally, a good code review to catch anything missed in the design review.
Top comments (0)