Show HN: Archsense – Accurately generated architecture from the source code | Hacker News Reader

Show HN: Archsense – Accurately generated architecture from the source code

archsense.dev

105 pointsbolshchikov44 comments

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.

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).

> 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.

I don't think that would be my preferred use-case for visualizing code or infra. I would use it when looking for issues (like to tight coupling, recursion, ...) but not for documenting or similar.

Also, regarding architecture, why is more important than how (2nd law of software architecture, see Mark Richards), but such a tool especially provides the how and fails to explain the why at all - making it not a perfect for a software architect.

The difficulty in documenting code is not creating a diagram of it, but rather simplyfing the things enough so that one can understand it quite "fast" while not omitting important details. I'm fairly confident that this task requires some sort of intelligence a tool can only provide to some degree.

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.

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?

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...

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.

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.

It would seem that some of their tools are open source [0].

[0] https://github.com/ArchSense/archsense-mono

going to shamelessly plug my library for python architecture visualization here: https://github.com/mivanit/dep-graph-viz

"generating architecture diagrams directly from the code - the source of truth." becomes a lot easier when the source code is the architecture.

When you can express the architecture directly in the code using an architectural programming language.

https://objective.st

Interesting link you shared there.

Can you link to a real-world example of using Objective-S to specify an architecture?

The "scripts" directory in the repo has a good number of samples.

Note that I wouldn't call it "specifying an architecture", I would call it "programming the system using architecture-appropriate connectors".

For example, a task JSON backend:

https://gitlab.com/mpwmo/ObjectiveSmalltalk/-/blob/master/sc...

First defines a Task (model) class, then a scheme-handler for storing those tasks (in memory), and finally configures + hooks up those objects to create+run the actual backend.

I think this is more code archeology than architecture, no?

I can see the utility of it for onboarding new team members - instead of chasing down stale docs, one gets a look at the state of the codebase as it is today.

It probably helps to spot problematic / unintended dependencies and the like as well.

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.

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.

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.

They support different languages based on what you're willing to pay. The free tier only supports JavaScript and NestJS.

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.

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.

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

I wonder what the shadow labour costs for doing the SOC2 and other compliance frameworks would be in a year.

For a seed stage company, it costs something like this:

Automation frameworks cost around ~10k

Audit ~ 10k

Tools and other supporting products ~10k

Time spent by team.. priceless

Haha, yes, shadow labour costs are always priceless.

$1900 is definitely too much compared to that.

Let’s do what you said 3 times because the first attempt might not make it.

I am not affiliated with archsense :)

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?

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.

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.

How do they solve the Code-Model gap?

Looks great, but 159 a month to even use the tool at all is an instant no.

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?? :)

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.

It is only dependency management.

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.

So this is visualizing software implementation then, as opposed to architecture?

Yes, not sure why they're using the term "architecture" here. It's a code structure visualizer.

Sure, architecture is the process of actively creating a blueprint, not passively rendering an existing piece of code.

> 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.

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.

Very true. I would call this "code representation", not architecture. Architecture is a different discipline, at higher level than code.

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.

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.

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.

I am sorry, but these busy diagrams are not helpful at all.

Reply on news.ycombinator.com