September 1, 2017
Apex Metadata API (generally available in Summer’17)
Apex Metadata API is a must-have for every developer. It empowers developers to update classes/pages/remote site settings/custom metadata and much more straight from Apex. Imagine creating an Apex Class instance from an Apex Class. It will handle dependency Injection in a way that will lower the coherence of the class model in Apex. Currently, when compared to Java project, class model is not handled that smoothly.
As an example of the improvement provided by this feature, consider the use of the metadata library from FinancialForce (https://github.com/financialforcedev/apex-mdapi). Previously, it was possible to create metadata types only after remote site settings were added to the organization. Metadata API remedies this shortcoming by allowing metadata creation without using old workarounds like sending a Visualforce page request to create Remote Site Settings (RSS) – a process which is not secure by any measure.
Metadata API can also be utilized to manage bulk admin work, such as security tweaks which are now possible to do even without metadata deployments.
At the moment, only layouts and custom metadata types are accessible without any deletion option added. In other words, it is possible to either create or retrieve layouts or custom metadata types. As the Salesforce team noted, they are still are working on this. However, if not all functions offered in Apex can be covered with tests, and every operation will be async, this feature does not resolve as many developer issues as it seemed at the first glance.
Here are other limitations. Operation of create/update metadata is async, and can neither be tested nor covered using unit tests.
Lightning Data Service (beta)
The Lightning Data Service handles records processing (create, edit, update, or delete) in your component without Apex controller. The power of LDS allows for the elimination of many components that are made exclusively for this purpose. Moreover, LDS shows additional superiority by utilizing layouts to display records that show consistency with the system’s overall user interface.
This seems like a win for the developer. Only bulkification, the ability to perform bulk operations, is missing.
Some developers who used force:recordPreview, which is also in beta, might consider changing from recordPreview to recordData, which is also in beta. However, be aware that force:recordData might change in some future release. We hope it will not.
Big Objects – Pilot (for some clients)
The Salesforce platform allows the management of huge data volumes through the brand new feature available known as Big Objects. If this feature is released together with the currently proposed design for the Pilot version, it will be a huge win for developers.
Salesforce itself is limited in terms of storage. For example, if you have ten million accounts, then there is a good chance that working with them directly in code might become a nightmare, e.g., like displaying reports or producing graphics. However, the challenge comes not from the data capability of Salesforce, but from the tools to operate with them, such as the non-availability of custom indexes, SOQL selectivity and many other functions. Big Objects facilitate working with Big Data.
Additionally, Salesforce released an asynchronous SOQL tool, primarily for admin. This tool enables processing big objects with ease that could not be processed by simple synchronized inquiry. Imagine counting “likes” per day from 1 billion social media users. Now we have a tool to group them by different dimensions and receive accurate analytics.
Wave analytics on Big Objects, or custom Objects which are based on data from Big Objects, allow for the storage of billions of records inside Salesforce. Combine this with the capability to create statistical objects based on the stored data, plus the capability to utilize custom indexes for custom Big Objects, and it becomes a huge upgrade for Salesforce Standard BigObjects.
Big Objects is somewhat limited in working from Apex. There are only a few options to create and store BigObject from Apex, but no way to retrieve them, due to Async SOQL not yet being fully available from Apex.
Async SOQL – Pilot
Asynchronous SOQL adds ability to work with large datasets, from either Big Objects or standard Salesforce Object. This tool empowers us to use big aggregation queries on large datasets which enables a whole new scenario – the collection of Big Objects aggregate data for custom object records.
This feature definitely holds a great promise for the reason that no other tool yet exists to provide smooth retrieval of data from Big Objects.
There is no ability to work with Async SOQL from Apex, which results in another list of limitations.
User Interface API – Developer Preview
User Interface API enables building native mobile apps and custom web apps with branding, the same look and feel as in a Salesforce due to information about layout in a response – one request for it. A single REST request returns enough metadata, layout information, and data to display, edit, or create a record.
The benefit of the feature is the ability to get metadata layout info and record info with a single API REST request. It is an invaluable tool for those who work with Salesforce and mobile development of their unique app. Now, with user API, the requests are record fields available in one response, as opposed to making two calls – one for the record and the second one for a layout.
Salesforce DX – Public Beta (generally available since Winter 18)
Salesforce DX simplifies the development process for new aps. The feature makes it easier to use custom folder structure, CI integrations, modern developer tools like Selenium, etc.
It works better and faster than any solution which is now available. In addition, the scratch orgs concept will improve CI processing even for existing solid processes. It does this by allowing for the elimination of CI sandboxes, where some developers validate their code before they actually building it into some other orgs. The coolest thing is the custom structure of the project which is achievable only in some IDE’s and not supported natively.
There are no significant advantages from Salesforce DX which were not achievable by a well-configured project, except for scratch orgs and custom folder project structure, which will definitely simplify development for a big projects.
Platform Events – generally available since Summer 17
Platform Events facilitate delivery of secure and scalable custom notifications by Salesforce from external sources. Integration is easier, and architecture can be smoother thanks to the event and event bus structure.
This is a really good feature. It empowers you to either publish events through apex EventBus class, through visualforce/lightning, or subscribe to their creation both on VF/Lightning (using CometD or other messaging lib) and via trigger on platform event through apex. Event-Driven architecture is simple and now it’s available for an apex too.
Consider there’s no rollback on publish operation – event, so publish counts in DML limits
The Winter ’17 and Spring ’17 Releases were really interesting, but the Summer ’17 release proved to be remarkable. Packed with truly valuable developer features, including Pilot programs, the release holds great promise for development professionals.