I'm new to Azure Logic Apps and my team will be transitioning our integration layer to it soon. Although I've learned that Azure allows for inline JavaScript (or C#), the higher-ups seem to be favoring Liquid a lot. From what I've seen in the Liquid documentation, the syntax looks quite complex, and it appears somewhat limited—especially considering it needs a workaround for NOT statements and can't handle chained conditions like "if A and (not B)". This is quite different from what we used before with Mulesoft's Dataweave. Am I missing something due to my inexperience, or is inline JavaScript better suited for complex data transformations than Liquid? What are the advantages of using Liquid over inline JS? And can a JavaScript script be reused across multiple places, or can only a Liquid file be reused?
3 Answers
I wouldn't recommend relying solely on Logic Apps for this. Consider using containers or migrating to Azure Functions if you aim to stick with Microsoft's stack, especially if you've got a container platform already in place. My team is moving some of our functions to Kubernetes, which has helped us cut costs compared to past decisions.
Liquid can be reused across your Logic Apps, but inline scripts unfortunately can't be reused that easily. Logic Apps offer flexibility, and there isn’t a one-size-fits-all solution for transformations. Inline functions are generally more suited for smaller, specialized tasks rather than major data transformations. Liquid is great for straightforward structural changes (like JSON to XML), but if you have complex rules and logic, it can quickly become cumbersome. For that level of complexity, consider using the Logic Apps Data Mapper or pass the data to an Azure Function where you can unleash the full capabilities of .NET or Python. Just keep in mind, adding Azure Functions can complicate things, but it’s valuable for serious integration projects. Overall, use Liquid for simple tasks, the Data Mapper for structured ones, or opt for Azure Functions when you need more flexibility. Inlines aren't the best route for major workflows!
Got it! If I need something reusable and flexible, Azure Functions are the way to go. Thankfully, we have those in our stack. I appreciate the breakdown—it helps a lot!
No problem! It’s definitely worth experimenting with everything. You might stumble upon solutions that work best for your needs, especially since you have some Mulesoft experience to draw from.
If your goal is to prioritize a visual, low-code approach instead of diving deep into coding, then you might want to stick with the built-in features of Logic Apps. Check out the data transformation tools in Visual Studio Code—it could make your team's life easier and keep management happy. Why didn't you mention this option before?
While we are planning to use Azure Functions as well, we're migrating from Mulesoft, which is more visual low-code. Management believes Logic Apps will feel similar to Mulesoft, but we'll see how it unfolds. As for the data mapper, I was concerned it might not handle our complex mapping and transformation needs. Do you think it can manage those well?
The data mapper can handle basic mappings, but for more intricate transformations, you might need to rely on Azure Functions or do some custom scripting if it gets too complex.
That makes sense, but we’ll have to weigh what management decides. You've given me a lot to think about.