Is it a good system architecture? | Code Society | Page 1

frosty crown Jan 25, 2026, 7:27 PM

#

Hi, so im building a beauty-salon multi app platform, and i wanna know if i did the right system architecture, i have separated spring REST API that has JWT role based authentication and MS SQL for database, i have admin side seperated, client side separated, both are web apps, and for employee side i choose javaFX desktop app for better performance

orchid pagodaBOT Jan 25, 2026, 7:27 PM

#

Gotcha

You call a bad discord mod an admin-is-traitor.

winter willow Jan 25, 2026, 7:30 PM

#

JavaFX is not something I'd pick personally, because:

you have massive platform lock-in
distribution is annoying
JavaFX is basically dead (ecosystem is dead, UI looks ugly, hard to hire)
very skeptical about the performance gain since network latency is gonna dominate anyway

Just use the same web stack for all 3 parts, share components etc. and then just ship an Electron app if you actually need a desktop app for some reason

#

MS SQL is a meh at best, just use Pgsql tbh

#

You'll probably want multitenancy support as well, finer grained permissions are probably another thing you'll need

frosty crown Jan 25, 2026, 7:33 PM

#

Well it includes a lot of features

#

From services history scheduling appointments, financial reports,

#

Employees

winter willow Jan 25, 2026, 7:35 PM

#

We have literal CAD workstations and Figma running on web tech, it's fine

bright helm Jan 25, 2026, 7:43 PM

#

Can you explain why you decided to separate the client and admin, and how they interact with each other? I assume the client schedules appointments and then sends that information to the admin side somehow.

It seems like this could also have been implemented as a single monolithic app, using a JWT to control access to specific routes, with admin routes simply prefixed by admin. At least, it's probably what I would have done unless there's something very specific that requires separating the services.

Not only would it make development easier, it could drastically reduce complexity, operational overhead, and cost, especially if there aren’t scaling requirements yet (for example, when you don’t have a lot of clients or users).

orchid pagodaBOT Jan 25, 2026, 7:43 PM

#

Gotcha

You call a bad discord mod an admin-is-traitor.

frosty crown Jan 25, 2026, 8:03 PM

#

bright helm Can you explain why you decided to separate the client and admin, and how they i...

They all are tied to same REST API

frosty crown Jan 25, 2026, 8:03 PM

#

bright helm Can you explain why you decided to separate the client and admin, and how they i...

Admin controls the business, he registers employees, services, financial reports etc

orchid pagodaBOT Jan 25, 2026, 8:03 PM

#

Gotcha

You call a bad discord mod an admin-is-traitor.

frosty crown Jan 25, 2026, 8:04 PM

#

The client side, its a webiste about the company, what service they offer, clients can register and schedule appointments based on available dates and see their history etc

bright helm Jan 25, 2026, 8:17 PM

#

frosty crown They all are tied to same REST API

i have separated spring REST AP
To be clear, when you say that, you mean you have 1 or 3 rest api? Because it sounds like you're saying you have 3 rest api service running?

frosty crown Jan 25, 2026, 8:18 PM

#

bright helm > i have separated spring REST AP To be clear, when you say that, you mean you ...

I mean i have REST API for all 3 apps (admin, client, employee)

orchid pagodaBOT Jan 25, 2026, 8:18 PM

#

Gotcha

You call a bad discord mod an admin-is-traitor.

bright helm Jan 25, 2026, 8:19 PM

#

Okay that make more sense, you had me scared for a moment. I thought you had 3 different rest api

frosty crown Jan 25, 2026, 8:19 PM

#

Nah that would be stupid

bright helm Jan 25, 2026, 8:20 PM

#

Than it should be fine. I still agree with not rob that it could've been one web app for all of them and use a electron app if you really needed a native solution for your employees.

frosty crown Jan 25, 2026, 8:21 PM

#

bright helm Than it should be fine. I still agree with not rob that it could've been one web...

No bro what

#

Its more an enterprise system

#

Not what u think

bright helm Jan 25, 2026, 8:22 PM

#

And? Enterprise system are built with electron nowdays. It's totally fine. I would even argue that you probably don't need a native solution for that and can just have you employees use the browser

frosty crown Jan 25, 2026, 8:23 PM

#

But javafx does https requests

bright helm Jan 25, 2026, 8:23 PM

#

I've worked building software for a company that made medical research software used by almost all research center and hospital in the province and that's what we did. It worked super well.

Nowadays, in in 99% of the cases, you don't need a desktop app

frosty crown Jan 25, 2026, 8:23 PM

#

The desktop app is also tied to restapi

bright helm Jan 25, 2026, 8:25 PM

#

frosty crown The desktop app is also tied to restapi

That's the thing I'm saying, you could have removed all the complexity of using a microservice architecture. The only real place in your system that I see value in using an API is for the client part. But it could've easily been handled by a monolithic web app

#

Although, we could easily argue that we could get ride of the whole rest api shenanigans and just have clients use it directly as well. All you'd need is a link towards the client portal

#

The microservice approach is likley not necessary for your use case.

#

#

What do you think @winter willow?

frosty crown Jan 25, 2026, 8:36 PM

#

#

This is how it looks

winter willow Jan 25, 2026, 8:36 PM

#

bright helm

Nah I'd probably just have 2 separate webapps, one end customer facing one

#

and then one merchant-facing one

#

multitenancy seems to be a very important feature here lol

bright helm Jan 25, 2026, 8:37 PM

#

If it is, the yes sure, I'd agree with 2 separate

winter willow Jan 25, 2026, 8:37 PM

#

and then just have the merchants use the same webapp for all roles (employees, admins, etc:)

#

But I'd also throw them all into the same backend API lol

#

or like one merchant API

#

and then one self service thing

bright helm Jan 25, 2026, 8:41 PM

