[swift-server-dev] Another way of designing server side

Brent Royal-Gordon brent at architechies.com
Mon Nov 7 02:27:34 CST 2016

> On Nov 6, 2016, at 2:10 PM, Anton Mironov via swift-server-dev <swift-server-dev at swift.org> wrote:
> 2. A basic set of designing rules on top of an ideology. For example (you might completely disagree with all of them, but these are just an example):
>    - prefer a functional approach (purity, lambdas, monads and etc)
>    - prefer a reactive approach
>    - carefully consider use of class inheritance
>    - mutability only when you need it
>    - build APIs that are hard to break or use in a not intended way
>    - TODO
>    I really miss these. On my opinion, the basic set of rules must be well discussed, written down, made public.

I disagree with this.

A web framework ought to be opinionated and consistent, and thus should have a strong, single-paradigm design. But the working group is not designing a web framework; it's designing the *infrastructure* for web frameworks. Designers should be able to take the output of this group and use it to make a framework that matches their vision of web programmer. One developer might design a traditionally functional framework; another might design a functional reactive one; a third might design a class-based MVC framework; a fourth might design a highly dynamic "convention over configuration" framework; a fifth might be very careful to file all the edges off. All of them should be able to use the networking, security, protocol, etc. primitives this group designs.

Obviously we should make sure the primitives are well-designed and flexible enough to accommodate many paradigms. But that's different from engineering paradigm opinions into them.

Brent Royal-Gordon

More information about the swift-server-dev mailing list