Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alamofire: HTTP Networking in Swift

github.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Alamofire: HTTP Networking in Swift

#11

Post by altyus »

krschultz wrote: post #6
treve wrote: post #4

Congrats on this release! However, I think the library name is a bit of a poor choice. I don't want to take away your thunder, I just picked this post to do my rant :). There seems to be a lot of new general-purpose libraries with very poor non-descriptive names coming out. Whenever I need to dive into a new codebase, in a language and ecosystem I'm unfamiliar with, it's extremely hard to figure out which dependency…

The alternative is non-memorable names. I can't tell you how many android-async-image-loader libraries there are. It's a lot easier to remember 'Picasso'. It's also a lot easier for me to Google for 'Picasso Android' and get relevant results.

I think Mattt can get away with this as he has the most well known open source library for cocoa development.

Re: Alamofire: HTTP Networking in Swift

#12

Post by Void_ »

treve wrote: post #4

Congrats on this release! However, I think the library name is a bit of a poor choice. I don't want to take away your thunder, I just picked this post to do my rant :). There seems to be a lot of new general-purpose libraries with very poor non-descriptive names coming out. Whenever I need to dive into a new codebase, in a language and ecosystem I'm unfamiliar with, it's extremely hard to figure out which dependency…

I wonder how much this matters to other developers –

but I, at least subconsciously, when faced with a library choice, take into account things like:

- Simple, pretty name (Alamofire is very nice-sounding and memorable – even feels like overkill, author should've saved it for an iPhone app or something.)

- The pretty logo

- The perfect use of Markdown (I'm so obsessed about using `` around everything that looks like code it feels like a psychological condition)

- Clear structure of README

- Simple examples with syntax highlighting

There must be correlation between the presentation and quality of the source code!

Re: Alamofire: HTTP Networking in Swift

#13

Post by wahnfrieden »

mythz wrote: post #5
matttthompson wrote: post #2

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

Looks like a great lib with a nice API, thx. Was there any reason why you chose callbacks over a Promise-like pattern for the async responses? Also do you know of any good HTTP Server libraries that will let you develop simple HTTP JSON services in Swift?

See Moya for a lib built on top of AlamoFire that adds reactive signals (fulfilling the promises use case): https://github.com/AshFurrow/Moya

Re: Alamofire: HTTP Networking in Swift

#14

Post by Void_ »

matttthompson wrote: post #2

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

Is there any way to add custom HTTP header yet? This would make for a nice API:

  Alamofire.request(.GET, "http://httpbin.org/get")
           .header("custom-header", "value")

Re: Alamofire: HTTP Networking in Swift

#15

Post by matttthompson »

Void_ wrote: post #14
matttthompson wrote: post #2

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

Is there any way to add custom HTTP header yet? This would make for a nice API: Alamofire.request(.GET, "http://httpbin.org/get") .header("custom-header", "value")

The short answer: Use the version of `request` that takes a `URLRequestConvertible`, and specify the header fields in that.

The long answer: Custom headers on a per-request basis are a bit of a red herring, from an API design perspective. In reality, most use cases boil down to one of three, which are taken care of in other ways:

- Default headers, such as `User-Agent`, are specified in `NSURLSessionConfiguration -HTTPAdditionalHeaders`. - `Authorization` headers, which are handled by `NSURLCredential` and `NSURLAuthenticationChallenge`. - `Content-Type` headers, which are handled by `ParameterEncoding`.

This is why Alamofire is designed the way it is.

Re: Alamofire: HTTP Networking in Swift

#16

Post by matttthompson »

myko wrote: post #9
matttthompson wrote: post #2

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

In the README it looks like using the ObjC AFNetworking is suggested if one wishes to do multipart http requests, I assume this is up to date and Alamofire doesn't support this at this time?

Yes, that's correct.

Re: Alamofire: HTTP Networking in Swift

#17

Post by treve »

altyus wrote: post #11
krschultz wrote: post #6

Earlier quoted context omitted.

The alternative is non-memorable names. I can't tell you how many android-async-image-loader libraries there are. It's a lot easier to remember 'Picasso'. It's also a lot easier for me to Google for 'Picasso Android' and get relevant results.

I think Mattt can get away with this as he has the most well known open source library for cocoa development.

I'm not a cocoa developer, and I don't really know who matt is, or what library that may be ;). Once I'm a seated cocoa developer I probably will though, but then my general point no longer really applies.

Re: Alamofire: HTTP Networking in Swift

#18

Post by matttthompson »

mythz wrote: post #5
matttthompson wrote: post #2

Creator of Alamofire here. Just pushed the 1.0.0 release. Happy to answer any questions you might have.

Looks like a great lib with a nice API, thx. Was there any reason why you chose callbacks over a Promise-like pattern for the async responses? Also do you know of any good HTTP Server libraries that will let you develop simple HTTP JSON services in Swift?

> Was there any reason why you chose callbacks over a Promise-like pattern for the async responses?

Deeply-nested networking callbacks are a code smell, and I find that promises often do more harm by hiding those smells—or worse, obscuring the flow itself. In practice, Alamofire is mostly going to be single or at most nested two levels deep anyway.

Re: Alamofire: HTTP Networking in Swift

#19

Post by matttthompson »

treve wrote: post #4

Congrats on this release! However, I think the library name is a bit of a poor choice. I don't want to take away your thunder, I just picked this post to do my rant :). There seems to be a lot of new general-purpose libraries with very poor non-descriptive names coming out. Whenever I need to dive into a new codebase, in a language and ecosystem I'm unfamiliar with, it's extremely hard to figure out which dependency…

You make some good points, and I agree to caution against names that bear no semantic relationship with their purpose. My justification of Alamofire is that it reflects the history of the project, which traces back from AFNetworking to Gowalla (formerly Alamofire, Inc.), the product for which it was originally developed.

Re: Alamofire: HTTP Networking in Swift

#20

Post by treve »

matttthompson wrote: post #19
treve wrote: post #4

Congrats on this release! However, I think the library name is a bit of a poor choice. I don't want to take away your thunder, I just picked this post to do my rant :). There seems to be a lot of new general-purpose libraries with very poor non-descriptive names coming out. Whenever I need to dive into a new codebase, in a language and ecosystem I'm unfamiliar with, it's extremely hard to figure out which dependency…

You make some good points, and I agree to caution against names that bear no semantic relationship with their purpose. My justification of Alamofire is that it reflects the history of the project, which traces back from AFNetworking to Gowalla (formerly Alamofire, Inc.), the product for which it was originally developed.

Ah I didn't realize the link to the AF in AFNetworking.

For what it's worth, I do love how the name sounds :)

Post reply on HN