How to build @Service architecture with Spring and MongoRepository?

Question

Java

Hello, I have a problem in building architecture. I want to create a "Short Link Service". The idea is this: three links come with a get request, on different controllers - a link to the iOS application, Android and PWA/SPA. After accepting the links, a check is made with the database to see if there are similar links in the database, if there are - to return the finished short link. If not, create a document in MongoDB, fill in the link fields, and return a short link. During the transition to a short link, the user's device is determined. Accordingly, if it was an Android device, the redirect goes to the play market, etc. The question is how to make a single @Service that will calculate business logic for different controllers that receive different links, which are mapped to the respective fields and what would that look like? My version implies three different servers, for each controller, which is not correct. Which option would be the best solution?

Answer 1

@Service is a class. It can have many methods, and each controller will call the right one. Each will have its own, unique part, and the saved will go through a common method. for example

// В Андроид контроллере
service.processAndroidLink(link)
// В iOS контроллере
service.processMacLink(link)

// в самом сервисе будут такие методы:
public void processAndroidLink(URL link) {
  // подготавливаем данные для записи
  URL androidLink = link;
  URL iosLink = createIosLink(link);
  URL webLink = createWebLink(link);
  var doc = prepareDocument(andriodLink, iosLink, webLink);
  save(doc);
}
public void processWebLink(URL link) {
  // подготавливаем данные для записи
  URL androidLink = createAndroidLink(link);
  URL iosLink = createIosLink(link);
  URL webLink = link;
  var doc = prepareDocument(andriodLink, iosLink, webLink);
  save(doc);
}
private void save(document) {сохраняем в MongoDB}
}

It is clear that instead URLit can be any other type.
Note that the save method is separated from prepareDocument : it's easier to test, they have different scopes, and prepareDocument can be used by someone else in the future.
In this case, I deliberately bypassed the issue of checking the existence of a link. You may want to make this a separate process. Maybe embed in processAndroidLink.