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?

  • r_mode@feddit.de
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 year ago

    mind if i ask what ‘hexagonally structured’ means? i have never heard of this and cant imagine what it could be :D

    • ZeroNationality@lemmy.one
      link
      fedilink
      English
      arrow-up
      7
      ·
      1 year ago

      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.

      • r_mode@feddit.de
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        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

        • ZeroNationality@lemmy.one
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          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

    • Cinnamon@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      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

  • Jamie@jamie.moe
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    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.

    • Cinnamon@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      I don’t know every time I’ve tried to change a beast like that, it was hard and frustrating.

      • jadero@lemmy.ca
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        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.

          • jadero@lemmy.ca
            link
            fedilink
            English
            arrow-up
            3
            ·
            1 year ago

            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.

            • Cinnamon@beehaw.orgOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              1 year ago

              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.

              • jadero@lemmy.ca
                link
                fedilink
                English
                arrow-up
                2
                ·
                1 year ago

                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.

                • Cinnamon@beehaw.orgOP
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  edit-2
                  1 year ago

                  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.

  • VeeSilverball@kbin.social
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    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.

    • Cinnamon@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      1 year ago

      things that should not exist

      Can you elaborate on this?

      As in, what things shouldn’t exist?

  • Stumblinbear@pawb.social
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    I just had a look at the Lemmy source and it seems pretty straightforward, what exactly are you having issues with?

      • key@lemmy.keychat.org
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        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.

          • recursed@lemmy.recursed.net
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            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.