...

[BenHayat]

...

[Jaymer]

Sounds great.
You missed the Headless Aware presentation by Himanshu at last years conference.
I think you'd be interested in the direction that was going - my only issue with it was it took massive amounts of time (relatively speaking) to do the client-side programming (data was being retrieved via rest w/aware). Himanshu also has the luxury of having ace Java developers to do anything he needs w.r.t. handshaking/communication.

Maybe a nice lucrative direction for Vlad, instead of doing the visual "draw links between BOs to create references" new feature - MS Access had that 15+ years ago. Has anyone NOT purchased aware because it didn't visually connect tables? There's plenty other reasons why Corporate isn't going to adopt Aware and its not cause of that (talk to Ben & Talbot).

I know Vlad thinks he needs to keep stuff simple for the non-tech users, but something like an awesome Aware REST service would bring in far more revenue & users than are going to adopt because Aware is still "for the non-techies"... cause, as people have posted on the forum, they bought into the Aware is for non-techies and then realized they still needed to dig under the hood a bit.

true, the Tom Fords et. al. have resisted using external tools to get the job done (stored procs, node.JS, etc.).

[BenHayat]

...

[PointsWell]

I know Vlad thinks he needs to keep stuff simple for the non-tech users

If the product USP is simplicity of development then keeping stuff simple is the corporate strategy not an opinion.

The product is marketed on the basis of low-code in the vein of OutSystems and Mendix. Visual programming as a concept has been looked down upon for too long as being lesser than hand crafting. The world is now too complex for that to continue.

[ACDC]

Maybe a nice lucrative direction for Vlad, instead of doing the visual "draw links between BOs to create references" new feature - MS Access had that 15+ years ago.

I agree, I don't see myself ever using this feature, when I get down to design an app the design plays out in my head with me driving the configuration tool as it is. Having a fancy graphical GUI to drag a drop and create relationships is just "bling" , which is probably planned because other low code competitors have it .

Not only it opens Aware to a huge market, but we can also now build true native code in Flutter and use it with Aware back end.

Imagine that - this has been an educating read, thanks Ben. Its functionality like this that will drive adoption and let Aware developers leverage the move by corporates to low code development environments and compete head-on with some of the other well known low code players gaining traction in the corporate space

[tford]

true, the Tom Fords et. al. have resisted using external tools to get the job done (stored procs, node.JS, etc.).

This is somewhat true, but I don't really understand the relevance to this thread. Enlighten me.

[BLOMASKY]

Every app has 3 parts. The UI, The business logic and the data maintenance (from here on called the DB).

2 parts are easy to discuss,

1st, the UI will run on the client, and if Aware is being used as a REST server, then flutter or some other language will handle the UI. So lets ignore that for now.

2nd, the DB which is performing CRUD against a SQL database. Since you would have to write FIND, UPDATE and CREATE in Aware since the UI is being handled outside of aware. I believe it is not any more efficient to write these vs. CREATE, INSERT or UPDATES in SQL and in many cases much lower performance, since aware only works with one record at a time when updating / creating records. (for example, I have a quoting system, where when the user wants to convert a quote to an order, each quote can have up to 20 line items and aware will call 20 insert statements, instead of 1 if written in SQL)

Now, we get to the fun part. The business logic. Some should be handled on the client, i.e. if you have to enter a persons SEX and don't enter M or F, you might want an immediate response informing the user of the invalid input. Pretty sure that would be much slower if you had to communicate back to the aware server each time the user changed the input.

Where Aware does have an advantage is the rules that can be triggered with (IF BO.attr WAS CHANGED or IF BO is new). This can be the huge savings in code that Ben mentioned, Not having to write a trigger or call a procedure each time records are added or attributes are changed.

Because of this narrow focus, I think this would be a very difficult sale. I could be wrong, I am usually wrong, but since there are about a gazillion people who can write stored procedures, triggers in their sleep and with the lack of Aware talent, this might be tough to sell to corporations.

I think what aware brings to the table is the speed of development, speed of maintenance, ease of maintenance when using Aware for the entire application and, when necessary call other REST systems for functionality that aware does not have built in.

Just my 0.02 cents worth.

Bruce

[aware_support]

