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