Saturday, October 20, 2007

Thoughts on 4D's Forthcoming Flex Library

[Editorial Note: I was being pretty speculative when I first wrote this - it was based on piecing together a number of disconnected statements from Summit presentations. Well, I got a number of things wrong (see the comment below). I guess this is typical of the impression people get when things aren't fully explained. I've corrected myself below, but left things mostly in place.]

At the general Q&A session at 4D Summit, it was announced that there would be a 4D library for Adobe's Flex. In another session there was a demo of a Flex app using the library hitting 4D with user specified SQL (creating tables, no less) which made it incredibly clear just how powerful the Flex library will be.

I love Flex - I think it's one of the coolest tools out there for implementing Web 2.0 features. For one, it removes just about all of the browser compatibility issues - things "just work" in any browser with a Flash 9+ plugin (which is 90% of them and going up fairly quickly), and it lets you do just about everything you can do with Ajax, and you can implement it in a way that degrades gracefully for those without Flash 9. The only downside is that Flex-based apps may take longer to implement than the equivalent task in an Ajax framework like 4D's Ajax Framework.

If you're working on a public web site, you pretty much have to support IE6. Unless you have the budget of Google or Yahoo! and can deal with all the browser compatibility issues (current and future), Flex is a far better choice than Ajax. (On the other hand 4DAF is a great tool for many non-public applications.) Yes, it may take longer to do some things in Flex than it would in Ajax, but that's just the price of compatibility.

Now, it should be mentioned that you can connect to 4D from Flex now using web services - there's no need to wait for the 4D Flex library. This is what we did on a site we work on and it works really well (to see it in action, have Flash 9 installed in your browser, go to this page, and check out the pricing area - it's done in Flex and hits 4D via web services calls). [Incidentally, the lack of any mention of the current ability to connect to 4D via Flex was one of the deficiencies of the Summit (IMO).]

The Flex library that 4D is coming out with wasn't talked about in depth, but here's what I've cobbled together mostly through deduction...
  • The big thing it offers is accessing 4D v11 SQL using SQL calls, not web services. In certain cases this is a huge benefit.
  • It cannot be used to hit earlier versions of 4D (SOAP is your only option for v2003/v2004).
  • It cannot be used to connect directly to other SQL data sources.
  • It doesn't use ODBC, but rather does a TCP/IP connection to 4D and uses 4D's native SQL protocol (which is being released for others to use as well). This takes the ODBC layer out of the question, lets it run anywhere Flex can run, and should make it slightly faster than an ODBC connection.
  • Because it's connecting directly via SQL there's no code to install on the server (in contrast to 4DAF). This is probably its biggest strength and its biggest weakness (more below).
  • It's likely that there won't be any interface items in the library - they'd be redundant with Flex's interface elements which are already pretty complete.
The fact that it's a direct SQL connection means the requests don't go through On Web Authentication or any framework code as similar calls do in in 4DAF. This is what I think it's biggest weakness and it has several implications...
  1. There are serious authentication issues given the relatively simplistic authentication tools 4D is providing for SQL connections. (Correction: They say there will be the ability to trigger OWA or something like it.)
  2. All of your business logic and code is in Flex. I didn't hear of any stored procedure support in 4D's SQL engine (most likely due to the performance issues of using the 4D language), so that means your business logic is distributed. Whether this is good or bad depends on your perspective. (Correction: There will be stored procedure support, so your business logic can be on the server.)
  3. I didn't see any way presented at Summit for tracking SQL calls. (Correction: There will be SQL logging - now the question is how good is it.) In a web environment this means you could be putting a huge load on your server with no way to monitor it.
  4. If your web site is public, it means strangers are doing direct SQL calls to your database (within the parameters of your Flex code). (Correction: This is now much less of an issue given the other corrections above.)
That means just about every one of my reservations about the 4D Flex Library is being dealt with in one way or another (since my underlying premise was mistaken). The only thing I'll be watching for now is how small the library will be. Flex code can be rather huge, so hopefully there won't be a much of a performance/bandwidth penalty for using the Library... This is especially important where you want to add small bits of "flare" to a page and may want to have more than one Flex object on the page. Unlike Ajax, you can't (easily) share code between Flash/Flex objects on the same page, so each object has to be complete unto itself, which means you want the code to be as light as possible.

The fact that it's a direct SQL connection is also a good thing...
  1. It gives you a new and different way to access your data via Flex, which means more flexibility (no pun intended), which is always a good thing.
  2. Provided your SQL calls don't result in calls to triggers, they'll be handled completely with preemptive multitasking which means great performance and load handling.
So the bottom line is that the 4D Flex library is a bit of a mixed bag looks like it's pretty much exactly what it should be, but and I'm really happy to see 4D paying attention to Flex - that alone is a great leap forward.

Labels: , , , ,

Digg It!  Add to  Add to StumbleUpon  Add to Reddit  Add to Technorati  Add to Furl  Add to Netscape


christophe said...

First, let's say we enjoy your post that shows a real interest on what will be published.

Some précisions :

"It's likely that there won't be any interface items in the library - they'd be redundant with Flex's interface elements which are already pretty complete."

that is not true and was told in the keynote. The 4DFlexLib is architectured in layers and the upper layer will provide high-level components as a custom DataGrid, navigation buttons,...

"The fact that it's a direct SQL connection means the requests don't go through On Web Authentication"
There will be a mechanism of authentication triggering OWA. We will describe it later. We are very concerned about this security problem.

"I didn't hear of any stored procedure support in 4D's SQL engine"

That was announced too.
You can indeed call User Defined Functions written in 4D code from 4DFLexLib.

"I didn't see any way presented at Summit for tracking SQL calls."
Consider it was just a preview of what will be provided. A log system will be provided too.

Apart from these precisions, you're right, you can communicate with Flex through Web Service or just XML over HTTP. But, providing 4DFLexLib we just offer you the choice depending of what you need.

Monday, October 22, 2007 4:08:00 AM EDT  
Jay Harper said...

Thanks Christophe... That clears up a lot and makes the 4D Flex library more attractive. The demos of the Flex library were few and quick in nature, and hence much of what I was saying was speculative...

Monday, October 22, 2007 7:17:00 AM EDT  
christophe said...

Thanks for quickly correcting your article. You're quite right : the presentation was very short as the product will only be available in 4D WebPack 11.
It was more a way of showing the very interesting things the SQL protocol will allow us to do.

Every issues you raised was pretty accurate, but happily we already have the answer :-)

For calling 4D method, it's simple : each method that is marked as Available through SQL (see Sergiy'session on SQL) can indeed be called from 4DFlexLib once authenticated.

Monday, October 22, 2007 9:13:00 AM EDT  
Jay Harper said...

Interesting... I hadn't put two and two together to figure out that all the 4D language hooks supported by the SQL engine could be used in remote calls. Of course some of it, like variables, aren't appropriate remotely, but other aspects, like method calls, would be appropriate remotely.


Monday, October 22, 2007 10:45:00 AM EDT  

Post a Comment

Links to this post:

Create a Link

<< Home