[HN Gopher] Show HN: Archsense - Accurately generated architectu...
       ___________________________________________________________________
        
       Show HN: Archsense - Accurately generated architecture from the
       source code
        
       Author : bolshchikov
       Score  : 86 points
       Date   : 2023-08-06 09:47 UTC (13 hours ago)
        
 (HTM) web link (www.archsense.dev)
 (TXT) w3m dump (www.archsense.dev)
        
       | jtwaleson wrote:
       | Looks like a good start! We definitely need more documentation
       | that does not go stale.
       | 
       | Is this for single repository? If so, do you have any plans for
       | visualizing multiple repos?
        
       | debarshri wrote:
       | Just checked out. Where this can be useful is generating the
       | system architecture for SOC2 and other compliance frameworks.
       | 
       | At ~$1800/year it is fairly expensive.
        
         | j45 wrote:
         | I wonder what the shadow labour costs for doing the SOC2 and
         | other compliance frameworks would be in a year.
        
         | cmgbhm wrote:
         | Funnily enough, I look at the pricing and think there's no way
         | I'd get this tool. If it's 10/user a year I dont think they are
         | economically viable
        
       | [deleted]
        
       | bdg wrote:
       | How do they solve the Code-Model gap?
        
       | alex_lav wrote:
       | Looks great, but 159 a month to even use the tool at all is an
       | instant no.
        
       | morningsam wrote:
       | I'm sure all of us working with distributed systems have had this
       | exact idea at least once, good to see someone actually did it.
        
       | gabereiser wrote:
       | This is awesome. This doesn't solve the justification premise but
       | it does show you definitively that your software architecture is
       | a hairball mess. Often I ask dev teams, "show me your
       | architecture" and get back vague boxes of even vaguer labeled
       | components. This is cool because you can see the dependencies and
       | structure and can devise a view of your architecture from that.
       | However, this is just one aspect to your architecture - the rest
       | is how you host it, how you support it, how you deploy it, and
       | how you develop it.
        
       | chrisandchris wrote:
       | Maybe it's just me, but I would never like to pay such an amount
       | for a subscription of a service (they charge >300 if you use C#,
       | as I do). I maybe want to analyze my architecture on this level a
       | couple times a year. Why do I have to pay each month? I'm missing
       | usage-based pricing today, everyone sticks everything into a
       | subscription.
        
         | danielvaughn wrote:
         | Maybe on an individual level it wouldn't make sense. But for
         | instance, in my current company we have a fairly complex
         | distributed architecture that's difficult to grok for new
         | engineers.
         | 
         | Their middle-tier pricing option is about $350/month, so if you
         | spend more than ~4 developer hours per month
         | documenting/explaining/analyzing your architecture, then you've
         | saving money with their product.
         | 
         | We definitely spend more than that so it would make sense for
         | us. However, I'd want to see it visualize the infrastructure as
         | well (we use k8s and terraform so in theory this should be
         | possible).
        
           | pengaru wrote:
           | > if you spend more than ~4 developer hours per month
           | documenting/explaining/analyzing your architecture, then
           | you've saving money with their product.
           | 
           | Except this is a false equivalence.
           | 
           | Not once have I documented something I was part of creating,
           | in sufficient detail to explain it completely, without
           | uncovering bugs/inconsistencies/oversights that otherwise
           | would likely go unnoticed. Furthermore the practice refreshes
           | the mental model in the minds of those
           | documenting/explaining/analyzing, which otherwise atrophies
           | and becomes out of sync with reality through the work of
           | others.
        
         | bryanrasmussen wrote:
         | Sounds like it would be useful for a company with consultants
         | that work on other companies' solutions - for one.
         | 
         | But yeah >300 sounds like something that will have to come down
         | to succeed.
        
       | not_skynet wrote:
       | going to shamelessly plug my library for python architecture
       | visualization here: https://github.com/mivanit/dep-graph-viz
        
       | chrisjj wrote:
       | This is hugely misguided. Architecture comes before
       | implementation, not after. A tool that encourages a view of the
       | structure of the implemenatation to be mistaken for architecture
       | is a tool for failure.
       | 
       | Whatever next?? Make your code edits on source accurately
       | generated from the binary?? :)
        
         | momirlan wrote:
         | Very true. I would call this "code representation", not
         | architecture. Architecture is a different discipline, at higher
         | level than code.
        
         | gremlinunderway wrote:
         | Not every project is a greenfield project. Very often you're
         | inheriting a huge codebase of legacy production code, so you
         | also need to account for that in your architecture as well.
         | 
         | Or at least you should account for that. I work with a dev team
         | that is supposed to own a huge legacy codebase that we're
         | dependent on a daily basis for using, but they are working on
         | an entire new greenfield replacement and refuse to do any
         | changes to it. Thanks guys, really glad you get to go off and
         | have fun with new tech while I'm stuck in the stone ages.
        
         | BoxFour wrote:
         | Software architecture is an ever-evolving aspect, especially in
         | large companies where multiple teams may concurrently modify it
         | without coordination.
         | 
         | As a simple example: Predicting the downstream impacts of
         | updating a module from c++11 to c++20 can often be a tedious
         | trial-and-error process. Having prior knowledge of potential
         | effects is a valuable starting point.
         | 
         | Though this leans towards dependency management rather than
         | pure architecture, in practice, the lines can blur.
        
           | chrisjj wrote:
           | It is only dependency management.
        
         | victor106 wrote:
         | No, it's not.
         | 
         | In some places the implementation deviates from architecture
         | and it's useful to know if it did and how it did.
         | 
         | Also, not all projects have the time and money it takes to
         | layout an architecture before actual implementation.
        
           | chrisjj wrote:
           | > not all projects have the time and money it takes to layout
           | an architecture before actual implementation.
           | 
           | IME that kind of project gains nothing from adding it after.
        
           | nonethewiser wrote:
           | So this is visualizing software implementation then, as
           | opposed to architecture?
        
             | junon wrote:
             | Yes, not sure why they're using the term "architecture"
             | here. It's a code structure visualizer.
        
             | momirlan wrote:
             | Sure, architecture is the process of actively creating a
             | blueprint, not passively rendering an existing piece of
             | code.
        
         | ChrisMarshallNY wrote:
         | I've found that architecture is an iterative process, in my
         | experience.
         | 
         | I write about it here:
         | 
         | https://littlegreenviper.com/miscellany/forensic-design-docu...
         | 
         | https://littlegreenviper.com/miscellany/evolutionary-design-...
         | 
         | I call it "Paving the Bare Spots":
         | https://littlegreenviper.com/miscellany/the-road-most-travel...
         | 
         | For myself, I think that firm architecture diagrams aren't very
         | good. I think that we need the ability to generate one "on the
         | fly," and this is kind of doing that. Not sure that this is the
         | solution, but it's in the ball park.
        
         | nickdothutton wrote:
         | Sometimes I need to know that the architecture I
         | requested/described is indeed the architecture I got from the
         | development team. I often don't have the time to check the
         | code.
        
         | j45 wrote:
         | In domains that are understood, clever architecture often will
         | beat clever coding, or avoid many headaches altogether.
         | 
         | In unknown domains that are learning their way, writing less
         | code and complexity and not more.
        
       | le-mark wrote:
       | Interesting, what languages are supported? I did not see a list,
       | only the comment "multiple languages supported". As others said
       | diagrams sell but notoriously hard in practice due to the "hair
       | ball" problem.
        
         | d_watt wrote:
         | I eventually found it under their pricing page.
         | 
         | I suspect from how "MVP" their site is, plus only NestJS
         | actually has a "use" button instead of a "request demo" button,
         | that the only thing currently supported is NestJS based
         | javascript, and this is a way to test the water if they should
         | build other languages. I could be wrong, ofc.
        
         | bolshchikov wrote:
         | Currently supporting JavaScript, in particular NestJS
         | framework. Angular framework support is coming and Python. You
         | are absolutely right about "the hair ball" problem, therefore,
         | diagram is with layers that go up increasing the abstraction -
         | starting from really low level (classes, etc) to high-level
         | (system components). Different utilities and helper classes are
         | disregarded straight away.
        
         | junon wrote:
         | They support different languages based on what you're willing
         | to pay. The free tier only supports JavaScript and NestJS.
        
       | kykeonaut wrote:
       | It would seem that some of their tools are open source [0].
       | 
       | [0] https://github.com/ArchSense/archsense-mono
        
       | Scubabear68 wrote:
       | The most useful architecture diagrams for me are context diagrams
       | (process boundaries and interactions), sequence diagrams for
       | important detail, and ER diagrams for databases.
       | 
       | This does not seem to create any of those, unless I am missing
       | something. This seems to mostly speak to code dependencies. Which
       | is useful, but probably not $300/month useful.
       | 
       | A typical architecture diagram will show you ingress points, API
       | gateways and the like, where your app servers or web servers or
       | whatever are, databases, eventing systems, etc and how they speak
       | to each other. This doesn't seem to do that, and it generally is
       | not possible to generate such a thing automatically because there
       | are too many dynamic pieces to track, or there are manual steps.
       | Also, as others have stated, good architecture documentation
       | requires thought and experience on what to highlight and what to
       | omit or group together.
        
       | d_watt wrote:
       | I definitely want some innovation in this space.
       | 
       | Does this actually track dependancies at the code level, or just
       | at the module import level. EG if have a redis connection file
       | that's imported to a service library file, and only 1 of 8
       | exposed methods from that service file use the imported Redis,
       | will every file that imports that service library show a
       | dependency to Redis, or just the ones that import the Redis based
       | service.
       | 
       | Also, quick feedback on your site, your hero image shows the view
       | that turns me off these types of things. An overwhelming graph
       | that sprawls 3 screens horizontally, and thus can't be reasoned
       | about in one look. The ones further down the page are more
       | compelling, but perhaps the 1st one is the only one that actually
       | represents the project?
        
         | Veuxdo wrote:
         | Agreed.
         | 
         | Good architecture diagrams require genuine knowledge, insight,
         | and, yes, effort. The creator needs to carefully decide what to
         | show and what to omit from each perspective.
         | 
         | It goes way beyond dependency diagrams, which is what automated
         | solutions are pretty much limited to. I wrote on this a couple
         | of years ago: https://www.ilograph.com/blog/posts/beyond-
         | whiteboarding-cre...
        
           | gabereiser wrote:
           | Way way beyond dependency graphs... what if your app stack
           | was Erlang or everything was grpc? You going to generate a
           | cute dependency picture for each service? Or draw the
           | ecosystem of services that support a business function? The
           | OP product is a good "start" but far from a complete
           | architecture.
        
       | vee_jay wrote:
       | It'd have been more compelling with a good looking graph. Better
       | to have a video showing the demo instead of a "Request a Demo"
       | button.
        
       ___________________________________________________________________
       (page generated 2023-08-06 23:01 UTC)