I recently attended the APEX World event “A Deep Dive into Low-Code”. I have had this question for a while: “Is Application Express a low-code development tool?”

My experience says: It can be, for small applications. However, with larger applications, sooner or later you will need to get your hands dirty. And that’s OK, because I think this is one of the strenghts of APEX: there are many ready-to-use functionalities and declarative solutions, while allowing you to easily integrate your own solutions.

Architecturally, there are many options to setup an APEX environment, but I like to keep it simple: first, there is the APEX engine is in the database, which therefore has all the strengths and weaknesses of Oracle; second, there is an Application server such as ORDS, which comes standard with an APEX installation; and then there is the front end: the browser. Although contested by some, I think the best project architecture has the data layer and business logic in the database and files for CSS/JS, like packages for PL/SQL. This way, the APEX layer will be very thin, it is just there to generate the webpage and to call functionality from the database.

“Is APEX the best option there is? Probably not, but it can be the best solution for your problem.”

APEX is driven by its developers’ community. For me, APEX came into maturity when the plugins became easier to develop, build and integrate. Suddenly, solutions for frequent customer requests were built and shared. Moreover, the best and most useful plugins are being integrated in APEX as standard functionality. And not just plugins. For example, there was a longtime request to be able to open an APEX application in multiple browser tabs. Although technically complicated, the APEX team came with a solution that is safe and simple to implement.

The introduction of the Universal Theme was a breakthrough. Not only its responsiveness on different screen sizes was a radiacal improvement, but the possibility to customize it without actually changing it was too. Through Template Options (predefined or your own) you can change the appearance of a page just with CSS, which may not seem very important. But what is important is that by not modifying the templates when installing a new APEX version, these templates can be migrated, taking full advantage of the hard work put into the new version of the templates. For example, in APEX 18.1, some features like items and checkboxes have a new look that looks really cool.

There is another aspect of applications that I was not fully aware of until a while ago and that is accessibility. One of the theme styles (and hopefully soon also the others) is tested using only the keyboard or Freedom Scientific’s screen reader JAWS, but it is also in compliance with the Web Content Accessibility Guidelines (WCAG) Level A standard.

And is not only the CCS but also the JavaScript that contributes to the user experience. APEX comes with its own JS library and with the latest version of the JQuery library. Dynamic Actions are the APEX’s native place to define you own front-end events, and it is one of the places where, I think, the most dangers are coming from. It is the place where you can decide to stay close to APEX or to has the freedom to go wild implementing own solutions. There is nothing wrong with doing the latter, and as a matter of fact, I do it often. But it has to be done responsibly, with a knowledge and understanding of JavaScript/JQuery. And you also have to take care of securing the application and the data behind it.

In my opinion, for an application to have a future it has to be able to communicate with other systems, and webservices are a way not just a hype. Maybe not completely matured and maybe not the best tool to do it, but the latest APEX version (in combination with ORDS) offers the possibility to create webservices declaratively and even to create pages based on REST requests.

It is often said that APEX is not suited for large applications with a large team of developers. I respectfully disagree. If building in the right way (with the business layer in the database and a thin APEX layer), one can use a Version Management System and locking to avoid conflicts. It is also possible to lock pages internally, which makes this problem much smaller than in other development tools. And is the application too large and difficult to release? You might want to consider another application architecture, one where the project is split into multiple applications.

How far can you reach with APEX?
From my experience, some of the client requirements can be met with low code solutions, and most of the requirements can be met with a partial knowledge of SQL, PL/SQL, CCS, and JavaScript/JQuery. And then there are solutions that require creative thinking. For example, one time we were required to build a dashboard displaying “Things to be done”. That would not be very difficult, except that some “Things to be done” were more important than other “Things to be done”, and the users had to be able to decide which sections they wanted to see first and which sections had to be displayed lower on the page, and these settings had to be remembered until they decided otherwise.

Another time, the page was so complex that the only real solution was to implement iframes. Iframes are not supported by APEX – and I can understand why that would be challenging. However, we used many APEX components and we transformed a complex page into multiple simple pages, with no implication for the user except a better performance and better general experience. I already mentioned the possibility to create webservices, but pretty much every API with REST/SOAP requests can be implemented in APEX: we have done it with Google Mail, Citrix, SAP and other, smaller, custom API’s. And not only APEX, but Oracle is making efforts in this direction as well, for example in creating or parsing JSON objects.

It seems very appealing, but what are the limitations and shortcomings of APEX?
A lot of these come from the same corner as its strengths: Oracle. Many agree that PL/SQL is not the fastest language around. The generation of HTML using templates, as easy, reliable and generic as it is, is built with PL/SQL, which makes it slower than for example SQL or, outside Oracle, Java or C++. And webservices are easy to make and secure with, for example, ORDS and OAuth2. However, when it comes to SSL certificates, many get in trouble because Oracle offers a place to install the certificates, a way to give them their location, and a useless error when the call cannot be completed because of the SSL certificate. Also, when it comes to continuous release, there are ways to do it, but it does require other tools and technologies. Automated testing falls into the same category.

Is APEX the best option there is?
Probably not, but it can be the best solution to your problem. Is it low code? Maybe not, but as a development tool is easy to learn, basic functionality can be built very quickly, and you have the possibility to customize according to the requirements. It has an active developers’ community where support and solutions can be found.

So, how far can you go with APEX? As far you want to go… within its limitations.