v2 Roadmap

[preaction]

These are the main features that, when complete, will mark the 2.0 release. These features will be considered EXPERIMENTAL until v2.0 is released.

• Form plugins
  • Form plugins will generate forms for JSON schemas. This allows for easy editing of data by users.
  • Form plugins can generate forms to edit all the fields in an item or only a subset of fields.
  • Form plugins will exist for some popular UX libraries like Bootstrap and Pure.
    • A default plugin with semantic HTML 5 markup not attached to any UX library will exist as well (This is cancelled for now: The default Yancy pages use Bootstrap4, so the default form plugin is Bootstrap4)
  • The form plugin will use the Mojolicious::Validation framework for validating data (This cannot be made to work without extensive enhancement of Mojolicious::Validation to support structured data validation, which can be done in future versions)
  • Yancy uses best practices by default, so form plugins will use Mojolicious's CSRF tokens.
  • Work has begun on Yancy::Plugin::Form::Bootstrap4
• Authentication plugins
  • An authentication plugin API for developing interoperable auth plugins
  • Multiple authentication plugins will be able to be loaded in a single site
    • This will be the Yancy::Plugin::Auth module, which can load other auth modules inside
  • Authentication plugins will exist for some common authentication schemes. Each plugin creates a unique identifier for a user
    • Password-based auth using Perl's Digest modules
    • Future development: LDAP auth (OpenLDAP and Microsoft ActiveDirectory)
    • OAuth2 (via Mojolicious::Plugin::OAuth2)
      • There will be a generic OAuth2 module, and specific ones for Github and other common providers.
    • Future development: OpenID-Connect
  • Authentication plugins will store the information needed to uniquely identify a user
    • Individual auth methods must fetch enough information to identify the user
      • LDAP uses distinguished name (dn)
      • Generic OAuth2 would need to provide a hook to find this information
      • Specific OAuth2 modules, like Github, can provide this information automatically
    • The multiplex Yancy::Plugin::Auth module must store what auth module the user used
  • Password-based auth will allow registration and providing an e-mail address for password resets (sending e-mails like this will be handled by a plugin and may be added to core later)
  • Future development (v2 and beyond):
    • User profiles that should be filled out when authenticating for the first time
      • This is already supported by registration_fields
    • 2FA for password-based auth
    • Role-based authorization plugin
    • Link multiple authentications to a single user profile
      • This is already supported by varying the username_field across multiple auth plugins
    • Authentication plugins may expose other information about the user
      • OAuth2 plugins can ask for "scopes" to get e-mail addresses, names, locations, etc...
      • LDAP plugins can fetch common LDAP fields
      • Plugins will all configure this in the same way, so that the multiplex Yancy::Plugin::Auth will be able to configure plugins correctly
• File upload field
  • Data fields will be able to be a path to a file
  • Files will be able to be uploaded through the JS editor or POST forms (using the form plugins)
  • Files will be stored using a content-addressable folder tree (using Perl's Digest modules)
  • Files which are not linked to data in the database will be cleaned up on a regular basis using a "cleanup" command (scheduled by the administrator)
• Data relationships
  • Properties in the schema can be declared as relationships to other data foreign keys.
    • This is completed in v1.043
  • Additional properties in the schema can be declared as relationships Instead, any x-foreign-key in the schema, or that refers to the schema, is automatically a relationship that can be joined.
    • These relationships can be one-to-one or one-to-many
    • Related data can be expanded by default in the configuration, or on-demand as an argument to the get or list backend methods
    • We do not want to send the entire set of related data every time we save the item, so the related data will be read-only for now
  • The editor will display a link to edit the related data
    • For one-to-many relationships, the link will display a list view
      • The list view will allow for creating/deleting items, ensuring foreign keys are correct
      • The list view will allow for editing existing related items, without editing the foreign key
    • For one-to-one relationships, the link will go directly to an edit form
  • Future development (v2 and beyond):
    • Support many-to-many relationships through a relationship table
    • Support editing related data in the same form as the parent data
    • Read foreign key relationships from the schema for the supported backends
• Pluggable editor
  • The editor menu will have a section for "Plugins".
  • Yancy::Plugins will be able to add themselves to the menu by defining a VueJS component
  • Yancy plugins will be able to add routes under /yancy/plugin/:plugin_name
    • It's not necessary for the editor to control route creation, at this point. Plugins can create whatever routes they want where-ever they want.
  • Plugins can define multiple routes and link between those routes, creating an application that lives in the Yancy editor
    • The editor is a single-page application (SPA) using the Vue.JS app framework. Over time, the JS API will be enhanced to allow for easier extending of the editor.
  • The editor itself will be moved into a plugin as well, see Slight reshape to de-emphasise bespoke spec in favour of OpenAPI spec #22
• Internationalization (i18n)
  • A Yancy site may load one or more language lexicons
  • All default Yancy templates and user-facing strings will be internationalized, with the language being decided by visitor preference
    • Yancy can be shipped with contributed translations
  • All internal log messages will be internationalized, with the language of the message being decided by the site's developer
  • Site developers will be able to extend the Yancy lexicons to add their own strings

These are breaking changes that will be made for version 2.0, with a transition period during the 1.x development cycle:

• collections configuration will be renamed to schema
  • This more accurately describes what is being configured
  • Any references to collection will be renamed to schema
  • This also makes it possible for parts of Yancy to accept both the name of a schema in the configuration or a JSON schema hash for ad-hoc schemas
  • During the v1.x development cycle, collections will be an alias for schema in the configuration, and collection will be supported
    • Before the stable v2.0 release, a warning will be generated to remind users to rename collections to schema on app startup
• The Basic auth plugin will be deprecated.
  • This plugin was designed for simple authentication while waiting for the more advanced pluggable authentication module.
  • The route feature of the Basic auth module is hard to use, hard to test, and just plain wrong
    • The pluggable Auth module provides a better way to protect given routes
    • The standalone app will need a way to require authentication for routes
  • Once the Auth plugin is complete and stable, the Basic auth plugin will be removed.

These things are not required for version 2.0, but would be nice to have.

• MongoDB Backend (WIP branch: backend/mongodb)
  • This will require the Yancy editor to understand some more complex data structures, similar to data relationships and packed data fields

[rmallah]

Data relationships
>>Properties in the schema can be declared as relationships to other data

Hi , I justed wanted to know if anyone has done any blueprint for
property naming conventions for expressing the relationships for other data.
This part of roadmap is extremely important even for early adoption of yancy
as any non-trivial system has relations to other data.

It is important to know the property naming convention so that we can write code
even for internal consumption at this moment that can be open sourced and contributed
back later.

regds
mallah.

[preaction]

On Mar 29, 2019, at 8:18 AM, Rajesh Kumar Mallah ***@***.***> wrote: Data relationships >>Properties in the schema can be declared as relationships to other data Hi , I justed wanted to know if anyone has done any blueprint for property naming conventions for expressing the relationships for other data. This part of roadmap is extremely important even for early adoption of yancy as any non-trivial system has relations to other data. It is important to know the property naming convention so that we can write code even for internal consumption at this moment that can be open sourced and contributed back later.

There will not be any required naming restrictions for establishing relationships: Yancy is designed to work with existing databases as they are, and this feature will continue that philosophy. The relationship will be configurable in the schema.