Part 1: Good and bad practices at APEX! Analysis and PoC
This is a series of few articles covering good and bad practices at each stage of the application lifecycle
Part 1: analysis
Part 2: development
Part 3: release to production and beyond
First things first: Analysis
Is APEX suitable?
Is Oracle APEX a Good Choice?
When deciding on a platform, it’s essential to evaluate if Oracle APEX fits your application’s needs.
Strengths and Weaknesses
APEX offers many benefits, like low-code development and seamless database integration, but it’s important to consider its limitations to ensure it’s the right fit.
Oracle APEX offers a number of advantages that make it a powerful tool for developers. It provides a huge range of capabilities, supported by extensive resources such as blogs, videos, and publications. Features such as large-scale reporting with interactive charts, authorization at any level (regions, elements, and even columns), and built-in components enable fast and controlled implementations. With hundreds of out of the box solutions - such as reporting, charts, forms, emails, as well as less frequently used ones but also really helpful like approvals, workflows, or working copies - APEX enables developers to deliver efficient and scalable applications in a very short time!
APEX is FAST!
Development in oracle APEX can be very fast - applications can often be developed in a matter of hours, depending on complexity. A powerful example is when, during the Russian invasion of Ukraine, a small team of developers quickly created an APEX application in just two hours to replace an Excel-based workflow to help volunteers support refugees more effectively. While the benefits of APEX are well-known, it is equally important to recognize when it is not the right tool for a particular project and to make that decision if necessary.
But on the other hand, there are some downsides to technology...
While Oracle APEX is a powerful tool, it is important to approach its use wisely, balancing its strengths and limitations. Recommending APEX in every scenario without considering the drawbacks can lead to shortsighted decisions. For example, offline applications are a challenge because APEX relies heavily on a persistent database connection. Custom solutions and complex workarounds are required to make such applications functional.
Similarly, while it is possible to create single-page applications (SPAs), they require extensive customization via JavaScript, AJAX, and other non-standard approaches, which deviates from the multi-page APEX framework.
Specialized use cases, such as iOS navigation apps, also involve inefficient and resource-intensive development. Even for Progressive Web Apps (PWAs), the main problem remains: APEX is designed for environments with consistent database connectivity, and deviations can lead to suboptimal results.
Conclusion
Don't be afraid to speak openly about the disadvantages of a given technology, it shows your experience and professionalism!
Who is this app for?
The key is not to divide this discussion into pros and cons, but to focus on understanding the technology background of the future application owner. Many customers already use Oracle databases and are familiar with SQL, but often do not realize that they also have access to Oracle APEX as part of their existing setup.
Is Oracle there?
If your prospect relies on a non-Oracle database, it’s crucial to determine if they’re ready to move to the Oracle ecosystem. Understanding their current workflow is essential - let’s hope it’s not all Excel for a large user base. However, if their “database” is Excel, the solution is clear: build an APEX app as soon as possible!
Other (maybe create in APEX) Apps?
If we discover traces of Oracle in the client’s environment, it’s a good sign - we’re in familiar territory. From there, it’s worth investigating whether APEX is already in use. Look for any production applications created with APEX. If they exist, find out who developed them and whether any documentation is available to understand their setup and potential for further development.
Other developers or DBA’s?
It is important to get to know the DBAs on the client side, because working with them is inevitable. I had the opportunity to work with DBAs of two clients from other time zones, which allowed me to experience a different culture and working hours than I was used to. When it comes to working with DBAs, always approach the cooperation with kindness and understanding - it makes a significant difference.
Skills of team members
APEX developers are often multitaskers, handling everything from DBA tasks and schema creation to building applications, working with SQL, PL/SQL, frontend technologies like HTML, CSS, and JavaScript, web design, and RESTful web services. We manage the entire application lifecycle, from initial analysis to production maintenance. Often, when encountering APEX applications at a client’s site, they’re either outdated or built on old versions. It’s also essential to assess the technical knowledge of the client’s team - you might be pleasantly surprised or unpleasantly disappointed, so be prepared for either scenario.
Conclusion
Find out as much as you can about the client, the more we are able to learn at this stage, the easier it will be for us to collaborate further.
Costs, risks, benefits.
When assessing costs, it is important to consider both the development time and training time required to create and maintain a custom application. Additionally, the complexity of the application must be weighed against the business benefits it will bring. If the costs, complexity, and risks outweigh the potential benefits, it is a clear sign that APEX may not be the best choice for your scenario.
Work with app future owner (pros)
Workshops
If possible, conducting workshops with the client is an excellent idea. Remember, they will be the owners and users of the application, and it should serve their needs effectively for as long as possible. Workshops provide a valuable opportunity for developers to understand the application from the business owner’s perspective, helping to align development with their expectations and requirements.
Mockups
Ask the client if they have any mockups, page templates, or ideas about how even as a simple buttons and forms should look. Well-made mockups are highly appreciated by developers, as they provide clear guidance on what needs to be done and the desired final result. This clarity can significantly streamline the development process.
PoC - Proof of Concept
Creating a proof of concept (PoC) directly in APEX is an excellent idea. Focus on the layout - arranging items, reports, menus, and other elements - without implementing any logic. APEX allows you to quickly build these visual structures, providing immediate clarity and direction for the application. Don't have a client-side environment yet? No worries! apex.oracle.com will help you create a PoC for your client in a very short time! It will show you the speed and capabilities of creating applications from a clean slate.
Work with app future owner (cons)
No (client) idea
Sometimes the client has no clear idea of what they want to achieve, which can be both good and bad. On the positive side, it gives us the opportunity to suggest ideas and solutions based on our experience. However, the downside is that without a clear vision, the client may struggle to define their goals or determine if the application will deliver meaningful benefits.
Crazy ideas
On the other hand, the client might come up with amazing, yet sometimes complicated and unrealistic ideas. It’s hard to say which is worse - the lack of ideas or having too many. Our role is to guide them, showing that there are numerous brilliant, out-of-the-box solutions that can perfectly address their needs in a given situation.
Mockups (yes again …)
Mockups can also be a challenge when the client presents their own unique design ideas, including e.g. custom fonts. While it's possible to create custom appearances and functionalities in APEX, we also know that these customizations can lead to issues, especially during updates, which can complicate future maintenance and compatibility.
(Final) Conclusion of part 1 …
As you can see, even at the initial analysis stage, we can address many aspects that aren't necessarily related to development, setting the foundation for a smoother project progression.