I will acknowledge this idea is potentially inconsistent with many standard
language practices however I’m interested in discussing the potential benefits
of including this in Swift.
Swift has always had a lot of potential for being the one language (to rule
them all) you code in whether it’s on client or server. However to do this you
still have to implement some sort of bridge between the two systems. Whether
it’s a REST API or web socket you have to step outside of Swift and you have to
step outside of knowable interfaces (I.e., Server.call(api:”/route/users”
withParams:.. <- You just have to know that route and which params it takes,
yes you can wrap your RestAPI in a framework, but someone still has to write
and maintain that framework which is just another bridge).
Here’s an alternative:
```
// Local
remote import “swift://localhost” // URL for framework.
try Session(apiKey:”ABC”)
let results = DataController.searchData(term: “Foo”)
```
```
// Remote
import AnyOtherClass
// remote import “swift://..."
remote class Session {
init (apiKey:String) {
}
}
remote class DataController {
public static func searchData(term:String) -> Array<Data> {
return MySQL.call(“SELECT * FROM data WHERE field LIKE %?%”,
term).map(…);
}
}
remote struct Data {
let field:String
let id:String
….
}
class InternalController {
}
```
When you import a remote framework it fetches the interfaces so you know how
you to interact with the framework. You know which functions you can call and
the parameters for each. There could be key words for synchronous vs
asynchronous and while the actual compiled code would setup TLS calls between
the two those calls could be optimized and compressed to send only necessary
elements of the scope.
This could be looked at similarly to Node.js which features a lot of calling
functions on the server from the client without having to setup a RestAPI.
Perhaps thats a model to look at however node seems to have a lot closer
connection between the client and server and as far as I know there is no code
completion for server calls in any IDE. Beyond that the ability to share
classes is certainly a step above.
Again this may be breaking way too many rules of language development however
as shown above the simplicity it could bring to client server communication may
worth it. It raises many considerations as well, Authentication for private
remote interfaces, versioning, session tracking, cross platform support (as in
other languages, for instance you could have a RestAPI router in addition to
the remote classes).
Weston
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
