Best architecture for multiple front-ends (e.g., Admin vs. Client) sharing one backend?

[roveda.marco (Marco Roveda)]

Hi everyone,

I’m trying to find the best architectural solution for a Jmix application where I need to have a single backend (data, entities, services) but two (or more) different front-end “entry points”.

My goal is to have a setup like this:

1. office.myapp (The Admin/Back-office App)

   • This would be the “main” Jmix application.
   • It defines the full data model, all entities, and includes all the standard Jmix UI screens for managing the entire system.
   • Users here are administrators or back-office staff ad see all tentants data.

2. client.myapp (The Client-facing App)

   • This would be a separate front-end application, running on a different port or URL.
   • It’s intended for external users (clients/tenants).
   • Users logging in here should only see a very specific, limited set of screens and be able to perform only a few actions (e.g., input data, update entities ecc) on a subset of the entities.

My key requirement is to physically separate these front-ends. I want to avoid having one single, monolithic UI where I have to manage complex role-based logic to hide/show 90% of the application for client users. I’d prefer two distinct applications that share the same backend logic and database, if is it possible

I’ve been considering two potential approaches and would love your advice on the “Jmix-idiomatic” way to do this:

Option 1: The Composite Project Approach
Is using a composite project the right way to go?
For example, I could have:

• A core module (add-on) with all entities and services.
• An office-ui module (add-on) with the full admin UI.
• A client-ui module (add-on) with the limited client-facing UI.
  Would this allow me to deploy two different runnable “apps” (office and client) that both depend on the core module? i don’t find best practice to configure this solution in a good way, i don’t know if there is documentation about this use of composite projects

Option 2: Main App + REST API Approach
Is the recommended solution to build office.myapp as a standard, complete Jmix application, and then build client.myapp as a completely separate application (e.g., a simple Jmix app with its own UI) that consumes the data from the main app via its RestDatasource?

I feel like Option 2 might be cleaner, but I’m not sure if it’s the most efficient way or how data sharing works best in that scenario (especially if the client app is also a Jmix app).

What is the best practice for achieving this “split front-end” architecture?

Thanks in advance for any guidance!

[mbucan (Mladen Bucan)]

Hello,

jmix.io

https://docs.jmix.io/jmix/separate-tiers-guide/index.html
https://docs.jmix.io/jmix/rest-ds/index.html

jmix.io

The architecture depends on many factors, some are:

• number of users
• need for future scalability
• number of database tables and rows
• security considerations
• performance
• existing systems

You can go several ways:

• can build office app, then copy paste it and gut it to have client-only interface, make 2 jmix applications with their own databases, have a external datastore to read data from each other, and it would work

• but you are aware of making the maintenance easier so you consider Option 1 - according to your specifications there would be one “core” application without UI (possible) and then you would upgrade it with add-on to have desired effect - they would look at the same database , remember that in order for jmix to work, it needs admin rights to its database, so you would use Jmix security with roles, which is quite good - but user must not be exposed without control to portions of UI that have unconstrained datamanager or entity manager, or can write sql, jpql, bpel, groovy and such

• You need to make an experiment with this and see if this fits you, have a few tables, construct entities, make the composite project - I’m not using it myself, but I know people do

Option 2 seems better to me, call me old-fashioned, but I like separation

• but be aware that REST call to access data is 3-17x slower in average than talking directly to the database (so if you have a gargantuan amount of data, make a shared database)
• The advantage of REST is that you can then connect other things to the services and business logic you have - maybe some future mobile app
• This doesn’t prevent you from having a core app without UI (or with admin UI) with data and logic, an office app, and a client app, like in Option 1
• With this, you don’t need to give access to the core module source to other developers, just the REST API specifications
• be aware to know how to secure these calls, use repositories …

I also have a requirement to develop the customer-facing app soon, so Option 2 is the way I will likely go - there could be some “modules” that another ecosystem’s developers can do by calling REST services

Kind regards,
Mladen

[krivopustov (Konstantin Krivopustov)]

Based on your requirements, I would go for Option 1. You will get 2 modular monoliths sharing some core model and logic, and connecting to the same database. Both are standard Jmix full-stack apps, so they can include any Jmix add-ons and all Jmix features will work out-of-the-box.

You can create just three modules:

• Core add-on (using Add-On template)
• Main app (using Full-stack App template), depends on core add-on
• Client app (using Full-stack App template), depends on core add-on

If both apps are developed by a single team, you can do it in a single composite project, so the friction for modularization will be minimal. The modules can also be moved to separate projects when needed.

This approach is definitely simpler and more “straightforward Jmix” than having a UI-only Client app connecting to the Main app through the REST DataStore. In general, I think that UI-only apps (as in Separating Application Tiers :: Jmix Documentation guide) should be considered only if you have a strong motivation to have no connection to the database for these apps.

The limitation of separate apps connecting to the same database is the inability to synchronize in-memory state for shared features like entity/query caches, pessimistic locking, notifications, etc. Basically all features described in Cluster Communication :: Jmix Documentation should be used with care.

Regards,
Konstantin