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