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?
mind if i ask what ‘hexagonally structured’ means? i have never heard of this and cant imagine what it could be :D
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:
Web app handler -> command interface -> message bus -> command handler (business logic) -> repository interface -> repository (Postgres, mongo, memory, email)
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
Assuming I’m remembering correctly, they’re both very similar. To the point that they’re basically the same concept by different sources and therefore have some wiggle in interpretation
adapter-core domain logic- port
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’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.
I don’t know every time I’ve tried to change a beast like that, it was hard and frustrating.
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.
So either their issue or I’m dumb, probably the latter.
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.
Isn’t that just saying that I just am not good at my job? I mean, shouldn’t I be able to just grasp it by just looking at it?
Like I want to contribute to it, but it feels so overwhelming and hard to find anything I need.
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.
I’ve been doing this shit for 3 years, and yet I have issues grasping fucking lemmy src
I apologize for my harsh tone, but you can see why I’m upset that I can’t read it properly.
I just had a look at the Lemmy source and it seems pretty straightforward, what exactly are you having issues with?
the fact that there are CRUD COMMON and API crates???
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.
is it kinda early for them to modularize their code?
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.
Fair enough
Is that a problem though?
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.
Casey Muratori talks about this kind of thing in some depth.
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.
Yes it does. It only makes testing things that should not exist otherwise easier.
things that should not exist
Can you elaborate on this?
As in, what things shouldn’t exist?
If you know how hex arch works and the dir structure is documented it should not be hard to follow a code path all the way through the stack quickly.