I'm looking into creating a new library which will start a couple of processes. I'm reading the library guidelines and it's not exactly clear to me how I should avoid the antipatterns associated with this. Should I have a supervisor tree in my library that the user adds to their application supervisor manually, adding the various config parameters to use the library?
Previously (like years ago), you just wired up whatever you needed in the library, then that library/application was started automatically when you used it in your app, or you manually added it to the list of applications. But that used configuration to config the library which is another antipattern, so I am thinking that can't be the right way to do things in 2019
right, that's exactly what I was thinking. It's totally possible to have multiple with different options. Would I still do mix new foo_lib --sup though? I thought that generated an app with a main application supervisor that will get auto-started
maybe I don't do that at all, and just provide code that returns a supervisor spec or something
and also, the pre-JITted speed is pretty poor so developing with jruby can be a PITA
but it's the best game in town if you don't use c extensions and can either put up with the slowness in development, or use Cruby for dev
with Jruby 9000 + truffle they are working on supporting c extensions by interpreting the C code and converting it into bytecode which is itself JITted, so JRuby with C extentions can actually beat the speed of CRuby with C extensions in many cases
omosoj: the child instances run the entire time, they are not spun-up per request