101–109 of 109 posts
Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)
Why? Why choose Swift over a language with an established framework ala python, ruby, ASP.NET, Node.js ?
No, I don't want to share models between the client and the server. I want an API dependency between them, a code dependency is actually worse. Why should the frontend change when the backend changes it´s abstractions? I want to change them independently, because they have different constraints and dependencies. If you are implementering your database schema in the frontend, you´re doing it wrong. An API is a view ag…
There may be technologies like protobuf to define those structures in one place, but i can still imagine there are cases where it could be useful ( business rules and validation, etc).
Earlier quoted context omitted.
> How does that make presenting their product propaganda any more so than any other product presentation? Heck, they even use it themselves for their backend. There is that aspect, sure. But what I wanted to point out is the irony of IBM promoting Swift since there isn't really any obvious advantage of using it full stack unless you are using iOS. Which happens to be the product of their new friend. That is all.
IBM has already ported Java over to the z Systems platform. So why is them also supporting Swift a bad thing here?
What I'm saying is that moving to swift full stack is only beneficial if you are using iOS or macOS on your clients.
No, I don't want to share models between the client and the server. I want an API dependency between them, a code dependency is actually worse. Why should the frontend change when the backend changes it´s abstractions? I want to change them independently, because they have different constraints and dependencies. If you are implementering your database schema in the frontend, you´re doing it wrong. An API is a view ag…
I completely agree with the general point, however at the minimum this lets client and server share the same exchanged models ( what the server sends to the client is defined once, as well as the opposite). There may be technologies like protobuf to define those structures in one place, but i can still imagine there are cases where it could be useful ( business rules and validation, etc).
Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical. Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)
While Swift will compile on different backends now, XCode is still the premiere Swift dev environment and will be for a good while. So a non Mac Swift dev won't be having a great time. The target market is really iOS devs who want the same language on the back end. That's a perfectly reasonable engineering goal for an iOS-first shop. But they're a vocal group and like to hype up server Swift as the next big thing for…
I don't know what the future plans are for that ...
For Swift on the server you only need an editor like Sublime, Atom, or whatever suits your fancy. That's it, nothing else. Get one of the most popular frameworks like Kitura, Vapor, Perfect, Zewo or the dozens of smaller ones and be ready to deploy to Heroku, Bluemix, AWS, Google Cloud, Digital Ocean in no time. It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a coup…
you always need at least compiler/interpreter to execute your code... unless write bytecode in your editor