• Moc@lemmy.world
    link
    fedilink
    arrow-up
    9
    arrow-down
    2
    ·
    edit-2
    10 months ago

    Someone in the thread mentioned that to get the benefits of micro services in a monolith, you can use a linting rule to prevent dependencies across modules

    Share data, not state.

    In Rust this is a pretty good use-case for channels, which can be used to send messages across threads.

    • lysdexic@programming.dev
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      10 months ago

      Someone in the thread mentioned that to get the benefits of micro services in a monolith, you can use a linting rule to prevent dependencies across modules

      I don’t think that makes any sense. The main benefit of microservices is organizational, more specifically how a single team gets to own all aspects of developing, managing, and operating a service.

      Lower in priority, there’s enabling regional deployments and improved reliability.

      How are linting rules even expected to pull that off?

      • Moc@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        10 months ago

        Should have explained my viewpoint. Most startups should not do micro services.

        Using linting to prevent coupling between modules can give you some of the benefits of micro services without going all in.

        • lysdexic@programming.dev
          link
          fedilink
          English
          arrow-up
          2
          ·
          10 months ago

          Using linting to prevent coupling between modules can give you some of the benefits of micro services without going all in.

          My point was that modularizing an application and decoupling components does not, by any mean, give any of the benefits of microservices.

          The benefits of microservices are organizational and operational independence. Where do you see coupling between components to play a role in any of these traits?