Alternative to Liferay/JSR 168 and 286 Portals?

Question

My team has been writing a dashboard application using Node.js, Twitter Boostrap, Mongo DB, and Mule for an ESB.

Recently an executive asked us to change our approach to a Portal/Portlet container like Liferay.

Some of us on the team have experience with Liferay, and we have pretty negative feelings about it. Dealing with things like full-page refreshes, portlet lifecycles, style and theming issues, and limited DBMS coverage are at the top of our list of complaints.

We see where our executive team is coming from. They have decided that they want to make the dashboard extensible and easy or easier to plug into for other groups.

Is there a solution out there which can balance the modern web expectations of users with the enterprise needs of IT professionals and executives concerned with building and extensible application with something like Liferay? Pluggable widgets are important here.

Node would obviously be our preference with something like Grails as a close second.

Thanks,

Drying

A portal solves a different problem than grails - e.g. it provides a lot more infrastructure like user & page management etc. . I don't understand what you mean with "limited DBMS coverage" as your portlets can use whatever DB you want. Also, full-page-requests are easy to overcome: Either your UI library of choice automagically does it or you can do it manually. So far, I don't see any negatives in the negative arguments you bring - other than "Liferay is not in the list of your preferences". – Abiotic

Thanks for the feedback. To clarify more. Can I achieve something similar to the portal spec using grails? It has a rich plugin library, and I imagine there are other out there who dislike Liferay. To that end my question was posted. I would like to solve the same problem liferay solves without the Portal overhead. Additionally, if you have some good examples of the overcoming full-page requests, that would be a great help. Perhaps I'm looking Portal in the wrong way- which is old spec/old tech. I'm primarilyconcerned with delivering a good user experience while satisfying executives – Drying

I would say that the portal is an overloaded word. You can "easily" merge the new JS approach and your stack with the underlying structure provided by Liferay. Liferay, either way, goes these days more in the direction of OSGi bundles that are just packages of some kind of application (can be anything from AlngularJS to old school JSP baste things). Especially there is quite a lot of work on going on to have the JS-based application as the first-class citizen. Dig in and don't be scared by the old tech level. Either way, it's not a Portal anymore but a Digital Experience Platform :D – Tighe

Answer 1

This question may not exactly be a good fit for StackOverflow's format, but I can offer some thoughts still.

If you want to stick your current platform, you need to figure exactly what features your executives want to get out of moving to a new platform. Are those features something you can build into your current platform? How much effort will that take compared to rewriting everything else? How effort will it take to learn a new skillset across your whole team? I'm sure your team can learn the new skills effectively but that still takes effort and there will be growing pains as your teams learns. If you can show to your executives that you can get the same features for a similar or less effort and that you can still have similar total cost of ownership, you can make a case to stay on your current platform.

Also I think you are underestimating what a Portlet container can do. I work mostly with WebSphere Portal so maybe thats why I think most of the pain points you mentioned really aren't that difficult to manage for me. Just because your container needs a particular DBMS to manage itself does not mean you can't use a separate DB for your custom data needs. JSR-286 introduced serveResource as a way to make AJAX easier to implement in portlets. In WebSphere Portal (don't know about Liferay), changing out the whole page content without a page reload might the most difficult on your list I'll admit though.

Modern doesn't have to mean bleeding-edge tech. And the large software products can still perform if you know how to use them right, just like any other tool.

Janeenjanek

Thanks. I don't think I've underestimated what Portal containers can, instead, I don't want the extra bloat they bring, that's one of the reasons my group chose node. It's very lean, and you only add the parts you need. Full-page refresh is a big concern of mine. So I avoid Portlets for that reason. If I've looked at this wrong, I'd love more feedback. A bit of background- I took a Liferay development class about a year ago, so I'm not completely in the dark when it comes to how it works. My initial impression was that it was a nightmare to develop, and that use experience was not good – Drying

It seems you are a bit biased towards Liferay when you say it was a nightmare to develop may be because the instructor was not good ;-). Anyways you can just refresh the portlet in the page rather than doing a full page refresh which is the default. As Olaf in his comment put full-page-requests are easy to overcome: Either your UI library of choice automagically does it or you can do it manually. Then it also comes with a fine-grained permissioning system I understand it comes with a lot of features which may not be required like the OOTB portlets and stuff. – Slapbang

If you can cleanly mention your requirement I guess that would help you decide. – Slapbang

"It seems you are a bit biased towards Liferay when you say it was a nightmare to develop" - I don't know that it is bias against Liferay. I think there are plenty of people that are biased against portals based on the complexities and limitations. I'm currently trying to fend off an ongoing investment in portal/portlet technologies because they just don't seem to be relevant anymore. I agree with a lot in this article: JSR-286: The Edge of Irrelevance | Java.net. – Gooseflesh

Link is dead -> web.archive.org/web/20090227070905/https://today.java.net/pub/a/… – Danielledaniels