Airframe Development Roadmap for 2022　Airframe Roadmap

We only have three major goals for 2022: RPC, Documentation, and Scala 3.

• Past roadmap for 2021 Milestone: Airframe 21 #1375

Finalizing the RPC Framework

Airframe RPC has been battle tested and becomes comfortable enough for building production applications. It's time to standardize RPC programming, error handling, logging, etc. If you are interested see also the presentation: Unifying Frontend and Backend Application Development with Scala (ScalaCon 2021) (slides)

• Standardize RPC exception handling airframe-rpc: Error handling with RPCException #2140
• Add a standard client-side request/response logging for instrumenting HTTP/RPC call activities at ease airframe-rpc: Client side logging #2142
• Improve gRPC logging airframe-grpc: Log response time and status code  #1820
• OpenAPI generation improvement to support multiple-languages at ease airframe-rpc: Improve OpenAPI generation #2150

Better Documentation

So far, we only have documentations for individual modules and these documentations are bit isolated. To have a comprehensive view of these modules, we need a walk-through documentation so that we can learn how to build applications using Airframe starting from logging, web application development, RPC, runtime DI, building UI with Scala.js, etc. #2169

Better Scala 3 Support

Related: #1077

Scala 3 does not fully support runtime-reflection. Airframe is heavily using airframe-surface (e.g., Surface.of[X]) to extract type information (constructor parameters, generic types, alias, and public methods) at runtime.

There are several challenges:

• Recursively resolving nested types hits an error especially when loading shapes from a class name airframe-surface: ReflectSurfaceFactory.ofClass(cl) causes illegal multithreaded access to ContextBase error in Scala 3 #1698
• We need to use split the source code folder between Scala 2 and Scala 3 if runtime-reflection package scala.runtime.universe is used.
• If we rely on runtime-reflection, compiling applications using Airframe into native applications (e.g., Scala Native, GraalVM) need some tricks.
  • This makes difficult to use some of airframe-modules in serverless applications (e.g., AWS lambda)

The usage of runtime-reflection in Airframe is quite limited and it already can support Scala.js, so even if we only use compile-time only macros for extracting type information, there should be no major obstacles. Some redesign of Surface (or recreation as a new module) might be necessary to effectively limit the scope of Surface.

Details: How Is Surface loaded from a given class?

A notable usage of runtime-reflection in Airframe is Surface.ofClass(cl), which is used in AnyCodec for resolving Surface from a given class:

This feature is added in #1098 and used for encoding RPC argument classes in the logs. Another usage is scanning Route classes in airframe-http for finding RPC APIs from the class path.

To avoid using runtime-reflection, we need a way to pre-register Surfaces of these classes that need to be serialized. An approach for providing runtime-reflection for Scala 3 can be found in https://github.com/gzoller/scala-reflection, but without a help from Scala compiler plugin, the performance for looking up type information will be quite slow.