I have a pretty conceptual question, just for my understanding. So when a component is trying to get something from a apex controller we use action.setcallback syntax. Instead of this, can't the JS controller invoke the apex class directly and in the class we declare the concerned method as a webservice method (with a future annotation and all) just like a JS custom button calls an apex class, currently.
Despite implied promises in the docs that you can directly invoke instance-specific Apex methods from JS, this is not possible at present (re: Case 16394449). So in the Lightning Components world, think of your Apex controller as a static, deterministic, stateless service.
Basically, the "service" (i.e. Apex controller for Lightning Components) is useful only as proxy for the
Database static methods and for orchestrating complex transactions.
One page in the docs reads, "Make your Apex class methods, getter and setter methods, available to your components by annotating them with
Another page in the docs reads, "Add the
@AuraEnabled annotation to any methods, including getters and setters, that you wish to expose on the client- or server-side. This means that you only expose methods that you have explicitly annotated."
Both of these tips are wrong (re: Case 16394449). The only interaction you can have with Apex is through static methods annotated with
@AuraEnabled as described in the "Apex Server-Side Controller Overview" page.
Significant additions and revisions to the documentation on this topic went live this week. These topics are new:
Additionally, other topics including those mentioned here were updated to be consistent with the new doc, and to point to the new topics for details.
FWIW, the (now replaced) documentation wasn't so much wrong as incomplete. The issue is that the
@AuraEnabled annotation is overloaded to be used for two different things, but those two different things weren't explained in enough depth for it to be obvious how they are different. Hopefully the new doc addresses that issue.