Hi everyone,
The first goals for server side are building networking, security, and HTTP/WebSocket parsing. Core components are super important but they are just components. Adding those up will not guarantee success. So I just want to suggest to make the design in another way. It is a little bit trickier but is much more efficient.
I consider multiple levels of design:
1. Swift ideology: safe, fast, expressive.
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.
3. System architecture (of server side or anything else) on top of the basic set of designing rules. I assume that there is one for server side somewhere. I suggest making it more visible.
4. Design of components and tools. I think that networking, security, and HTTP/WebSocket parsing are on this level.
Each level may not be engraved in concrete and must be reconsidered iteratively (maybe except for the first one).
So what do you think?
Thanks,
Anton Mironov
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.
···
On Nov 6, 2016, at 2:10 PM, Anton Mironov via swift-server-dev <swift-server-dev@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.
--
Brent Royal-Gordon
Architechies
+1
The infrastructure needs to be able to support each type of web framework, while still providing Swifty APIs for networking. Handling (or explicitly not handling) asynchrony will be an interesting part of this I think.
···
On Nov 7, 2016, at 12:27 AM, Brent Royal-Gordon via swift-server-dev <swift-server-dev@swift.org> wrote:
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.
As you say, those primitives must be well-designed: criterion A, criterion B, criterion C. Primitives must be flexible to accommodate: paradigm A, paradigm B, paradigm C. That still looks like design guidelines to me.
···
7 лист. 2016 р. о 10:27 Brent Royal-Gordon <brent@architechies.com> написав(ла):
On Nov 6, 2016, at 2:10 PM, Anton Mironov via swift-server-dev <swift-server-dev@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
Architechies