Seeking Advice on Implementing a "Package Level Guide" to Categorize and Track Progress

System Design
81

Message originally sent by slack user U7213XMGS3H

(Max works with me, for context)

82

But once you have moved the files into packs and resolved the big architectural todos, each pack owner should be able to focus on defining a public api and start enforcing it.

83

Message originally sent by slack user U7213XMGS3H

yep

84

Message originally sent by slack user U7213XMGS3H

we’re just trying to figure out our timeline

85

can you tell me how many LOC aprox the project has?

86

Message originally sent by slack user U7213XMGS3H

gosh… good question

87

Message originally sent by slack user U7213XMGS3H

idk

88

Message originally sent by slack user U7213XMGS3H

we have a lot of files in the repo that probably don’t count as real app code

89

Message originally sent by slack user U7213XMGS3H

like old vendor js

90

Message originally sent by slack user U7213XMGS3H

we have on the order of 1k models

91

Message originally sent by slack user U7213U6VS93

Rails stats says something like ~150k of Ruby

92

I’m using https://github.com/fastruby/rails_stats to measure it including all packs and we’re at ~85KLOC

93

beware rails’ own stats doesn’t count packs

94

based on the number I get from that gem, we’re at ~10.5KLOC per developer.

95

that would probably be a more comparable metric

96

Message originally sent by slack user U70TIGAX94P

I worked on huge rails app with hundreds of developers - difficult to say exactly - and we found it wasn’t worth it to have complete coverage with public interfaces, no active records, etc.

However, it was definitely worth it in some high profile cases. And often it turned out to be a natural part of a refactor.

A big obstacle to hiding active records was the graphql api. Efficient queries across all packages require either a pretty heavy intermediate query layer (we were 90% to implementing that and then deprecated it) or privileged access

97

Message originally sent by slack user U70TIGAX94P

Also, documentation can at first be pretty high level, that makes it easier. Not per method, but describe responsibilities of the package and stuff like that

98

Message originally sent by slack user U7213XMGS3H

Yes! we’re struggling with our graphql api too. We’ve taken the stance that we probably need a graphql gateway and to think of the packs almost as services

99

Message originally sent by slack user U7213XMGS3H

We haven’t done that yet, though

100

Message originally sent by slack user U7213XMGS3H

We have a sort of intermediary graphql state right now where all the graph code is one huge pack and it can read the legacy app (which is still most of our code) and the packs’ public APIs. When we build new graph features we ask that engineers not interact with active record