An Introduction to Single Page Application Development in Oracle APEX

Some Background First

Web application development is now the No.1 development choice for new application development and Javascript is now the No.1 developer language. This can be attributed to the explosion of mobile devices and a global adoption of modern browsers and web standards.

 

The old issues of cross browser support and browser limitations are long behind us now paving the way for this meteoric rise. There is now an ever growing demand for more sophisticated and complex web applications to replace desktop applications or modernize legacy web applications. The building of these sophisticated applications introduced a new design approach, namely Single Page Applications (SPA).

 

Did you know that most modern desktop/mobile applications these days are actually SPA web applications that are then wrapped into a desktop application using tools like Electron or Cordova? How can you tell? Well you can’t really as they have the same behaviour characteristic of a native desktop application, the only telling sign is that they are way better looking thanks to CSS3. Skype and Visual Studio Code are two very well known and widely used tools. Did you know they are both built using Javascript and Electron? Haven’t the tables turned? The browser’s rendering engine really is the modern evolution of the JVM, write once deploy everywhere.

Isn’t it great to be a web developer?

Well “Yes” and “No”, due to an explosion of frameworks/tools/libraries, it makes choosing the right tools for your project(s) really hard. Many frameworks have come and gone whilst others have undergone complete rewrites. The reason is that web development is hard, and the job of making it easier is still being figured out, so everything is constantly evolving. We all use frameworks/tools/libraries as we want to make our jobs as easy as possible whilst giving our users the best possible application we can, within the budget and time constraints enforced on us. Low code and rapid application development frameworks are (becoming) more favourable, we just want one that will have longevity and be flexible enough to meet our current and future requirements that we’re not currently aware of. When building data centric applications, we personally think Oracle APEX fits that bill and we will explain why….

Web Application Design Patterns

Before we talk about APEX, first, let’s talk about web application design patterns in more detail. What are the web design approaches available to us? Well, there three main application design patterns that you can follow:

1. Multi-Page applications (MPA)
2. Single Page Applications (SPA)
3. Hybrid Approach that is a multi page variation of single page applications (MSPA)

Multi-Page Applications

MPA development is the traditional style of development that has existed since the birth of the internet, HTML pages are rendered via a browser GET request and the Saving form data is done via submitting the page using a POST request and then the browser re-rendering the page again.  This type of application is noticeably different to how a desktop application behaves. Could you imagine reloading your desktop application every time you made a change? The reason for this distinct difference is that the web was not designed for application development, application development was adapted to the design of the web. Applications following the MPA  design pattern, their HTML/Pages are traditionally generated on the server. Think ASP, PHP, JSP, or our personal favourite Oracle APEX.

 

Single-Page Applications

SPA development is a more modern approach that evolved around 11 years ago, quite some time after the introduction of XML HTTP Request (XHR/AJAX) around the year 2000. In an SPA, all necessary code – HTML, JavaScript, and CSS – is either retrieved with a single page load, or the appropriate resources are dynamically loaded and injected into the page as necessary, normally in response to some user interaction. This decreases the size of the requests, because instead of returning HTML and data combined, the server returns the raw data in JSON format and the browser merges this with an HTML template defined in a framework Javascript file. This means that the data is now separated from the presentation, allowing more reusability and flexibility. Your page is never POST(ed) and re-rendered. HTML content is dynamically injected into the page. Because of this avoidance of page reloading, an SPA application provides a much better user experience, increased performance, whilst maintaining screen context i.e. the user is not interrupted and does not lose their position on the page. Users of these applications are far more productive using this type of application (if it’s designed well, of course). So we can say that this type of application is suited for an application that is heavily used by its users or when fast access to a lot of related data is required.

 

Hybrid Approach

The hybrid approach is basically an application made up of multiple single page applications which are more likened to business modules. All interaction is done via AJAX, you just might switch your main viewing page to another when visiting a different part of the application. This helps reduce complexity and the footprint in the Browser/DOM. Could you imagine how much HTML would be rendered if E-Business suite was in one HTML document?

Client Vs Server

Lastly, whilst we finish the topic of design, there is one additional dimension which we should mention i.e. where are the web pages/code generated? Are they in static files or generated on the server? Generating HTML/Javascript on the server adds additional overhead on your server but allows for you to tailor the page design based on who the user is or what role they have or other changing variables/conditions. The downside to SPA applications is that they are made up of static files which require all conditional logic to be built-in and exposed on the client, resulting in a larger download requirement i.e. Javascript files are larger.

Did you know? The overhead of the APEX engine generating an APEX page is less than .02 of a second. There have been many discussions on the scalability of APEX, none better than the usage of Oracle itself mentioned here by Joel Kallman.

So what type of framework is APEX?

