Java front-end, PHP/MySQL back end methodology

Question

I have been basically out of the programming world for about 10 years, with only a bit of dabbling here and there with small Java utilities and one large Access database I wrote for someone, and some VBA macros here and there.

Now I've come back with a project I would like to work on, and I'm very confused about the whole new web-programming scene. I am trying to write a web based multi-user database, and I'm not so familiar with the technologies used.

So I figured that I should go with what I'm familiar with. I know a bit of PHP and lots of SQL, so that's a good start for the backend. And I hate CSS and javascript, so I'll try to use a standard Java desktop application for the front-end (which is anyways more appropriate for this database then a web-based front-end). I don't know C# at all and am not willing to learn it just for this project, though I am curious to learn it eventually.

I've spent many hours on it, and I've familiarized myself with Jackson for JSON processing, and even made a fancy command queue that sends requests and receives responses to the server on a separate thread and deals nicely with errors.

But I'm finding the whole process quite tedious. For every little table I make in the database, I need to make a Swing JFrame, then I have to connect the user interface with the underlying Java class that holds the data, then I have to make the requests that put the data into the appropriate JSON, which often involves little fiddling with Jackson annotations, then I have to make the PHP that takes the data and makes it into an SQL query. And same for the other direction, I have to make a request to the server that asks for the data, I need to write php to make to appropriate SELECT queries, pack it into JSON (at least json_encode does that quite nicely, though it's complicated if there are one-to-many relationships involved) get the information back into my java class, and then to get that displayed in the GUI. And all along the way data has to validated and errors dealt with.

I feel like this is way too much work for such a simple thing. I'm used to Access, where you just make a query, and then displaying the results and allowing the user to edit them is just a matter of running a wizard and moving around the controls a bit. And I feel like a lot of what I've done already with my command processing queue is probably re-inventing the wheel - every web-based application needs something like that.

Am I missing something?

Answer 1

Since you are not developing a website or a web application, but a desktop application which stores its data on a server, there are indeed a few layers you can skip.

A common approach, in this situation, is to use web services.

When a service should be lightweight and interoperable (that is, you can use it with ease from virtually every programming language), the service can take a form of REST. The drawback is that not every server-side language makes it possible to create REST services painlessly, without writing too much code.

Another form a web service can take is SOAP. In .NET Framework, this was a de facto standard option for web services for a long time, although recently, there is a major shift towards REST; for instance, SharePoint itself relies more and more on REST instead of previously ubiquitous WCF services. I could imagine that the situation is similar with Java and PHP.

The benefit of SOAP is that you probably don't have to write any code at all. In .NET Framework, you declare your web service interfaces server-side and let the framework generate the WSDL (the detailed schema of the service) and process the requests and the responses. Then you import the service client-side, without the need to write a single line of code.

The drawback of SOAP is that it is usually much heavier compared to REST. Responses are also usually larger, which impacts the bandwidth.

In your case, consider the web service as an interface to your database. Since you don't want anyone to be able to select everything from your users' table or delete all your tables, the web service is a way to tell who can access what.

This is different from simply giving access to an SQL database with a fine-grained configuration of permissions, so that a given user can access and do only a very limited amount of things. With a web service, you can also sanitize inputs, control how much resources are accessed by a user, use cache to boost performance, access resources outside the database, etc.

Of course, you can simply even the step of writing the service interface if the only thing you need is to bind the service to the database. In .NET Framework, WCF Data Services are used for that (the project is originally called Microsoft Astoria; search for this name if you want articles which are not too technical). I'm sure Java and PHP have something similar.