this post was submitted on 23 Jan 2024
362 points (96.6% liked)

Fediverse

28499 readers
338 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).

If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!

Rules

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy

founded 2 years ago
MODERATORS
 

Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy's Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of choice.

you are viewing a single comment's thread
view the rest of the comments
[–] BURN@lemmy.world 3 points 10 months ago (1 children)

I find that Java is overly Verbose, but it’s much better than the alternative of underly verbose.

Java really follows the single class for single functionality principle, so in theory it makes sense to have these located in different classes. It should probably be abstracted to a shared method, but it shouldn’t be in the same file.

At least to me this looks like simplicity, but I’ve been writing Java in some capacity since 2012.

[–] Corngood@lemmy.ml 6 points 10 months ago

It's not just the visible complexity in this one file. The point of it is to keep a subscriber count in sync, but you have that code I referenced above, plus:

LinkPersonCommunityCreatedEvent LinkPersonCommunityDeletedEvent LinkPersonCommunityCreatedPublisher LinkPersonCommunityDeletedPublisher

And then there are things like LinkPersonCommunityUpdated[Event/Publisher] which don't even seem to be used.

This is all boilerplate IMO.

And all of that only (currently) serves keeping that subscriber count up to date.

And then there's the hidden complexity of how things get wired up with spring.

And after all that it's still fragile because that event is not tied to object creation:

  @Transactional
  public void addLink(Person person, Community community, LinkPersonCommunityType type) {

    final LinkPersonCommunity newLink = LinkPersonCommunity.builder().community(community)
        .person(person).linkType(type).build();
    person.getLinkPersonCommunity().add(newLink);
    community.getLinkPersonCommunity().add(newLink);
    linkPersonCommunityRepository.save(newLink);
    linkPersonCommunityCreatedPublisher.publish(newLink);
  }

And there's some code here:

https://github.com/sublinks/sublinks-api/blob/main/src/main/java/com/sublinks/sublinksapi/api/lemmy/v3/community/controllers/CommunityOwnerController.java#L138C31-L138C50

    final Set<LinkPersonCommunity> linkPersonCommunities = new LinkedHashSet<>();
    linkPersonCommunities.add(LinkPersonCommunity.builder().community(community).person(person)
        .linkType(LinkPersonCommunityType.owner).build());
    linkPersonCommunities.add(LinkPersonCommunity.builder().community(community).person(person)
        .linkType(LinkPersonCommunityType.follower).build());

    communityService.createCommunity(community);

    linkPersonCommunityRepository.saveAllAndFlush(linkPersonCommunities);

that is able to bypass the community link service and create links in the repository directly, which would presumably not trigger than event.

Maybe there's a good reason for that, but it sure looks fragile to me.