Ulf Dittmer

Ah, I hadn't noticed that the original post was from 4 months ago. Nothing to see here then :-) Good luck with the sales!

Having read your earlier books (and having been an iText user for years), I'd be happy to review this one as well.

Why would that be different? A service may be used in different contexts, each requiring a different selection of data to be returned. Or it may be a multi-tiered application where, even though the ultimate client is a human being, the processing goes through a number of steps. That would be quite common in a microservice architecture.

That's a similar question to https://coderanch.com/t/740519/java/Graphql-usage-joining-multiple-tables. GraphQL is more a description language (i.e., which data a client wants) than a query language, and as such is not involved with the details of retrieving that data. That can be as complex or as simple as warranted.

GraphQL has nothing to do with databases. It describes which data the client wants, but it's up to the server to decide how best to store and retrieve it. Nothing changes in that respect - GraphQL is just another means of accessing the data.

Yes, that's possible, although it's not GraphQL's role to make this happen. GraphQL is used to describe which data the client needs - it's up to the server to retrieve that data, and return it to the client. So the client need not be aware whether the data comes from one or more tables, or whether it comes from a relational DB at all. So there's a decoupling, and the server-side data architecture could change fundamentally without the client ever becoming aware of it.

I found the OpenLIberty server quite easy to get started with, and it supports JEE as well as MicroProfile, including GraphQL. The easiest way to get started is this: https://github.com/OpenLiberty/sample-mp-graphql, discussed in https://www.openliberty.io/blog/2020/06/10/microprofile-graphql-open-liberty.html.

The OpenLiberty blog has more information about various aspects of how to develop GraphQL application, like https://openliberty.io/blog/2020/06/05/graphql-open-liberty-20006.html and https://openliberty.io/blog/2020/08/28/graphql-apis-open-liberty-20009.html.

Thanks! The Apollo library seems to require a fixed query at compile time (except for parameters), which doesn't allow for much flexibility. But the Netflix library supports creating queries dynamically at runtime - which is the kind of flexibility that I think one wants when going to the effort of implementing GraphQL.

Lanny Gilbert wrote:How much more effort will it be to implement a GraphQL version of the server-side code vs. ReST? Or is the effort the same (more or less)?

That's hard to say without seeing the actual REST API, but in most such APIs I've seen you do not have the capability to specify which parts of the data you want to get, exactly. You can usually specify things like a search term, or an ID for a specific data record, or a maximum number of items to fetch etc., but not select which data attributes, specifically, are returned. So the server-side code would not have the logic to deal with this. Which means that this question:

Our clients, for the most part, want to do as little as possible in order to comply with the change from CORBA and/or SOAP to ReST or GraphQL.
     Given that these APIs have been around for 15-20 years, is it worth building GraphQL, with all its flexibility, instead of ReST, given that the clients will be sending and receiving the same data points, only in JSON format rather than wrapped up in CORBA or SOAP cruft?

is really: does the client want to build in that kind of flexibility, now that the code needs to be substantially touched anyway? I'd say there's no general rule to decide either way, but if the APIs have been running for 15 years without changes as to what data is returned (or even 5 years), and there's no call for that kind of flexibility NOW, then it's probably safe to say that building this capability would be misguided at the moment.

When building systems, it's always tempting to build in flexibility to accommodate future changes, but quite often the flexibility that's eventually required is different from the flexibility one envisions at the start (before the system is actually used). So in general, if the client is not asking for it, and you have no other reasons to suspect that it may be needed soon -which, obviously, you would discuss with the client- I'd say go without GraphQL.

I see that you're discussing Apollo in-depth as a client library, and are linking to a long list of client libraries in various languages. For a micro-service architecture one might have Java clients, not just browser or app. Can your recommend a particular Java client library or two that stand out from the crowd?

It's been a while since the last release, and we've been busy adding features and fixing bugs to make JForum even better than it already is. A servlet container that supports Servlet API 3.1 is now required, for example Tomcat 8. Some of the new and improved features are:

The Trash Can lets you designate one forum as trash can - meaning topics that get deleted are moved to it, rather than actually getting deleted from the database. If the forum is set up to be accessible by admins only, you keep deleted topics for future reference without them being publicly visible (which comes in handy on moderated forums frequently)

Banners can be shown on assorted pages, up to 3 at the top and up to 3 at the bottom, either as plain text or with HTML, including links. That could be used for announcements, or ads.

Added lots of missing translations to various languages

Many improvements for the mobile view: some pages were entirely missing before, and a new dropdown menu for navigation makes it easier to get around

Eight new smilies, some of them animated, like ROFL

Numerous bug fixes

A full list of new features is at https://sourceforge.net/p/jforum2/wiki2/NewFeatures270/, upgrade instructions are at https://sourceforge.net/p/jforum2/wiki2/UpgradingFrom25and26to270/ and you can download it from https://sourceforge.net/projects/jforum2/files/. The documentation is at https://sourceforge.net/p/jforum2/wiki2/Documentation/

All feedback is welcome.

That's great, Stephan. The email was supposed to be in the image in the post, but apparently that only works for me. The email in my profile here is public - that's the right one.

As the JForum team prepares a new release, we want to improve a number of the localizations that have fallen behind. There are about 70 language entries that haven't been translated to Dutch yet, most of them fairly short. Is there anybody here interested in helping us out? If so, please get in touch with me via email.



We could also use help for a number of other languages, namely Turkish, Japanese, Norwegian and Portuguese. Those are even further behind, so would need more work. But even a partial translation of the outstanding entries would be great.

that refers a dependency of maven

No, it does not. That's Maven telling you a compilation error occurred.

Have you followed up on the advice about the Unicode character?

It's been a while since the last release, and we've been busy adding features and fixing bugs to make JForum even better than it already is. While the next version is not quite ready for release, it is stable enough to distribute it more widely and let everyone test it. No additional features are planned before the release, and we know of no bugs, so it should be quite safe to install. A servlet container that supports Servlet API 3.1 is now required, for example Tomcat 8. Some of the features are:

The Trash Can lets you designate one forum as trash can - meaning topics that get deleted are moved to it, rather than actually getting deleted from the database. If the forum is set up to be accessible by admins only, that way you keep deleted topics for future reference without them being publicly visible (which comes in handy on moderated forums frequently)

Banners can be shown on assorted pages, up to 3 at the top and up to 3 at the bottom, either as plain text or with HTML, including links. That could be used for announcements or ads.

More love for the mobile view

Eight new smilies, some of them animated, like ROFL

Numerous bug fixes

A full list of new features is at https://sourceforge.net/p/jforum2/wiki2/NewFeatures270/, upgrade instructions are at https://sourceforge.net/p/jforum2/wiki2/UpgradingFrom25and26to270/ and you can download it from https://sourceforge.net/projects/jforum2/files/.

Once the release is final, an upgrade from this beta to the final version should be quite painless, so you can use this version without having to fear another upgrade later on. All feedback is welcome.