Building a complex app from Azure Services using low/no-code tools

?Low/No code development can be a thing of beauty! It can also be just as complicated as creating a solution through code. When you build solutions using low/no code tools you are making a trade-off between the number of pre-built components and design autonomy. The trick is to know when that trade-off will pay you back in terms of speed of development and maintainability. In this post I share a recent experience of mine, where I developed a moderately complex solution using Microsoft's Power Automate, Service Bus, SharePoint, Teams, and Log Analytics services, along with the SendGrid email service. What I learned surprised me.

The case for low/no code

Simply put, the promise of low/no code is that you can do more in less time and with less knowledge of the underlying processes. When used correctly I agree that you can do more with less, but I disagree with the notion that you don't need to understand the underlying processes - at least at a conceptual level. I have seen plenty of poorly designed flows in Power Automate and Logic Apps (many I created myself) and can attest that poor design is just as much a problem in the low/no code environment as with traditional programming. These caveats aside, however, when you know what you're doing you can definitely deliver solutions faster with low/no code tools.

Solution components

The problem before me was to create a general-purpose messaging platform that would send either emails or Teams notifications to one or more individuals using a template and keep a log of the results. The solution would look something like this:

The general idea is that any application could post a message to a Service Bus queue, which was monitored by a Power Automate flow. When a new message arrives in the queue, the flow extracts its data, finds the requested template in a SharePoint library, merges the data from the request with the template, and depending on the nature of the request sends an email or posts a Teams message to one or more users or to a Teams channel. After the message has been sent it is logged to Log Analytics, from which Power BI produces reports. Not a single line of code is involved.

Benefits and challenges of this approach

The benefits were many. By using pre-built services like Service Bus, I didn't need a database or some other persisted storage to manage requests. Power Automate provides out-of-the-box connectors for Service Bus, Log Analytics, SharePoint, and SendGrid so I didn't need to read-up on their various APIs. In addition, Power Automate can trigger a flow whenever a new message arrives in a Service Bus queue, so I didn't need to create a looping process to "listen" for new messages.?

But there were some challenges. Perhaps the most challenging was that each Azure service has subtly different authentication mechanisms. Some require an identity principal like SharePoint or Teams - for that I needed a service account. Others can use application identities, such as Service Bus. While others work best with a key/secret pair. Sorting those out can be a bit of a headache.?

One big advantage I see with this service-oriented architecture is that each of the services provides some level of logging that helps you see what's going on. On the other hand, your debugging gets spread out across all the services, so you definitely are hopping between browser windows when trying to track down what the app is doing. This is quite different than a fully coded approach, where all you need to do is step through the debugger in a linear fashion to see what the application is doing.

Key takeaways?

Here are a few things I'd suggest based on my experience building this app:

1. Don't scrimp on design time - spend just as much time designing as you would with a traditional app. You'll be glad you did.
2. Get all the permissions, credentials, keys, etc. you'll need up-front, so you don't have to stop in the middle of development and wait for those - this is especially important if you work in an organization (as I do) where you rely on others to grant permissions to production resources.
3. Test your individual components before assembling them. I used Postman extensively to make service calls, verify permissions, and debug individual components.
4. Although it might be counter-intuitive, do not get discouraged if your project takes just as long as a coded approach might. The payback may not always be in terms of development time, but rather in terms of lifetime maintenance cost and in the stability of the finished solution.

Conclusion

While low/no-code tools have been marketed as a way for end-users or less skilled developers to create robust solutions, the truth is that they don't reduce the skill required to create enterprise-grade solutions. What they do is allow an experienced developer to build solutions from prefabricated components (sometimes) more quickly, but more importantly in a more stable and sustainable way. Regardless of the services platform you use (e.g. Microsoft Azure, Google Cloud, or Amazon Web Services) with practice you can create enterprise-grade solutions that rival anything you could build using more traditional programming tools.