Skip Navigation

Posts
130
Comments
162
Joined
3 yr. ago

  • What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service.

    We only get this if we do microservices correctly. That's more or less the whole point of my comment. In many cases, teams rush into splitting their monolith into smaller chunks and call it a day. Without proper monitoring, orchestration/choreography, service boundaries, tooling, etc. microservices will drag a team into territories where they will lose control.

    Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code [...]

    No, I don't believe that. However, I also don't believe people who write spaghetti code will start writing better code just because now they are writing smaller components. If the team has good coding hygiene, they will produce good code whether it's monolith or microservices. But you have a point. If we are talking about components that are 200LoC, it's more difficult to produce spaghetti (or easier to recover from it). I'm not sure that's the norm, though.

    As a final note: I'm not saying microservices are bad, or monolith is better than microservices. I'm just trying to introduce some nuance. I have been part of a microservices transformation and I think it was successful. But we met with many challenges along the way that were not immediately obvious from the beginning. To quote one of the pioneers of microservices architecture:

    Don’t think of adopting microservices as flipping a switch; think about it as turning a dial. As you turn that dial, and have more services, you’ll hopefully have more opportunity to get the good stuff out of microservices. But as you turn up that dial, you’ll hit different pain points as you go. (Sam Newman, Monolith To Microservices)

    • Linus Torvalds
    • Kent Beck
    • Dylan Beattie
    • Ian Cooper
    • Simon Brown
    • Martin Fowler
    • Daniel Terhorst-North
    • Sam Newman
    • Andy Hunt
  • I think this is a good rule-of-thumb in general. But I think the best way to decide on the correct coverage is to go through uncovered code and make a conscious decision about it. In some classes it may be OK to have 30%, in others one wants to go all the way up to 100%. That's why I'm against having a coverage percentage as a build/deployment gate.

  • I see that you have the following line in your bot:

     typescript
        
    auth: @me.secrets.lemmee,
    
      

    Does that mean you are storing the JWT in your secrets? Doesn't that mean that it will expire after some time? Wouldn't it be better to get the JWT before performing the action? Something like this: https://www.val.town/v/canpolat.getLemmyJwt

  • Removed

    White Box Testing

    Jump
  • Most of the time 100% code coverage is just a waste of time.

  • Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.

    Microservices architecture by itself doesn't guarantee making anything better. Making services smaller doesn't automatically make easy-to-understand code. That's why a lot of companies that didn't pay attention to what they are doing went from monolithic architecture to "distributed big ball of mud" or "distributed monolith". Just like any other architecture pattern, for microservices to work, the team needs to make conscious decisions to overcome the challenges specific to their architecture.

  • Thanks for sharing. This is a great way to write simple bots without dealing with hosting.

  • I see, thanks. That's a test instance and therefore there may be other restrictions related to federation for that particular example.

  • Did you take a look at write freely or other blogging software with native ActivityPub support?

  • This is probably not the correct place to as this and I don't know the inner workings of Lemmy, so forgive the stupid question. Does that mean, for an external post to get a programming.dev ID does someone in programming.dev instance to have been subscribed to the community the post was originally shared? Is that why I don't see any posts at for example https://programming.dev/c/testbot42@voyager.lemmy.ml even though I see them at https://voyager.lemmy.ml/c/testbot42? If that's the case, it sounds like an important limitation.

  • Thanks for sharing this talk. I watched it a few day ago and thought of sharing, but then forgot about it. As pointed out in the video description: "Email is too big to change, too broken to fix... and too important to ignore." The bit about the first marketing email was interesting (video timestamp) and is relevant for our times.

  • The post is what started the whole ADR wave in the industry (I think there was also a conference talk by him). https://adr.github.io/ has a list of resources (templates, articles, examples, tools, etc.).

  • That's a great idea.

  • I would definitely have the "Vital Contributor" badge if it existed.

  • We do that in a meeting. In some cases it may take several meetings before we can make a decision. But I think those are generally fruitful meetings (I don't see them as waste of time). PRs give people a chance to think about these on their own pace, but when it comes to decision making, I feel like meetings actually save time (provided that people are sufficiently informed).

    It's also possible that our ADRs deal with higher level decisions and is therefore easier to establish some sort of a consensus. From your description (especially the "refactoring" bit) I thought maybe you are using ADRs at a level that is closer to code. I cannot really think of our ADRs stopping people from refactoring the code in any way :)

  • I see. I guess if it's accepted then you update the Status in the PR and merge it? There isn't a single ADR format; there are several ADR formats that are successfully being used by different teams. The format I had in mind was the one introduced by Nygard (linked article). In our case, we generally first discuss the topic and then write the accepted decision in an ADR. So, there isn't much room for discussion/voting afterwards.

    But it's good to learn about other people using it in different ways (a learning opportunity for me). It's interesting that you mention ADRs stopping people from refactoring. Do you have any examples you could give?

  • We started with with ADR, but then we also started using RFCs to discuss designs. Having this sort of minimal documentation really helps us in many aspects.