Rest of Eureka will be in single rfc rather than multiple
German consortium still working on standing up Eureka environment
Cooperative effort, Kirstin can liaison a bit, Craig will try and connect
Current projects
All
Wayne Schneider can generate a dependency graph from Okapi, possibly by area
Here are the graphs:
Okapi raml allows generating some visualizations
Worked from Q CSP 1 list of modules
Can fake out okapi to generate graph of modules even if they aren't installed to get the graph
Q full graph is overwhelming!
built an install file of what okapi thinks you need to run UI and users module by telling okapi wanted to enable users module with simulate=true then okapi will respond with list of what it thinks that module needs based on module descriptors
pinned snapshots to the Q version to get list of requirements and added in stripes core and stripes smart components
okapi doesn't perfectly portray the NPM requirements, have to know
minimal system of stripes with users a bit less overwhelming
surprises: calendar, batch print, circulation, fees fine, etc
add in inventory and it gets a few more things, surprises: SRM, entities links
add in ERM, minor surprises as well
would want to look at minimum graph and start chopping out what shouldn't be there, and move on to other areas
only shows documented dependencies, bugs do get filed for those
is there anything in this that tells us no we can't enact the draft in the spreadsheet?
is there a way to work through some of these that seem especially off?
the scale of the challenge to actually have loosely coupled applications
are there algorithms to help identify the work
only analysis but not the work
find part of the system that mostly lives on its own and start from there, ie lowest hanging fruit not inventory or circulation
maybe guidance for new things? might not know yet what the guidance would be, having to do the low hanging fruit first to figure out what is possible
some decoupling impossible right now
some things all apps depend on
try and build rigorous minimal platform and then add, leaving off the big things until later, then work from edges in on minimal
previously minimal chopped things out smaller to make it seem smaller, eventually every approach hits the constraint around config options vs testing things actually work
community compromise on testing only one (or two) configs which is why missing deps don't matter because no one installs stuff indepdently
testing and config constraints in the community
dev rancher envs leads to long lasting branches, hosted env build breaks in part because of this
number of configs being tested separately are probably in high single digits but no one testing subsets with subsets
can eureka handle what is in the spreadsheet?
it depends. can compose apps however you like as long as deps are defined accurately but it means you have to enable all apps in one go and then behind the scenes okapi/eureka makes sure everything comes online
grouping in applications but still a monolith in the background doesn't really help
is there benefit in trying to implement grouping and seeing where we need to create more independence? does it give edges? or is it better to start with monolith and do the chipping?
need to define applications is both technical and functional, from technical perspective it is hard to decompose right now so maybe we need to punt on technical and just go on functional point of view
spreadsheet is aspirational
may be used as reference but folks making decisions are on the development teams
actual decomp has to be done by teams
what should this group try and grasp?
once the work starts will the group be able to influence at all?
ok for this group to present aspirational
community seems to want to have a say
iteration on mega applications over time, which aspirational model can lend a goal to
