kdenhartog
Add Node.js Support
I have a WIP version of the Node.js wrapper for indy-dev going. I decided to split it from the current indy-dev.dockerfile. Obviously one big problem is the dependencies on different versions of multiple different entities (libindy, indy-node, etc.) due to the different maturities in wrapper support. Do you suggest this approach @kdenhartog or am I thinking about it wrong?
I think that is fine as an interim solution. I'd like to get them together, but if it's easier to build them separately first go for it and I'll figure out how to get them merged together.
I'm thinking the better approach to this will be to build and maintain a few images that can be passed in through make arguments. For example something like make start WRAPPER=node.js VER=1.6.2 would start up a dev image and pool that's compatible with that version of the wrapper and node.js environment.
Suggest you look at how von-image works. With that - someone on our team is building a tagging images with the latest released indy code. Docker-compose files that use it just have to have a tag change to bump versions.
https://hub.docker.com/r/bcgovimages/von-image/ - see the table of versions
There is a related github issues that shows the dockerfile to create von-image. von0image has been optimized for size and functionality.
See the docker files (pool.dockerfile, agent.dockerfile) in https://github.com/hyperledger/education/tree/master/LFS171x/indy-material/nodejs
If I were you, I would use von-image, as it is maintained. Alternatively, I would be tempted to create a parallel project but that brings in node-js on top of indy-sdk + indy-node. I would definitely use the dockerfiles in von-image as the starting point as they have been optimized nicely.
I agree with your point about using the images built and the fact they're already maintained. It's incredibly enticing. The one downside I saw to this approach was that the developer has to edit the dockerfile each time they want to change the version they're working with. I'd like to not have to do that if possible, but I'm not certain it's possible yet.
I've also had some requests to get a indy-node development environment too. I haven't thought too deeply about the best way to do that yet, so if either of you have suggestions it would greatly appreciated.
I don't understand the issue with the developer editing the dockerfile for a different version. indy-node and especially indy-sdk are dependencies for an agent and like any other dependency (e.g. those in package.json, etc.) should be consciously updated as appropriate by dev team agreement. I don't think it makes sense that the developer in an edit/test session would be running different version. I think that makes the integration too tight.
With the current technique, indy-node and indy-sdk can be updated independently, which I think makes sense. indy-node would be tracked more loosely - tied to STN updates likely. indy-sdk would only use release tags (never branches) but would likely be monitored more closely.
As for indy-node dev, I would suggest to the indy-node team that they make a docker image that has all the dependencies, and have only the code that is being work injected into the container either live (volume) or in the last few container build steps. That's a very general model, and there are a couple of ways to accomplish that.