LUYA 2 thoughts

The LUYA Project is very stable, there are good modules, we try to fix things quickly and add new features step by step. But we also start to see the limitations with current AngularJS code which only have legacy extensions (they often don’t get updates anymore). A lot of people asked for “what will be LUYA 2” and we also started to think about this internally. I also answered a similar question 2 years ago regarding migration to Angular 2:

Rewrite the existing code to angular 2 or any other technique would take so much time, instead we will plan a version 2 of LUYA.

So here we are now, 2 years later, still thinking about what LUYA 2 could be. What your thoughts? What would you expect? Where should the journey go? Let us know!

My (personal!) current thoughts regarding this are:

  • We start from scratch. Taking the best ideas with us, leaving others behind.
  • We should position us more in the segment of an “agency” system, thinking of multiple customers using the same system and not thinking in “1 webserver = 1 customer = intall LUYA” and doing the same for the next customer. There are so many competitors out there for this approach. This means you would have to setup LUYA 2 once for all your customers
  • Thinking more like GitLab, its Open Source you can install it wherever you wan’t but it might give YOU or US (as LUYA Organisation) the built in option to provide this Service as subscription system for all your customers.
  • LUYA 2 should be an API Services Hub which is not limited to a single site, instead you can install all the customers and sites on a single service. All customers will log in on the same LUYA service.
  • Taking ideas from regarding frontend editing of blocks, taking flexibility of Directus in terms of generating data/models and relations.
  • Strict separation of API and User Interface, which means we have to rethink of how ActiveWindows work and other system. It might make learn curve even harder when module developers need to know both PHP and JavaScript (what ever technique we choose).
  • Create models and relations inside the admin, but allow them to export as json which can be taken for VCS (a strong sync process to sync those generate models between environments if needed, providing a single point of contact to all your customers and domains which contains all the data makes it easier for preproduction and test environments. Setup LUYA 2 on two hosts, sync them and all your customers are ready to use the Prep/Test system)
  • When creating websites based on generated relations and inside a generalized API its hard to add logic into, therefore it would be nice when there is like a bridge which contains the project logic (the customers application, for example generate a PDF). Maybe it would also be possible to directly install those application logic as a composer package and just tell LUYA 2 the path to the composer plugin then it does the rest (install and update of the plugin but the code is only maintained in the composer plugin)

In Short: Moving LUYA into a single point of contact for all your customers and websites. Use whatever technology you like to create the websites frontend of your customer, supported by SDKs which talks to the APIs of LUYA 2. If there is specific application logic (create pdfs, customized api controllers, etc.) store them as LUYA 2 composer plugin which is written in PHP and can interact with the LUYA 2 hooks and events.

Just my thoughts :smile:

Hey nadar,
you have some interest ideas. Here are my first thoughts:

Will LUYA 2 based on yii3?

Maybe we can take the core as start point, refactoring and removing old stuff - and start building the other new modules?

Sound really interesting! But we have to keep in mind, that each customer will have many different requirements and logics. It must be possible to override controllers, views, blocks, etc. for each customers, something like a theming for the backend.

If there is one service for many websites/customers we should thinking about scalability and availability.

  • Scalable service (multiple server to one Database)?
  • One database for all customers? Or one db-server with multiple databases for each customer?
  • Support database cluster?
  • Backup mechanismus?

Should also be useful for a backup. Maybe it will be complicate with deleted relationships.

How does package access to the rest of the system? What is with access control for packages?
Should packages be limited to some customers?

Architecture - Microservice

A big question is, should the backend, model and api code in the same repository or extract it into multiple services and repos?
Of course the backend and frontend should completely extract from the other code/services and only access data via the same endpoint. And the frontend is completely customized.
But where will be the business logic? Here my ideas:

User Layer Data Access Layer Business Layer Security Layer Data Model Layer Datasource
Frontend (customer A) LUYA API Customer A logic LUYA permissions LUYA Model MySql (and Elasticsearch*)
Frontend (customer B) Customer B logic
LUYA Backend LUYA API LUYA logic LUYA permissions LUYA Model LUYA DB

*Supporting elasticsearch can help for more scalability and performance on many requests and also complex search queries. An indexer (maybe based on the json export of the VCS?) filling the es indices.