APEX was first designed in 1999, and by design is a multi page application (MPA) framework, since this was the only design pattern at the time. APEX is now almost 20 years old and has constantly evolved. It is a great low code development tool that allows us to create many types of web applications or websites declaratively. APEX, over the years, has included more and more feature rich functionality and adopted more and more AJAX capability i.e. partial page refresh which is the cornerstone of an SPA design but this capability is only limited to refreshing/filtering/saving reports or charts, or executing PLSQL Code. DML Forms require a page submit.

To explain the concept behind APEX in a bit more detail,  the applications we build with Oracle APEX are a set of HTML “Pages” which we navigate between to view data or submit to save the data. We design our applications with the concept of shared components that we define once to show up on each page so that it appears like a regular application. e.g. navigation menu, top toolbar etc. Pages have to reload every time a user performs a submit action to save a FORM, or when navigating to other another page. The following is a demo showing this multi-page concept and how disruptive it can be for the end user when switching between pages.

Link

Embed

Copy and paste this HTML code into your webpage to embed.

There are many types of applications or websites that APEX is suited for, but building a sophisticated Single Page Application is not possible “out of the box”, and thus limits you to building an MPA style application. The reason is that it was simply never designed for this purpose.

What are the main SPA frameworks?

There are many open source and commercial Javascript frameworks/libraries, and many have already come and gone, but the current main players are Vue, React JS, and Angular. The thing about using these frameworks is that you will actually end up using several libraries together like React JS and Redux, plus you will use build tools like Webpack, Grunt, Gulp, Browserify, Yeoman, Brunch and you’ll need Node.js as well. In our opinion it’s a complicated set of tools/libraries to learn for beginners compared to getting started with Oracle APEX.

Fortunately there are builders/IDEs that make SPA development easier which are using these frameworks underneath, such as Outsystems, Vaadin, Appery.io etc. Oracle has also introduced it’s own rival cloud service named Visual Builder Cloud Service (VBCS) built on top of its own Javascript framework Oracle JET (Javascript Extension Toolkit). The JET toolkit is a component library built on top of jQuery, jQuery UI, Knockout, and Require JS. The main characteristic of these builders is that they generate all the client side code and access the data via REST. By rendering everything client side they miss out on the benefits of serverside rendering. Client side rendering will mean that all the business logic and code must be downloaded to the client, whilst serverside only presents the generated HTML/CSS/Javascript, keeping the business logic more secure. Serverside rendering can also make showing customized displays much easier and reducing the clientside code footprint and complexity. So switching to a client side rendering approach does have some negatives.

Lastly, Javascript frameworks can be quite complicated to understand and learn, especially if your background is procedural programming like PLSQL. They use Object Orientated Programming (OOP) and design patterns like MVVM and MVC. If we consider APEX, it’s still thriving after almost 20 years and is a safe bet and a very productive and cost effective one as it’s simple to learn and use. The main reason for this simplicity is it’s declarative/low code, but also gives experienced developers full control. With APEX, everyone does not need to be an expert to get started and be productive.

Why would I want to build a Single Page Application in APEX?

APEX has many unique characteristics that you won’t find in any other framework. The following 6 characteristics sets it apart from every other development framework.

No.1: it runs within the Oracle Database, it’s at the same level of your data negating the need for a middle tier (Java need not apply). It’s perfect for data centric applications. You have full access to all database capability, and as of 18c the Oracle database packs a very long comprehensive set of features.

No.2: it’s meta data driven. Using SQL you can query everything that is designed on your page, or in your application, and you can do this at the point of page rendering or in every AJAX callback. You can even generate applications/pages/regions etc. using the same API’s the APEX builder uses to create your applications. The power and solution capability this gives you as a developer is not widely publicised and in our opinion is really underrated. There is no other development framework out there that has this design, APEX is truly unique!

No.3: is serverside generation, you can programatically output HTML, CSS and Javascript on the fly. This can be on page render or for AJAX callbacks. The benefits of server generated Javascript is not widely publicised either. Again it can reduce your client side foot print drastically as well as reducing client side coding complexity.

No.4: we can build visual appealing applications really fast with APEX, and they are super easy to deploy and maintain.Thanks to the universal theme and Theme Roller you can achieve a modern look and feel whilst adhering to corporate colour conventions. APEX has an extensive and mature PLSQL API, and also built-in REST support thanks to ORDS (Oracle REST Data Services). As shown in the earlier infographic, APEX is continually evolving and adding more and more features.

No.5: the low code design makes it easy for beginners to become productive, whilst it provides full control for experts. Comparing this to a SPA framework, it caters for a much broader range of developer skillsets, even business power users can learn APEX! Think of the cost savings in training and development.

No.6: licensing cost, yes Oracle is expensive especially when compared to the many open source databases and development tools out there, but if you don’t have a data foot print above 12G you can use 18c XE, ORDS, and APEX for free. You can also deploy this on cloud providers that can charge as little as $5 a month for hosting. So for people not using Oracle yet there is no entry barrier for adopting APEX. You could even use REST to access data in remote databases if your data requirement exceeds 12G. There are solutions to keeping costs to a minimum for small businesses. For everyone else already using the Oracle database it makes sense to use APEX, it’s really crazy if you don’t.

