4
Lightbend Lagom - Reactive Microservices | @lightbend (www.lightbend.com)
IngramChen 積分 1

play+akka+cassandra

不過它的 API 寫起來很奇怪,而且程式排起來也不會很清楚…

public interface HelloService extends Service {
    ServiceCall<NotUsed, String, String> sayHello();

    default Descriptor descriptor() {
        return named("hello").with(
                namedCall("hello", sayHello())
        );
    }
}

Generic parameter 用到三個… 可讀性已經變差了。

Java 8 Stream API 也是很多 generic parameter (多到四個),但是開發者使用 API 時卻藏得很好,程式碼很乾淨。

lagom 的 API 一時之間很難吃的下去,也許要用 scala 腦去思考?還有,因為 API 大多是 async 的緣故,程式碼也是開始堆了好幾層:

public <Id, Request, Response> ServerServiceCall<Id, Request, Response> authenticated(
    Function<User, ServerServiceCall<Id, Request, Response>> serviceCall) {
  return HeaderServiceCall.composeAsync(requestHeader -> {

    // First lookup user
    CompletionStage<Optional<User>> userLookup = requestHeader.principal()
        .map(principal -> userStorage.lookupUser(principal.getName()))
        .orElse(completedFuture(Optional.empty()));

    // Then, if it exists, apply it to the service call
    return userLookup.thenApply(maybeUser -> {
      if (maybeUser.isPresent()) {
        return serviceCall.apply(maybeUser.get());
      } else {
        throw new Forbidden("User must be authenticated to access this service call");
      }
    });
  });
}

看這些程式碼,我實在吃不下去,上面只有三個 if 邏輯而已,卻要寫成這副德性…

haocheng 積分 0

不過 async 的寫法很容易會寫成這樣,用 rxjava 也有一樣問題...

IngramChen 積分 0

所以如果不是很有必要,就不要用 async 開發。我是覺得只有 android 有必要用 async 開發,server 其實只有少部份需要這樣寫。

haocheng 積分 0

其實也很難混用,要嘛就全部 sync ,不然就全部 async ,混用更難讀...