I’ve had multiple conversations over the past few years that were variations on a theme. They generally go something along the lines of these…
- “We’re starting a new project and we plan to use APEX. How are we going to keep users from getting into the database and mucking with stuff?”
- “We’re starting a new project and we plan to use APEX. Normally we do authentication and authorization based off our AD users and groups, but we’ll have to change that, right?”
- “We’re starting a new project and we plan to use APEX. Do we still need to go through our regular project management process?”
- “We’re starting a new project and plan to use APEX. Do we still need to have approvals for data access?
The answer to all of these is questions is – APEX doesn’t change any of the rules of how databases work, nor does it change how our company manages things. APEX is new to these developers and there will, of course, be new methods and new syntax to be learned. At the core though, what ever it is that is being developed is still an application using an Oracle database. Oracle is still Oracle, the data is still data, and the compliance rules are still required.
Frequently there is some push back “Certainly APEX will change something” and they are right; but my response to that is “Yes, of course; but you didn’t really ask about APEX. Remove APEX from your question and insert python, or java, or c#, or some framework. Would you still ask those questions?”
For data security you’re still going to have data in tables with grants and roles determine which users can see or touch the data. Some objects will probably be insulated behind views or packages so there won’t be any direct access. All of Oracle’s row level security and auditing features are available. Encryption and audit vault if needed are also possible. These are features of any database application – APEX does not, in any way, take these away. Nor does it implement them for you.
For authentication and authorization, APEX does have some LDAP support built in but it also allows you to build your own custom functions. So, just as you might invoke some library to integrate with your Active Directory, you might also write your own or augment the existing tools with custom functionality. APEX, once again, like other development frameworks has common functionality available but also allows expansion, just like others.
For project management, approvals, and other corporate standards – no third-party tool would exempt a development team from the rules. In the other direction, APEX doesn’t know any of our rules so it can’t automatically implement them either. Doing stuff with Node.js is pretty cool too, or maybe you’re using an awesome new CSS and JavaScript framework; but, like APEX, using them neither negates nor enforces the company rules on their own.
I try to promote APEX and I’m happy to see its adoption. I think it makes doing many of the right things easily and efficiently; but if you use it improperly you can create more problems for yourself and others.
Like other tools – if you use it properly you can build amazing things.
APEX is a tool. It is not special… and that’s exactly why I like it.