Here's some ideas for things one could build using Entity JS.
- Use EFQ to return entities based location and plot them using a mapping library. Leaflet?
- Plot data stored in your entities into charts/graphs using a data visualization library. D3.js?
- Use Drupal as the datastore for your event-driven, asynchronous I/O project. Node.js?
- Lazy load entities using view modes into a parallax scrolling site.
- Update commerce entities based on DOM actions to speed up your Drupal Commerce site.
- Create killer AJAX-driven content editing forms to better serve the needs of your clients.
So yeah... pretty much anything you were able to do using entities before can now be handled asynchronously via JS in Drupal.
So how does Entity JS work?
As stated earlier, Entity JS is an abstraction of the Entity API. Some of the functions are nearly a direct 1:1 abstraction such as entity_create and entity_delete. Other functions act more like helpers to provide a set of actions. For example, entity_render_view loads an entity and then invokes entity_view to return the entity as HTML that can be inserted into the DOM. The aforementioned function even takes a 'view mode' argument, to allow for any field display configuration the JS programmer needs. Call and respond a node with a 'Full node' or a 'Teaser' or any custom Entity View Mode that the system allows, and so on.
Security and Access Permissions for Entity JS are unique.
My retort here is "YES!" - I completely agree. This is why the permissions on this module are not set for any users roles on install. Site admins must opt-in these roles to give access to actions using specific entity types. One note: Right now we do not have any check for per-bundle entity access.
Entity JS is definitely an alternate layer that can easily be used to attack a Drupal site if the permissions were turned on fully. Don't do it! You especially don't want to allow CRUD access to 'user' entities on your site to anonymous users. This should be obvious but I have to feel I have to say this here.
There are definitely safe ways to use the module. For example - if you only want users to view content, configuring Entity JS permissions to allow anonymous users to 'read node entities' is fine. But keep in mind, if you have nodes that you don't want people to see, a savvy person could potentially expose Entity JS to call nodes into their browser console or what-have-you.
Why isn't Entity JS access handled by existing permissions?
There is also the idea that one could use the existing access hooks for users to determine what entities can be dealt with for that role. The problem here is that users may need access at different levels when the browser is enacting commands on their behalf, such as it would often be in Entity JS. It shouldn't be implied that just because Entity JS might be configured to allow authenticated users to create taxonomy terms that these same users should be allowed to visit /admin/structure/taxonomy/tags/add from within the Drupal site.
While large portion of users will not read your JS code, especially if it is compressed, this doesn't provide full security because the JS behaviors are still available to anyone willing to try using them.
Setting permissions correctly for Entity JS is very, very, very important. If anyone would like to donate time to do a security audit on this module, I would be very grateful.