Project Discussion (Aug 15th)

[MatthewVita]

New Release!

@privateOmega

3.1.0 is merged in and is testing well! We now have:

• Updated hapi jar
• Version bumps to java, js2xmlparser, and xml2js (primary deps)
• Corrected unit test object
• Improved hl7 parsing support with the latest version of Hapi (forces node >12 with the Node Engine Version)
• Agreement to keep devDependencies frozen as as they aren't managed/don't work together with version bumps
• Potential speed improvements?

Potential Work Items

We're in a good place so this will be tricky to come up with a list of what we want to do with with the library.

• Completely redo the unit and functional tests based on how the devDeps are super old?

• The name of our project has nothing to do with Java. Maybe we can find a mature Hapi binding in a nice programming language to replace (node) Java. Obviously this is a bit more abstract then our current design / the binding would have to cover like everything. Node -> Some New Language Bind -> Java Bind -> HAPI

• Maybe we can go wild and really "brand" the README? Only if your interested. I'm mildly interesated.

• Fix SLF4J logs (very boring)

[privateOmega]

@MatthewVita Kudos, great to see the new version release. Sorry I hadn't replied any sooner with my hectic past couple of weeks. Hope yours turned out well.

True. Replacing Java with a less difficult setup would be great, but considering HAPI being the gold standard of Hl7, I feel strongly against replacing it. Also I dont think there are any bindings for HAPI, atleast I've never encountered any so far.

Branding the Readme? 👍 Sure, any ideas in mind ?

Yes fixing the SLF4j logs would be great like I had said before, its super annoying for a person, especially a dev seeing non-error or really important warnings showing up on their terminal I guess.

[MatthewVita]

@privateOmega Howdy. Both of us keep busy!

Oh wow. I didn't word that well at all! I'm certainly not for getting rid of HAPI - that would defeat the purpose of our project. What I meant to say is we're not necessary stuck with using node java as the middle layer (in theory), which has that nasty old Java dependency issue. Perhaps we can get around that by having node bind with a (compiled?) language that can somehow bind with Java and therefore, Hapi. It's architecturally a mess but it's important that we at least think about some binding solution so we're not stuck with Java 8 and can call modern Java nonetheless. I have a feeling the old version is a deal breaker for many folks when they check out our README. What I'm proposing sounds (is?) sloppy/complex but it least we can start the Java 8 conversation.

As for branding the readme... when you have a chance, please check out https://github.com/matiassingers/awesome-readme. We can compare what we like shortly.

Agree on SLF4J.

Talk soon. Sorry for the confusion on the HAPI stuff!!!

[privateOmega]

@MatthewVita

Oh wow. I didn't word that well at all! I'm certainly not for getting rid of HAPI - that would defeat the purpose of our project. What I meant to say is we're not necessary stuck with using node java as the middle layer (in theory), which has that nasty old Java dependency issue. Perhaps we can get around that by having node bind with a (compiled?) language that can somehow bind with Java and therefore, Hapi. It's architecturally a mess but it's important that we at least think about some binding solution so we're not stuck with Java 8 and can call modern Java nonetheless. I have a feeling the old version is a deal breaker for many folks when they check out our README. What I'm proposing sounds (is?) sloppy/complex but it least we can start the Java 8 conversation.

Maybe I am still missing the point, but how do we interface a node library like ours with a java progream like hapi without node-java, or are there any other java binding libraries in node? Else what I think is we might have to rely on a C++ binding of Java and write native node modules to access that, but that sounds like too much work and complicates the hell out of the project.

Also I haven't tested it out, but does node-java work only with java 8 ?

What are your thoughts?

[MatthewVita]

@privateOmega

Hey!

You can probably tell I'm still dreaming of supporting modern Java. It's honestly for the developer's sake.... and no, I won't be bringing up my crazy/stupid idea to run the solution in a docker container with an API endpoint for instance :). Regardless, here's some new research on a possible solution... we'd be looking at this flow:

Node -> Node FFI -> C++ JNI -> our HAPI code ... and then the whole way back.

Links:

• Node Foreign Function Interface
• C++ JNI usage
• JNI general information

This would work. It's complex though. It's adding 1 more binding and 1 more programming language to the mix. Having two is elegant... three is kinda nuts.

As for node-java and Java > 8 support, I haven't put any serious amount of time to test/research. On my list.

[privateOmega]

@MatthewVita Hey,

haha I am totally down with idea of supporting modern java versions and I would like to see everyone not rely on java8. Well no idea's really crazy, its just too much effort in my opinion. Thanks for this setup information, I will go through it and it looks quite interesting.

[MatthewVita]

@privateOmega,

I did use the word "nuts" haha. It can solve the problem but it's likely going to be too much effort like you said. Also, anyone looking at the code will be "what is going on here???".

At this point, the only way to support "modern Java" is to hide away our code in a Docker container with a single http endpoint. I've brought this up before and think it's also nuts but may be realistic. The current solution remains, of course... this is just a wrapper.

Maybe this Docker conversation is worth bringing up? We're running out of options with this issue :(.

[privateOmega]

@MatthewVita Alright, I guess we can go forward with the docker solution. How about you write a node application with exposed routes and I will containerize it?

[MatthewVita]

@privateOmega okay, I put together something we can start to play with here: #22

It's a node express server that accepts calls to our solution (I'm using the package directly for now). The curls are just for testing.

Ignore the bodyParser stuff... I'm having a terrible time figuring out how to meet my goals with the latest middleware there so I'm using an outdated approach!

Please note I put this together sort of quickly so we can start testing. We will certainly refine the code/etc as we make progress!

[privateOmega]

@MatthewVita I've dockerized the http application in #23. PTAL.

[privateOmega]

@MatthewVita I've merged #23 branch into #22