In the first part of our blog series about Low Code comparison between Oracle APEX and Microsoft Power apps we looked to what both companies have to offer in the Low Code market, their focus, and target audience. In this blog post we will talk about what each provide when creating database centric web applications.
To compare both tools we will evaluate how they perform when facing some basic challenges when creating a data centric application with the data and business logic stored in their respective databases, Oracle Database for Oracle APEX and SQL Server for Microsoft Power Apps. These three challenges are:
Oracle APEX runs in the database, accessing data and displaying it in the web browser is its specialty. In APEX you can leverage the whole power of SQL directly from APEX. The data will flow from the database to the web server running ORDS and from the ORDS webserver to the browser seamlessly. When developing an application, the developer does not need to worry about the data access layer, only about writing the SQL and what to do with the data. The developer can use their database skills and does not need to learn a new programming language or syntax to retrieve information from the database.
Microsoft Power Apps allows the developer to query the database using a set of functions and expressions, then later Power apps translates to SQL and executes the query in the database. You are not able to leverage the whole power of SQL directly from Power apps because you need to use another abstraction on top of SQL to query the data. Sometimes the function you need cannot be delegated. This means it will not run in SQL Server, and it will run in the client with a limit of how many records it can process. You will need to apply workarounds like creating views to pass the limitations.
The problems before-mentioned are related to the fact that Power Apps is not aim specifically to database developers but to citizen developers (I talked about this in the first part of my blog series). Power Apps offers great support for SQL Server but because it is not the main use-case for it, you will find that there are still details to polish when fetching data from the database.
Microsoft Power Apps does not support calling T-SQL (Transaction language used in SQL Server) procedures directly. The developer must use another tool which is part of the Power Platform named ‘Power Automate’. You need to define a flow and after that, call the flow in any place of the application where we need to execute the stored procedure. A few disadvantages of this approach is the amount of clicks required to define a flow and the billing schema which is different to what a developer is familiar with. Power Automate gives you a range of flow executions - every time you called a flow, one execution is consumed. When you run out of executions you need to buy more. They are not expensive but thinking that every time a user clicks a button, they are running out of credits is a bit uncomfortable.
The same freedom applies to CSS. You can create CSS style sheets and include them with your application to change bits of the looks and feel, or if you want a whole different look, you can even create your own themes.
As we see in this post, both tools allow us to create applications and accessing the database resources, but they perform differently on this. A different approach could have been taken for this evaluation, but these covered are some of the main challenges a developer faces when creating a professional database centric web application.
APEX’s main goal is facilitating the creation of database centric web applications and it does a wonderful job, when creating an application. The logic and the data are there next to the framework in the database, this makes the developing experience easy and efficient. Power apps in the other hand does not performance so well here due the fact that creating web applications on top of the SQL Server database and provide flexibility to professional developers it is not its main goal. Its goal is to give power to non-professionals developers to create apps without technical knowledge, and it performs fantastically on that, but this feature is a trade-off, and the professional developer can feel its repercussions from day one when working with the tool.
Author: Alexis Galdamez
Job Title: Development Consultant
Bio: Alexis is a Development Consultant at DSP-Explorer. Alexis has developed plenty of mission critical applications for the financial sector.
He is passionate about Web technologies and Oracle APEX and utilises them to provide to the customers a high-quality software solution.