Best practices for JavaFX desktop application communicating with a remote server [closed]

Question

I need advice on best practices for designing a desktop application in JavaFX communicating with a remote server. As I mostly have experience in developing web applications, I need to know common problems and need-to knows that should be considered when developing desktop applications.

Problem description and requirements:

This is an application for employees to view data, take report and perform several other actions based on their roles.

• This application will be installed for more than 10 employees, # can be increased later.
• Each employee should be able to login and use the application (multiple employees can use the application at the same time).
• Any modification on data performed by each employee will be recorded for future tracking.
• Application will display differently to each user based on their roles.
• As this application will be installed on many computers, employees can login to application from different computers and they will be recognized by their login.

Suggested solution:

Is it considered a good practice if:

• I use Mysql as backend database?
• I create an intermediary server with connection to database which allows client applications to connect to the server and interchange data through it Or each application instance used by employees should directly establish connection to database which is hosted on another server on the same local network?

Answer 1

An application's architecture has many components to be considered and could be designed in many ways, therefore there is no clear answer to that question but there are some important points that should be considered when designing one. When you are developing a desktop application you should consider its key differences from a web application and try to address the challenges they bring.

• Network (or Internet) Connection: A desktop application might not have an active network connection all the time, so unless you want your program to fail every transaction when an active connection is not available, it should have its local embedded database (like h2) and later sync the data with a web app in a remote server when active connections is available (Don't connect to remote DB directly because of server-side validations, load balancing, etc!).

  Desktop applications are standalone in nature so if one can't function without internet connection then what's the point in it being a desktop app?

• Synchronization: previous point suggests that you should have a local database and sync it with remote server application. Remember that synchronization should be two way: A) send local data to the server B) receive data from server and saving it in local database. This could be tricky if data model is complex and full of dependencies as dependent entities need to get synced together and it increases the risk of sync operations in events like connection failure or power loss. There is also data model changes that should be taken into consideration. So try to:

  • Design your data model to be as minimal as possible.
  • Avoid dependencies between entities.
  • Avoid modeling cross user interactions in data model as it breaks the assumption that application is designed to be used by a user regardless of other users (which is often the case in desktop apps.)
  • Design a protocol for synchronization that considers data model changes and maybe requires the program to be updated before synchronization gets started.

• Updates: Desktop apps usually need to get updated regularly. You have to keep that in mind in all steps of designing the architecture, specially when designing high level modules as they should be as independent as possible so that they can be updated independently. Also you need to design an update scheme to handle this requirement.

• Multi-threading: JavaFx and most of desktop frameworks (that I know of) have a main thread that drives the application and UI components get updated in it. Time consuming operations like synchronization and database transactions should not be done in main thread as they cause the program to freeze.They should be run in a separate background thread and periodically notify their progress to mian thread.

• Database Sessions: In web apps open session in view is a popular strategy for database sessions but implementing it could be tricky for desktop apps. Remember that usually it's not a good idea to have a single session for the whole application as you shouldn't keep sessions open for a long time (keep that in mind specially if you're using hibernate for example).

• Notifications: It's a good idea to implement a notification system to periodically check remote changes and notify users.

Answer 2

Creating an intermediate server I'd say is totally required. If you don't exactly know the amount of users that will use the application, if suddenly it scales from 10 users to 100 it'll kill your database. Also, the database connection is very latency sensitive and many messages are exchanged, so the "closer" your backend server is to your database, the better it will perform. (speaking from experience with a MySQL DB accesses directly over a 3G network. Had to move to REST to get it working reliably).

As I understand that you're already familiar with Java, I'd go for the following architecture:

• Database: (MySQL, PGSQL, MSSQL...)

• Backend Server: Spring Boot might be a good option.

  • JPA (Eclipselink or Hibernate) repositories
  • Implement Business Logic at service level
  • REST Interface
  • Handles authentication and tokens.

• FrontEnd: JavaFX

  • HTTP communication with the bakend. No Business logic is implemented in the JavaFX. Only interfaces with the backend.

The architecture will allow to update the business logic in a central place without caring which version of the application the end-users have. Also, i'd recommend to version the API (ex http:///api/v1/...) to avoid incompatibilities.

Of course, you can try to directly expose your database models directly via REST using spring-data-rest-webmvc. If your DB is already properly designed, in Netbeans with couple clicks you can get the model extracted and get an application ready to expose your models via REST; then, the business logic needs to be implemented in the client. Honestly, if the project will need to be maintained in the future, don't go for this solution and implement the logic in the server.