Lastly there’s also productivity apps that come with it like Quick SQL which is a markdown editor that can quickly build your data model and also generate a dummy dataset. You can also quickly build prototypes using APEX, comparable in time to using a wireframe tool. The difference being you have a functional application to preview, making the choice to use APEX that much easier.

What is a SPA user experience like?

If you are still wrapping your head around a single page application design style, let’s consider the APEX Page Designer introduced in 5.0. Whilst the APEX builder is not a single page application the Page Designer is modelled on a single page design style. Prior to APEX 5.0 there used to be a set of pages that were used to edit pages, regions, items, buttons etc. and you would find yourself navigating from page to page to page. This requires many clicks and page reloads to make your changes.

With the new page designer you can do everything on one page without interruption including saving Form data without reloading the page and keeping your screen context. It makes you somewhere along the lines of 5x more productive and in some cases like the multi-selection/editing capability of items/regions you can be 20x more productive. This is the type of performance benefit end users get from a SPA application over an MPA application. It’s this type of user experience and productivity benefits we want our customers to have in the applications we build. How much more efficiency can be gained and time and money saved when both developers and the application users are more productive using an SPA design over an MPA design? It can be quite a lot!

Can I build a single page application in APEX?

Using out of the box components you can build a single page application in APEX but everything would need to be created on one page. It literally is a single page application (minus the login page). You could argue that you can use dialogs to edit report content defined on this one page but from a technical point of view they are separate pages opened within an iframe within the dialog so they still mimic a single page design but are still using the MPA model since a page with a form is still POSTed back to the server. It’s a very limited design choice and is only really applicable for very small and simple SPA applications. If you start expanding on this iframe approach you will still end up hand crafting a lot of code (just look at the APEX dialog code).

So for the majority of applications you’re then back to building a multi-page application. For many developers this design pattern is fine with them and their customer base. For others, that want/need to build more sophisticated applications using the SPA design pattern, they’re going to have to learn a Javascript framework or look at an alternative GUI option e.g. Oracle’s Visual Builder Cloud Service, or Outsystems. However these frameworks are very different in terms of design because they are static and miss the whole dynamic nature of APEX, so you will be making tradeoffs.

If you are wanting to use APEX to build a sophisticated application, you are going to have to make some design trade-offs following the MPA design. These tradeoffs have an impact on end user productivity. You can however reduce theses trade-offs by implementing your own customizations, but your low code app starts to become a high code app that will take longer to build and maintain, which results in much higher costs. This results in the SPA frameworks looking like the better choice.

So what if you wanted to build a real SPA application in the same way you would a regular MPA application in APEX without losing productivity? Is it possible? The answer is: Yes you can!

Ok, so how can I build a complex Single Page Application in APEX?

APEX is extendible thanks to the plugin architecture. Using the APEX plugin architecture you will hook straight into the page designer and it’s no different to regular APEX development if you follow the same approach of providing support for conditions, authorizations, build options, read only etc. Currently the majority of APEX plugin developers are using it for single functionality use cases like nested reporting, multiple file upload, new LOV items etc. but you can take this a step further and plug-in an existing SPA Javascript framework and provide a reusable declarative set of regions, items, processes, and dynamic actions that are designed to work together to form a single page application design approach to building your application. This is what we did, building the FOEX Plugin Framework for Oracle APEX. Using our framework you can build a single page application in APEX using everything that APEX has to offer. You can choose either design style where it fits best, even within the same application.

This means that the complex applications that would have normally gone to other technology groups i.e. the Javascript, Java, .Net, Angular, React team, could now be “Built with ❤ using APEX“, and in much less time. Think of how much time could be saved on developing these complex applications when we use APEX? Here’s a recent quote from Joel Kallman on this exact subject:

Real customer quote today:

“We also produce more quality app dev output than any other team I’ve met in less time, with lower budget and fewer people – I have to be diplomatic when I point this out, lest any feathers be ruffled. The opportunities for us with #orclapex are vast.”

— Joel R. Kallman (@joelkallman) December 13, 2018

In summary if we look at the features for the design patterns available to us, it makes sense that we choose tools that are flexible and supports both our needs now and for the future. APEX, combined with FOEX ticks this box!

[easy-pricing-table id=”4597″]

Single Page Application Demo

Here is a short demo showing how Single Page Applications built with the FOEX plugin framework behave in APEX.

Link

Embed

Copy and paste this HTML code into your webpage to embed.

Coming Soon, Part 2

This is the first part in series of SPA blog posts we plan to publish, in our next post we will show you how you how easy it is to create a Single Page Application in APEX using FOEX  Plugin Framework. We will then explore the design concepts behind the FOEX i.e. how we integrated the Sencha Ext JS Javascript framework and made SPA development possible in APEX declaratively. We will also discuss what are the extra things (and Gotcha’s) we need to consider when designing applications using this style, as opposed to the traditional MPA style.