search

monarch-initiative / monarch-legacy

Monarch web application and API
BSD 3-Clause "New" or "Revised" License
42 stars 37 forks source link

Migrate monarch-app to node.js #817

Closed cmungall closed 8 years ago

cmungall commented 9 years ago

Switch from ringo to node

Previously the blocker here was the switch from sync to async calls. The initial implementation made multiple sync service calls in serial - switching the logic to async would have been a nightmare. Now the majority of service calls are async and in the client (e.g. golr widgets) so this would presumably be much easier.

This will not happen before the release (obviously) but am open to discussion of timing of experimental branches etc. Comments welcome under this ticket. Discussions of other options welcome, but it's unlikely we'll be using grails...

cc

@harryhoch @jnguyenx @kltm @kshefchek @DoctorBud @nathandunn @nlwashington

harryhoch commented 9 years ago

I have no particular experience with node.js, and I'm not the one with my hands deep in the code, but I keep hoping for something that is note quite so wild-west as JavaScript.

I have no idea regarding the validity of any of the content of this article, but it certainly makes me want to take a closer look -- https://developerblog.redhat.com/2015/04/22/scala-vs-node-js-as-a-restful-backend-server/

kltm commented 9 years ago

I think the transparent reuse of client and server code is a big win. I'd think that if somebody was dead set against the current JS, starting the migration to ES6 sooner might be a good way to go.

That said, I think there probably isn't too big a jump that needs to be in the server, especially now that a lot of the old API weirdness is apparently being eliminated. Before anything drastic like switching languages, it's probably worth just teasing out the remote service call bits and seeing how many pain points actually exist.

nathandunn commented 9 years ago

As much as I always advocate Grails (JVM + closures + niceties + web-framework + ORM [optional]), I think that node.js might be the easiest jump. Not because the client / server re-use (I’ve done this with both JS and Java, and I always feel like the payoff is moderate relative to other things), but because most of what the middle-layer does is routing / templating, which node/express is very good at and requires almost no changes to the front-end mustache pages. Grails has a very similar routing framework (it can use mustache, but defaults eg. jsp / velocity / freemarker).

The scala / play framework or clojure / wicket (or maybe something else) might be a good functional java alternative if that is important. But the way the server is built / is moving, it appears to be going more in the direction of light middle-ware with the GOLR layer doing most of the heavy-lifting.

I think my only caveats would be: 1 - do you need JVM integration (ontology libraries, etc) . . . then I would migrate to one of the other JVM frameworks? 2 - who is going to be writing / maintaining it?

In the long-run it probably doesn’t matter so long as the chosen library is well supported / maintained (any of the above will do this).

Nathan

On Jul 14, 2015, at 2:32 PM, kltm notifications@github.com wrote:

I think the transparent reuse of client and server code is a big win. I'd think that if somebody was dead set against the current JS, starting the migration to ES6 sooner might be a good way to go.

That said, I think there probably isn't too big a jump that needs to be in the server, especially now that a lot of the old API weirdness is apparently being eliminated. Before anything drastic like switching languages, it's probably worth just teasing out the remote service call bits and seeing how many pain points actually exist.

— Reply to this email directly or view it on GitHub https://github.com/monarch-initiative/monarch-app/issues/817#issuecomment-121397228.

harryhoch commented 9 years ago

@nathandunn, your analysis makes sense to me. In the case of Exomiser, we discussed JVM-like integration (very possible with Ringo) and opted for a REST interface instead. If we're ok with that pattern, node will probably make sense....

as much as I'd love something functional-ish, it doesn't seem particularly warranted here...

cmungall commented 9 years ago

This is a good summary.

There will be an increasing role in Monarch for application logic written in a JVM language, interfacing directly with SG, OWLAPI, machine learning APIs, etc. But this logic will be outside of monarch-app, which already transitioned to a lightweight template server with most UI on the client side.

On 15 Jul 2015, at 8:45, Nathan Dunn wrote:

As much as I always advocate Grails (JVM + closures + niceties + web-framework + ORM [optional]), I think that node.js might be the easiest jump. Not because the client / server re-use (I’ve done this with both JS and Java, and I always feel like the payoff is moderate relative to other things), but because most of what the middle-layer does is routing / templating, which node/express is very good at and requires almost no changes to the front-end mustache pages. Grails has a very similar routing framework (it can use mustache, but defaults eg. jsp / velocity / freemarker).

The scala / play framework or clojure / wicket (or maybe something else) might be a good functional java alternative if that is important. But the way the server is built / is moving, it appears to be going more in the direction of light middle-ware with the GOLR layer doing most of the heavy-lifting.

I think my only caveats would be: 1 - do you need JVM integration (ontology libraries, etc) . . . then I would migrate to one of the other JVM frameworks? 2 - who is going to be writing / maintaining it?

In the long-run it probably doesn’t matter so long as the chosen library is well supported / maintained (any of the above will do this).

Nathan

On Jul 14, 2015, at 2:32 PM, kltm notifications@github.com wrote:

I think the transparent reuse of client and server code is a big win. I'd think that if somebody was dead set against the current JS, starting the migration to ES6 sooner might be a good way to go.

That said, I think there probably isn't too big a jump that needs to be in the server, especially now that a lot of the old API weirdness is apparently being eliminated. Before anything drastic like switching languages, it's probably worth just teasing out the remote service call bits and seeing how many pain points actually exist.

— Reply to this email directly or view it on GitHub https://github.com/monarch-initiative/monarch-app/issues/817#issuecomment-121397228.

Reply to this email directly or view it on GitHub: https://github.com/monarch-initiative/monarch-app/issues/817#issuecomment-121657429

kltm commented 9 years ago

Elsewhere, we've been migrating our data libraries to something more usable (https://github.com/berkeleybop/bbop-rest-manager; supporting synchronous, callback, and promises) and have had good luck with some of the /synchronous/ http clients in node. Although the one we're using does a very hard lockup, it would probably work fine on a properly configured backend.

From previous poking around all the libs are available on npm, and since we could start out with a synchronous http lib to simulate the current setup, this means that a switch to node is pretty much trivial for anybody with a free afternoon.

DoctorBud commented 9 years ago

I've made progress on this at https://github.com/monarch-initiative/monarch-app/pull/914.

The immediate goal is to have a single body of source code that can operate as either a RingoJS or a NodeJS server, where the tests successfully complete in both environments. Currently, the NodeJS is between 25-50% complete.

Once we have feature parity and tests pass in both environments, we will deprecate the use of RingoJS (but still maintain it until we have verified there are no gotchas in terms of NodeJS running on a production machine) and switch the various startup scripts and makefiles to use NodeJS.

DoctorBud commented 9 years ago

Current status:

Next Steps:

Next Next Steps:

Current Tech:

I've adopted some particular NodeJS libraries to replace some of the libraries that only exist in RingoJS with ones that can be used in NodeJS. The particular versions and libraries here are not cast in stone; there may be better alternatives as we move forward (hooray for choice!).

cmungall commented 9 years ago

I just realized we had a lot more cruft than I thought in api.js; none of the calls to ontoquest, federation are needed. All this means is that you may have ported more than you need to. I would like to decruft soon, but don't want to make future merges hard. No action needed at this point, just FYI

cmungall commented 8 years ago

Done

cruft ticket here: #975