Just to clarify - Aware IM already supports REST services. Nothing stops you from writing native client applications in whatever language you like and use Aware IM REST as the backend (in fact, some people have done that and demo'ed at the Conference in Providence). The ONLY thing that is missing at the moment is security (full OAuth support for services exposed through REST).

If my understanding is correct (and I could be wrong) you would only need to worry about security if your services are accessed by a third-party. If, however, you are writing client applications that use REST as a back-end, why would you worry about security - why would you ask for a token for yourself??

Now, if your services ARE accessed by a third party, then you may want to support proper security. Or not. Depends on the nature of the application. And to us at the moment it is not quite clear how many applications would require full OAUth security for 3rd parties to access their services.

Incidentally, we ARE researching this as we speak - we performed an investigation of how much work would be required to support OAuth for services exposed by Aware IM for the next version. And it looks like it's quite a lot of work. So before we embark on this project we need to understand full benefits of this feature. So far, it looks 50/50 at best.
Your comments on this are very welcome. Maybe I will create a separate thread where people can vote...

[BenHayat]

...

[BenHayat]

...

[PointsWell]

I get down to design an app the design plays out in my head with me driving the configuration tool as it is. Having a fancy graphical GUI to drag a drop and create relationships is just "bling" , which is probably planned because other low code competitors have it .

While this is all well and good to design in your head, it makes it very much harder for maintenance by another person. I have come back to my code that I have been working on intensively for a number of years and still have moments of "What does that do".

Drawing ERD from Aware is of minimal use, but being able to produce a flow based process map would be incredibly valuable to me.

[aware_support]

Code: Select all

In today's wild wild west, security is THE MOST important, no matter who is using the service. Hackers are all over the places and you are asking

This is just a blanket statement. Why on earth would you want OAuth protocol to use your OWN services??? Are you going to grant an access token to yourself?? This just doesn't make any sense.

And security is NOT always necessary - it depends on what you are doing.

[Jaymer]

FWIW,
here's a Node.js OAuth2.0 server implementation

This would allow Bruce, for example, to expose his client's POs, Ordering, etc. to their customers and vendors.
He would use JS to code, parse, etc. all the requests and post directly to the database (which bypasses any Aware business rules).

Question: If Aware DID NOT have this [security] built into it, what chance would Aware have of being the solution for his client?
or... if Aware doesn't offer the highest level of REST security, they'll do it in another tool.
So, if we [ie. Vlad and team] don't do this now, then how many more future opportunities will be missed by us [developers] and Aware?

(cross posted to the REST Vote thread - unsure where the best place for this is)

[aware_support]

And this is what we will most likely use if the project goes ahead (Apache CXF):

http://cxf.apache.org/docs/jax-rs-oauth ... troduction

[BLOMASKY]

Where Aware does have an advantage is the rules that can be triggered with (IF BO.attr WAS CHANGED or IF BO is new). This can be the huge savings in code that Ben mentioned, Not having to write a trigger or call a procedure each time records are added or attributes are changed.

Because of this narrow focus, I think this would be a very difficult sale. I could be wrong, I am usually wrong, but since there are about a gazillion people who can write stored procedures, triggers in their sleep and with the lack of Aware talent, this might be tough to sell to corporations.

I think what aware brings to the table is the speed of development, speed of maintenance, ease of maintenance when using Aware for the entire application and, when necessary call other REST systems for functionality that aware does not have built in.

Just my 0.02 cents worth.

Bruce [Lee]

The RED section, you are making an assumption that is far from the truth.
You're saying anyone writing client code, has access directly to the Db without an HTTP server (like Aware) as the the middle tier.
Aware as a REST service does T H R E E major things,
1) a complete HTTP Request/Respond system
2) a Complete ORM middle tier between client and DB
3) Last but not least, Aware's Process and rule engine allows us to build sophisticated routines against GET, POST, PUT and DELETE verbs.

We can do all the three above in Node.js, .Net Web API or Java, But aware will save you building the infrastructure, all the data plumbing, Data Context management, Data structure and much more.

What we need is to make sure Aware is up to par with today's REST standards and it is fully secure. The rest is already there.

Perhaps you mis-understood me. I was not saying that anyone writing client code is a DB or has access to a DB, What I am saying is that when your offering Aware as the middleware to a corporation, Your offer is "You don't have to know SQL, you just have to learn Aware" With the limited # of Aware programmers, they would have to commit to training the talent. If they decide to go with Node, for instance, then they will certainly need SQL developers (of which there are many). you said:

Aware as a REST service does T H R E E major things,
1) a complete HTTP Request/Respond system
2) a Complete ORM middle tier between client and DB
3) Last but not least, Aware's Process and rule engine allows us to build sophisticated routines against GET, POST, PUT and DELETE verbs.
the 1st 2 can be accomlished by Node with Express in about 20 lines of code. Yes, we do agree on the 3rd. Aware does provide a robust rules based backend that other tools do not. However, I feel that if you decouple the front end from that, you loose so much functionality. That is why most of the competing low-code solutions, provide all 3 layers in 1 tool. UI, MiddleWare and DB support.

Bruce