Hi all,
I'm very excited for the formation of this area of development. While I might consider myself primarily a macOS and iOS app developer, I've done my fair share of Java webserver development, as well as a lot of small embedded development. You can't make a non-trivial app these days without some kind of server-side support.
I realize the initial focus of this working group is fairly low-level support for server-side development, but in much the same way that Swift development is made richer by the availability of the robust Swift Standard Library, so to is web development.
In my estimation, the most current iterations of Spring.io, and the up-and-coming Baratine.io*, offer insights into powerful web development paradigms that I'd like to see streamlined and Swiftified. While this group is avoiding such a high-level, it strikes me that thinking about the high level can greatly inform how the low-level APIs evolve.
One of the things that Java frameworks take advantage of is Java's rich introspective ability, and particularly lately use @Annotations as a way to simplify configuration and reduce boilerplate code. This typically expands into dynamic creation of proxy classes, and I'm not sure how Swift's introspection and code-generation capabilities stack up. I know Java-style @Annotations are on the roadmap in some form, but not until after ABI stability.
Unfortunately, I think that means any Swift webapp framework will suffer problems similar to that of Spring: a clunky datafile-based configuration structure that becomes obsolete when more introspection features become available, creating a wealth of out-of-date instructional material online and a lot of technical debt.
Hopefully I'm being overly pessimistic, and we're able to enjoy elegant, powerful, scalable web development in the near future.
In any case, I hope I can make a positive contribution.
ยทยทยท
--
Rick Mann
rmann@latencyzero.com
*Baratine is incredibly performant and substantially relieves the developer from the persistence burden, but IMHO currently is quite verbose when it comes to implementing something like REST endpoints, and has a very steep learning (grokking?) curve.