Great article about how to start off a project and how to modularise your code. But it's not about architecting an API. This isn't architecture. Please don't call it architecture, you'll confuse people. If you want to talk about the architecture of an API, at the very least that would require a huge amount more background, a much more complex real-world based scenario, a lot of discussion, and a series of articles with diagrams.
Nonsense...so what is your definition of architecture then? Giving background and a real world example over and above what's written here would all of a sudden qualify this post of being worthy of being labelled a architecture discussion? Utter nonsense.
Good article on how to architect your node apps. Thanks Thiago.
Architecture isn't how to organise stuff. You don't tell your kid to "go upstairs and architect your room". Architecture is an altogether higher level discipline. As I said, it's a good article. But it's not about architecture.
There is no professional body (especially with regards to JS dev) that will define exactly what "architecture" is and isn't. For me, architecture is a very loose term that can mean many things, code structure being one of them. Personally, when I think "application architecture" then the data model is fundamental and most important - but the code structure is also a part of it (as is choice of technology etc).
I think we might actually agree (that architecture is a loose and general term), I just felt it unnecessarily pedantic to moan about the title of this post when it's perfectly "fine".
"Structuring your Node.js code in a better way" just doesn't have the same ring to it!
I disagree. That is one interpretation of an application architecture. However is not the only one. I wrote my Master Thesis on exploring the concept of software achitechture and among the conclusions is that, by necessity, the scope of "the architecture" is not always tangible or strict. It can (but more often is not) be defined for one single functionality, for the database, for the logging, or for every and any part of the application.
The tangible documentation of the architecture is usually referenced on older literature, but modern software solutions have extrapolated multiple layers of complexity and tend to be higher level, thus defining the architecture on a separate set of documents, ideas or mandates is less and less practical (where do we stop if we have an N number of references, do we specify those as well? do we use partial documentation of "obvious" dependencies? what if we need to take over one of those dependencies? where do we stop the abstractions? when is it more pragmatic to make an actual implementation that is self documenting?).
Often architecture is interpreted as "how to organize the project" and for many authors that means the way the project is literally organized on a file system is an implicit declaration of it's architecture. Under that construct, it is completely valid to say that this article defines the application's architecture in it's own realization.
The purpose of my thesis was to explicitly demystify and make the concept of architecture less esoteric, since is supposed to be a tool for a more concrete plan of realization of an application. Another conclusion is that things like a simple diagram could define an architecture and that any author can express it as detailed and using as many tools as the intention (which is express the organization for a purpose) require or was practically desired. Under those circumstances, declaring that this cannot be called architecture is up actually up to the author and whoever receives this information, if it helps clarify how the application works, then definitely serves as the architecture. The recipient of the information cancan request a more concrete definition of any of the parts (but I can hardly find a more concrete way than the code explained). Architecture in software serves the purpose of communication. The tools could be the discussion, articles or diagrams, but that on their own do not exclusively define the architecture.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.