Persistence Initiative: Meeting Report

Categories: Development , TYPO3 CMS Created by Oliver Hader
During a weekend in March 2019 Artus Kolanowski, Manuel Selbach, Benni Mack and Oliver Hader have been meeting at dkd Offices in Frankfurt/DE for a persistence initiative code and concept sprint.

GraphQL Integration

The general scope of the initiative meeting was focused on integrating GraphQL API into TYPO3 core. Preliminary an internal API — used by developers — shall be established to allow retrieving structured data. Due to possible additional dimensions like languages and workspaces this API must resolve proper relations according to the given context.

To expose that API as a public web interface (e.g. to be used by modern client frameworks like Angular, VueJS or React) additional aspects have to be considered — most important to be named is a permission layer to control access of data exposed to the public. Current ideas are based on Symfony‘s “security-acl” package to grant or deny access on various concepts like table, field, folders, files, etc.

Refining table configuration

During the implementation process of inferencing semantics and implicit behavior of $TCA properties, participants identified the demand of structuring current $TCA much better — aspects related to schema (storage), processing (validation) and representation (rendering in user-interface) are target to be separated further.

Support of JSON data-types

TYPO3's mechanisms for storing relationships supports three different types — comma-separated values (CSV) stored at the originator, foreign keys stored at the referenced subject and many-to-many relations stored in a specific intermediate table (MM).

In the worst case scenarios CSV storage only contains identifiers without storing their concept — thus, the according relationship can only be determined by evaluating the current $TCA settings and is not robust to adjustments. JSON data-types became available with MySQL 5.7 and would allow storing specific information as well as being used in database JOINs as well. Doctrine DBAL already supports these data-types — however there is no cross-database implementation of statements like JSON_CONTAINS to be used in QueryBuilder.

Refining permission layer

The possibility to determine permissions on a per-table or per-table-field level currently is only available for backend users and backend user groups. To broaden the application scope and expose a semi-public endpoint to GraphQL, it is required to ensure that only defined information can be retrieved. Thus, the permission concepts need to be decoupled from backend users and any user record in general. Composer package „symfony/security-acl“ provides a flexible concept, based on access-control-lists (ACL), for dynamically managing those requirements concerning permission handling.

Reducing localization and workspace complexity

Resolving multiple content dimensions like languages and workspaces requires detailed knowledge about the implementation — especially when it comes to resolving relationships — it has been mentioned earlier already that these can be persisted as comma-separated values, foreign keys and using an intermediate table. Correct information can only be retrieved by following the principles of retrieving „default values“ and overlaying them for each according context (language and/or workspace). To remove query complexity and possibly allow direct queries — e.g. using JOINs — the semantical meaning of workspace placeholders shall be reevaluated again.

Be part of it.

All in all the participants were able to define next steps for the persistence initiative, shape the concepts to be used and developed a preliminary roadmap. Want to be part of it? Get in touch.