Timeline for Good way to offer both LWCs and a REST API in the same code?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 22, 2020 at 12:39 | vote | accept | Keith C | ||
| Feb 4, 2020 at 19:59 | answer | added | Keith C | timeline score: 3 | |
| Feb 4, 2020 at 18:00 | history | tweeted | twitter.com/StackSalesforce/status/1224754635338133504 | ||
| Feb 4, 2020 at 17:57 | comment | added | Keith C | @PhilW, In this case, I don't think we would want separate access rights for the two access mechanisms, but you are right that security needs to be factored into the approach (as always). | |
| Feb 4, 2020 at 16:58 | comment | added | Phil W | (Clearly, whatever you do needs to pass security review and there needs to be a good reason to do what you do, but hopefully you get my drift) | |
| Feb 4, 2020 at 16:57 | comment | added | Phil W | The point I mentioned about security concerns - in cases where security can be considered at the API level, perhaps applying an "all or nothing" security approach (if you have all permissions, call the logic otherwise don't call it and return an error), the business logic can be considered a "utility" and not apply CRUD/FLS or other checks of its own. Each "entry point" (REST and LWC/Aura here) can apply the checks relevant to their context of use. For example, perhaps the logic creates new objects that are returned through REST but not to the LWC. REST checks perms, but LWC doesn't need to. | |
| Feb 4, 2020 at 16:49 | comment | added | Keith C | Hi @PhilW, thanks for your attention here! If a layer does something significant then +1; I'm allergic to thin layers that just cause method interfaces to be duplicated e.g. the ugly controller/helper setup in Aura. | |
| Feb 4, 2020 at 16:45 | comment | added | Phil W | Well, it rather depends on whether the business logic is 1:1 with any one of the methods exposed to the "APIs". I said "facade" because these frequently provide a way to view and interact with the business logic and related data is subtly different ways. One of the benefits of such an approach is allowing you to refactor the behind-the-scenes code without impacting any of your APIs (you can also think of these as the traditional layers in an application - front end<->API<->business logic<->persistence). The API layer might also encapsulate more of the security concerns too. | |
| Feb 4, 2020 at 16:16 | comment | added | Keith C |
Yep @PhilW, Yeah fair point. Perhaps the separation should be at the method level e.g. the @AuraEnabled method calls a plain method (also called by the @RestResource code), but then that is close to what I am already proposing. The only extra concern for the @AuraEnabled case is the @AuraEnabled annotation...
|
|
| Feb 4, 2020 at 15:50 | comment | added | Phil W | From a separation of concerns perspective it is better to provide the business logic in one class and to provide appropriate (at)AuraEnabled and (at)RestResource facades in two separate classes that leverage the business logic class. | |
| Feb 4, 2020 at 15:20 | history | asked | Keith C | CC BY-SA 4.0 |