Expression Platform News Summer Update
By Devon Zachary, Senior Developer July, 2019
EXPRESSION Development Νews
Keep me up to date with the development of Expression.
As we approach the summer dev cycle here at Expression, we’d like to give everyone an update on some of the interesting things that have been happening on the technology side of the platform, as well as how they impact you and your clients. Since this is the first edition of the Expression Platform News, we’re really excited to start sharing what we’ve been working on, and we look forward to your thoughts and feedback on this and on Expression as a whole.
In the months to come, you should be receiving more of these updates about the latest and greatest on the platform, and these updates will also be visible on the right side of the “Welcome” page when you login to Expression. You can also find new and past editions at expression.cloud/community/platform-news.
Dynamic Data Models (Now available in Beta Mode)
Dynamic Data Models are one of the most exciting new features of Expression this year - allowing you to create your own, complete CRUD APIs based on the native Expression API engine.
This expands the customizability of Expression immensely, allowing for complete definitions of Custom Object Types and their relationships; accessed through the Xpr API using the same syntax you are familiar with for all other standard API interactions - and backed by their own native SQL database, just like our standard APIs.
This feature is currently in Beta, but is being used for a couple of projects already with some stellar results! If you’d like to give it a try, let us know and we’ll enable it on your site, as well as give you a cook’s tour of how it works, and what you can do with it.
Performance was improved this quarter by tackling three major sources of slowdowns: API Resource Construction, Settings System, Cache Service andImage Resize.
API Resource Construction
Internal construction of API resources was dramatically improved, primarily by reducing the number of blocking system calls at process start with improvements ranging from 1-15ms per unique resource on the page.
In practice this results in page-speedups between 150-300ms; with the actual amount scaling with the number of unique resources used on a single page.
The site configuration system was profiled and filesystem access was reduced by an order of magnitude delivering a static performance increase (5-15ms) for all areas of the platform.
Metadata pertaining to the management of cache state was factored out of the API caching protocol, reducing network traffic and providing a latency improvement across all areas of the platform
It is now possible to selectively hydrate objects using the parameter select_fields. It is now also possible to grab full collections (i.e. non-paginated) sets from the API by passing all as a parameter for per_page. This feature is an excellent way to efficiently populate combo boxes and listings where you only need a few fields.
There are two strategies on the backend for how this is executed, depending on whether or not there are hydrated objects.
Note: Here we are using HTTP syntax for examples, but these work just as well in XprApi calls (SSJS) or DataSources
Example One: /articles/?select_fields=Id,Name&per_page=all
In this case we are hydrating exclusively first level properties. This is the fastest mode of execution available
Example Two: /articles/?select_fields=Id,Name,Section.Title&with=Section
This mode is effectively the same, but as you can see from the syntax allows you to selectively hydrate embeds as well. The execution strategy is about an order of magnitude slower then the base fastest case (non hydrated relationships) but is still more efficient than a fully hydrated request without select fields.
We are presently refactoring backend calls to use this new feature as we come across potential opportunities in our day-to-day. This will result in ongoing small improvements to the responsiveness of the backend as we find and remap these calls.
Commit State displays have been confusing for some time, because they would occasionally get into a state where the status (committed/unsaved/edited) for a BundleEntity does not match the user expectation. This was because we were using a detection on the DB objects themselves to determine if an object was “dirty” or not, rather than using the actual status of what was committed to GIT in the process.
Unfortunately, this means after the 2.12.5 update that your commit state may appear different than it actually is. The data for this will “self-heal” on next commit of the Bundle and will be correct ongoing.
IDE Fixes and Improvements
Various places in the Bundle IDE have been updated the new API features available to improve performance. A display bug limiting the number of Datasources available for selection has been fixed. A race condition was fixed that affected the Entity Browser, resulting in inaccurate display of data.
2019 Bundle/GIT Roadmap
We are currently in discovery on various improvements to the GIT/Developer workflow for Expression sites, both to dramatically improve the developer experience of working with Bundles and supporting our future goal of a Bundle Marketplace. More to come soon!
Content Management Improvements
Content Management now supports column header sorting. We’ve also integrated Visual Search, allowing for searching articles by Category.
Categories can now be searched by their Parent.
Sort Ordering was previously being managed by the client application, and could get out of synch with the server. This has been changed to always show the most accurate information available from the server.
And finally, it is now possible to open the Article Editor in a new tab from the Section Listing by right (or middle) clicking on the edit pencil icon:
Default Content Type Definition for new Articles
Content Type Definitions can now be defaulted on a Section. This allows you to create a set of Custom Fields, and specify that all new Articles created within a Section will use the Content Type Definition set in the Section Editor:
This is a great feature when you have many Custom Fields on a site, and you want to set up particular sections to only use a subset of those Custom Fields, to reduce visual noise in the editor and support happier Clients, because they’re only seeing what they need to see.
The Expression Technology Team is looking forward to bringing you more great new features and workflow improvements in 2019 - and charting a path to 3.0! Stay tuned for more news!