Deprecating Swish?

[sidraval]

After Encodable/Decodable landed in Swift and the removal of Argo as a dependency of this project, I feel like this codebase doesn't do all that much. It provides a little bit of structure and has some niceties, but I'm not sure I'd reach for it on my next project, for example. I don't think I'd like to spend any time maintaining the project going forward.

Curious what contributors past and present think - cc @sharplet @klaaspieter @gfontenot

[sharplet]

I think most of my usage of Swish could probably be replaced by the combination of a promises/reactive library and some convenience methods. For example, with ReactiveSwift:

let fetchModel = URLSession.shared.reactive
  .data(with: modelRequest)
  .attemptMap { data, _ in JSONDecoder().decode(Model.self, from: data) }

I don't think I'm opposed to this, but would love to hear what others think.

[sgoodwin]

I'm a big fan of Swish and use it on every project where I have a choice. I'd rather not have to reach for a whole new paradigm to do what this small, focused library does so nicely. It's ok that it doesn't do very much, that's a good kind of library, the kind that doesn't take 2 years to remove from your app if you need to later.

[gfontenot]

I would also not like to see this lib deprecated. I'm looking forward to using it on a project relatively soon. I agree with @sgoodwin that the fact that it does so little is a positive, not a negative.

If the issue here is that nobody at thoughtbot wants to maintain this anymore (which is reasonable), then I'd argue for splitting this out into a new org under community control. I'd be happy to take the reigns there.

[eliperkins]

+1 to not deprecating it.

I don't think the goal of this repo ever was to strictly do encoding and decoding, but rather to abstract away request creation, request performing, and response resolving. While these things may include encoding and decoding JSON, I don't think that's the only thing that Swish is able to do.

[klaaspieter]

Please don't deprecate this. I like that this is a small set of protocols. It's a good place to start that is easy to make more complicated over time.

@gfontenot in case you do pick this up, let me know if I can do anything to help. I was going offer the same but I'm not sure if I have enough spare cycles to take on full maintenance.

[sgoodwin]

I volunteer as tribute to maintain this if you need help Gordon.

[sidraval]

Not deprecating, woo hoo!