#

winter willow But I'd also throw them all into the same backend API lol

I'm not sure about that then.

#

But as you said at the very beginning, "ask 10 people you'll get 15 different answers"

winter willow Jan 25, 2026, 8:42 PM

#

we did that at work and it served many people

bright helm Jan 25, 2026, 8:45 PM

#

bright helm I've worked building software for a company that made medical research software ...

The way we did it there (it was like that from the beginning) was simply one instance + db per customer. We were also following governmental rules that kind of forced us towards this but it's totally a way to go.

winter willow Jan 25, 2026, 8:46 PM

#

Ye we had a few dedicated instances too but those were quite expensive (and we eventually reduced that over time)

bright helm Jan 25, 2026, 8:46 PM

#

Yeah it was for sure more expensive

#

Most of the time it wasn't our decision; they wanted their own thing running in their servers.

#

Anyway, I’d be comfortable with the 2 app solution you proposed, but I think we could start with something simpler.

You can start simple with one app and a shared database. If the user base grows, you can scale by adding a load-balancer and, when necessary, give certain tenants their own databases without changing the application.

bright helm Jan 25, 2026, 9:54 PM

#

#

And then if it scales even more, there's some bottleneck or simply new requirements, it's always possible to change toward a microservice architecture relying on REST APIs

livid jewel Jan 28, 2026, 4:55 AM

#

bright helm I've worked building software for a company that made medical research software ...

osintbuddy 😭

bright helm Jan 28, 2026, 5:25 AM

#

livid jewel osintbuddy 😭

???

livid jewel Jan 28, 2026, 5:38 AM

#

bright helm ???

Its an electron app now

bright helm Jan 28, 2026, 7:03 AM

#

livid jewel Its an electron app now

It's fine the XD

young stag Jan 30, 2026, 9:30 PM

#

I would use MySQL8 or MariaDB 10.3, but if you use MSSQL, make sure you have covering index for everything.

Samething for MySQL on AWS or Azure, you need covering index.

Keep everything small, 10 tables max.

I would use Jersey instead of Spring, unless you want Spring Boot AppService.

Jersey has better backward / forward compatibility support, less major upgrade nightmares, and less CVE.

Do you really need a desktop app, instead of just an HTTPS website ?

Make sure you JWT is not exploitable.

bright helm Jan 30, 2026, 9:31 PM

#

All good advice hahaha

#

3/3 don't recommend the desktop app haha

young stag Jan 30, 2026, 9:35 PM

#

Maybe for like a cashier app

#

Maybe he needs to support like kiosk payments

#

All my clients who have kiosk payment are written in C# with MSSQL hosted on Windows 11

#

I know one restaurant who is using iPad kiosk payment

#

Some are still on MS-DOS 😂

bright helm Jan 30, 2026, 9:36 PM

#

young stag Maybe he needs to support like kiosk payments

Maybe but I'd argue that you could still run it in a browser in 99% of the cases

#

Or make it work in a electron app and call it a day

young stag Jan 30, 2026, 9:38 PM

#

https://openjfx.io/

JavaFX

#

does not look too bad

#

JavaFX has not been discontinued. It was removed from the core Java Development Kit (JDK) bundle in Java 11 to allow for more flexible, independent development and release cycles. It is now maintained as a standalone open-source project called OpenJFX.
Key points regarding the status of JavaFX:
Decoupled, Not Dead: Oracle stopped bundling JavaFX with its JDK releases, but the source code was open-sourced under the OpenJFX project, where it continues to be actively developed and maintained by a community that includes contributions from Oracle developers and the company Gluon.
Separate Module/Dependency: Developers must now explicitly include JavaFX as a separate library dependency (e.g., via Maven or Gradle) or use a JDK distribution that bundles it, such as those from Azul Systems or BellSoft.
Active Development: OpenJFX follows the same release cadence as Java, with new versions (e.g., JavaFX 24) released in parallel with new JDK versions and receiving regular updates and enhancements.
Modern Framework: It is considered a modern GUI toolkit with features like CSS styling, FXML for declarative UI, 2D/3D graphics, and support for desktop and mobile platforms via third-party tools like those from Gluon.

#

Swing + FlatLaf

https://www.formdev.com/flatlaf/

#

SWT I have used also

#

If you want to stay pure Java

Swing + FlatLaf (most practical today)

Swing is old but rock-solid

FlatLaf gives you a modern UI (IntelliJ-style, dark mode, HiDPI)

Massive ecosystem, easy packaging

Still actively used in serious tools (IDEs, enterprise apps)

Pros

Stable, boring (in a good way)

Native-ish look

Zero drama with JVM updates

Cons

UI code feels dated

Not “fancy” by default

👉 Best choice if you want reliable desktop UX without fighting the toolkit.

JavaFX (still viable, just… different)

Now community-driven (OpenJFX, Gluon)

Cleaner UI model than Swing (FXML, CSS)

Good for dashboards, media-heavy apps

Pros

Better UI architecture than Swing

GPU-accelerated

CSS styling

Cons

Smaller ecosystem

Packaging & long-term confidence issues

Fewer devs excited about it

👉 Fine if you already know it or need rich visuals.

SWT / Eclipse RCP

Uses native OS widgets

Very “enterprise tool” vibe (Eclipse, DBeaver)

Pros

True native look & feel

Fast, mature

Cons

Steeper learning curve

Less flexible UI design

Tied closely to Eclipse ecosystem

👉 Good for internal tools, not flashy apps.

#

JavaFX might not be a bad idea

#

Spring Rest is a maintenance nightmare

#

upgrading MSSQL is painful, and .bin backups is not nice either

#

Just make sure you test all your queries in the Microsoft SQL Server Management Studio and use covering indexes for EVERYTHING.

#Is it a good system architecture?