I looked into the lemmy src, and what is supposed to be a CRUD API has several layers of abstraction. Same at work, where we have hexagonally structured apps where following any sort of logic is literally impossible. What are your thoughts?
The thing about larger-scale architecture is that you can be correct in any specific sense that it's more than you need, but when you actually try to make the thing across a development team, you end up there because the code reflects the organization, and having it broken up like that lets you more easily rewrite your previous decisions.
At the small scale this occurs when you notice that the way in which you have to approach a feature is linguistically different - it needs conversion to a substantially different data structure, or an interface that compiles imperative commands from a definition. The whole idea of the database having a general purpose structure and its own query language emerges from that - it lets you defer the question of exactly how you want to use the data. The more configuration you add, the more of those layers you need. When you start supporting enterprise-grade flexibility it gets out of control and you end up with a configuration language that resembles a general purpose programming environment, but worse.
In the end, the point of the code is to help you "arrive in the future" in some sense - it's instrumental, the point of automating it is to improve the quality of your result by some metric(e.g. fewer errors). For a lot of computations, that means you should just use a spreadsheet - it aids the data entry task, it automates enough of the detail that you can get things done, but it also gets out of the way instead of turning into a professionalized project.
The hexagonal architecture or onion architecture is oversimplified as having everything bolt onto a core of business logic via designed and designated interfaces to abstract away implementation details on either side.
Say you have a web app which takes requests from the outside world and based on those requests it performs some business logic (tracking accounts, orders, etc).
In hexagonal architecture you'd maybe implement such a thing like:
What this lets you do is split apart the app at the interfaces into separate modules which can be reasoned about and tested separately.
End of the day you don't care what is happening on the other side of the interface as long as whatever it is follows the interface specification.
Building applications like this meants that if we wanted to extend our app with an API and a Real-time Websocket service, we can (usually) just write a handler to turn that request into a command for the command interface and be done with it.
cool, thanks for the explanation :) i am familiar with onion architecture, i just never heard of hexagonal arch. i assumed there would be some difference
basically you make an onion, where the core domain logic handles well, your actual logic the adapter handles requests and makes them understandable for your core part the port part is your db or anything like that, it's usually an implementation of an interface
I don't see the problem with modularizing code. Any proper IDE will make following through the crates as transparent as if it were all in the main src folder. It's not like there's some complicated indirection at play or anything, it's direct references and invocations.
Given this project has been around for many years, (looking at their releases), I wouldn’t say it’s “early” to modularize their code. It’s very common practice to abstract out / move commonly executed code into their own packages and modules to allow ease of reuse across the app. This way if an entire subpackage needs to be moved or deleted, all related code could be affected at once and code which references it, simply needs to be edited. Typically these places to edit are much easier to handle since most of “calling code” wouldn’t touch the modularized / abstracted code, only their callables.
I've coded most of my applications in that structure. It makes changing and testing things sane. Plus, if I need to make a large backend change, I can keep the abstractions compatible and have the rest of the app not notice.
There are a few possible reasons for that, but the main ones are:
The architecture may be from the rococo (filled with pretty, but ultimately useless and confusing "decorations") or surrealist (tenuous relationship to reality) schools. This would make it difficult to grasp for anyone but the people involved from the beginning.
The architecture could be perfectly sound, but for some reason, you are having trouble putting it all together. The most common reason for that is a lack of training and documentation.
Not dumb, untrained or not yet sufficiently skilled in this particular area. While you bear some responsibility for getting up to speed, I would argue that it is still their issue if they are not providing the necessary resources. With something like lemmy, you are probably on your own for finding and making use of those resources. But I would be surprised to learn that those resources don't exist. I haven't looked, but there must be some kind of documentation written by someone and a community of like-minded people. Maybe even some tutorials.
That said, some people will always struggle with certain kinds of abstraction or multiple layers of abstraction. For myself, one thing that I find helpful is to view each layer as an API that I'm targeting or a library that I'm using. In those cases, you never really worry about how things get done in the background.
Do you really have any idea how the keywords that solicit user input work? Not likely. Even if you do, you still completely ignore the fact that you know it while writing a line of code that solicits user input. That is a layer of abstraction that you use regularly without even thinking about it. A good architecture allows the same kind of reasoning about your code.
Absolutely not! I'm not sure anything in any field is so trivially simple that it can be grasped just by looking at it. Getting even minimally competent in anything requires both study and practice.
The good news is that study and practice are skills worth acquiring, because they are useful in any endeavour.
The great news is that study and practice are what's needed for mastery, too, so once you start your journey, you can can continue as far as you want.
Well, sure, it's frustrating. I haven't looked at lemmy code, so maybe it is a dumpster fire. But I've been programming since about 1980, and I still stumble more than I'd like, even when I'm the one who wrote the crap I'm trying to figure out. :)
If you've only been developing for 3 years then you're not much beyond a junior. Nobody (least of all yourself) should expect you to be able to just sit down and grok a rust codebase using actix.
What you appear to be lacking right now is patience and experience. They both come with time.
In general, I've been doing this for like 5 or 3 years.... this as in programming. Actix-web is no problem here, it's just the architecture that seemed to stump me.
I apologize for earlier, but depression is a real bitch at times, and I can have these moments where I just... go off the rails.
Add comment