separation of concerns in enduser mojo application projects.

[rmallah]

is there any way to achieve the below in Mojolicious projects.

1. We want designers and ui developers to work only on views/templates of the Mojo project
2. We want to restrict access to the controller codes and other non-ui codes to that team.
3. We want that the ui developers should have a testing environment to iterate their designs while they are working on it.
4. We want ui developers have testing data in the templates while they are working on it.

Approaches that do not work very well.

In certain projects we have developed UIs by purely using data access via XHR requests and
JSON format however we face following challenges.

1. The apps are not as fast 🚗🚗 compared to Controller => Stash => Template , pipeline. (🚀🚀🚀🚀)
2. Search engines do not index these javascript apps / SPA easily.

Non-full proof solutions

1. Encrypt the lib and .pms using source filters.

Proposed wild thought

Can we have a local Mojo application on ui-developers' environment that uses HTTP
to proxy the stash data from a remote mojo application.

Kindly suggest commonly used approaches for such situations.

regds
Rajesh Mallah.

[jberger]

You can of course build two applications, one which is a json api and one which is a thin backend that makes requests of that api and renders html. It would essentially give you a "frontend" or SPA-like app without exposing the backend while still giving you a server-side rendered frontend.

I really encourage you not to source filter encode your backend code to hide it from your frontend developers. If you must separate concerns do it at the application level, use a "microservices" pattern not obfuscation in a fragile manner.

No we will not add core functionality to proxy the stash from a remote application, that is essentially the microservice pattern I describe above but with a proper response rather than encapsulating the stash in some way.

In my humble opinion I feel we should find some way to make Mojo very inclusive
to all kind of team members and make it super friendly to typical workflow pipelines.

I am going to assume this wasn't intended as an insult, I hope it wasn't meant as one though it can be read that way.

[jberger]

You can do layouts in Vue, look at "slots"

[rmallah]

Thanks, that is something that i had not come across before.

In any production environments however its good to have
many options. Yes micro-services patterns using API allow
composition and collaboration among diverse IT setups
and are generally used in modern development, but ...
as it is said there is no single size that fits all.

[jberger]

there is no single size that fits all

no certainly not, however, front-end rendered from a public json api, server-side rendered, server-side rendered from data from a non-public json api (microservice) cover nearly all use cases, all of which mojolicious does support. I'm not sure what you think

Can we have a local Mojo application on ui-developers' environment that uses HTTP
to proxy the stash data from a remote mojo application.

would be other than a microservice baked into the framework in a very kludgy way (which of course we won't do)

[rmallah]

of-course its kludgy and there was no suggestion for inclusion of such a thing.
The combinations you enumerated does nearly cover all use cases.
As a matter of fact i am now realizing that probably this forum is only for
suggesting features for Mojo.

I only wanted a discussion on approach to be taken for separating templates
and controllers among different teams.

[kraih]

As a matter of fact i am now realizing that probably this forum is only for suggesting features for Mojo.

That mostly depends on who happens to read your post first. 😁

[jberger]

In my humble opinion I feel we should find some way to make Mojo very inclusive
to all kind of team members and make it super friendly to typical workflow pipelines.

I am going to assume this wasn't intended as an insult, I hope it wasn't meant as one though it can be read that way.

It probably is nothing, I got a very bad night's sleep last night.