Suppose I have a model called Estimate. I have a Vapor 3 API that I want to return a list of these models, filtered by query parameters. Doing so currently returns a Future<[Estimate]>, which results in the API returning JSON that looks like this:
[{estimate object}, {estimate object}, ...]
Instead, I'd like make it return something this:
{"estimates": [{estimate object}, {estimate object}, ...]}
So, the same thing as before, but wrapped in a JSON object with a single key, "estimates".
According to the documentation, any time I want to return something non-default, I should make a new type for it; this suggests to me I should create a type like:
final class EstimatesResponse: Codable {
var estimates: [Estimate]?
}
However, after filtering I get a Future<[Estimate]> and NOT a pure [Estimate] array, meaning that I couldn't assign it to my EstimatesResponse estimates property. It seems weird to make the type of estimates be Future<[Estimate]>, and I'm not sure how that'd turn out.
How, then, can I return JSON of the correct format?
First, you need to create Codable object, I prefer struct as below. Must implement protocol Content for routing.
struct EstimatesResponse: Codable {
var estimates: [Estimate]
}
extension EstimatesResponse: Content { }
I assumed that you are using a controller and inside the controller, you can use the following pseudo-code. Adjust your code so that val is Future<[Estimate]>, then use flatmap/map to get [Estimate].
func getEstimates(_ req: Request) throws -> Future<EstimatesResponse> {
let val = Estimate.query(on: req).all()
return val.flatMap { model in
let all = EstimatesResponse(estimates: model)
return Future.map(on: req) {return all }
}
}
Related
Introduction
(Apologies if the title is confusing, but I explain the question better here!)
I'm building a networking library that can perform JSON decoding on its responses.
Host apps adopting this library will create enums conforming to NetLibRoute. All that currently does is enforce the presence of asURL:
public protocol NetLibRoute {
var asURL: URL { get throws }
}
In a host app, I have a routing system that enforces API structure at the compiler-level (via enums and associated values) for each endpoint, like this:
enum Routes: NetLibRoute {
case people(Int?)
// Other routes go here, e.g.:
// case user(Int)
// case search(query: String, limit: Int?)
var asURL: URL {
let host = "https://swapi.dev/"
let urlString: String
switch self {
case let .people(personID):
if let personID {
urlString = host + "api/people/\(personID)"
} else {
urlString = host + "api/people/"
}
// Build other URLs from associated values
}
return URL(string: urlString)!
}
}
I also want each enum to be associated with a certain Codable type. I can do that, of course, by modifying the Route protocol declaration to also require a type conforming to Decodable:
protocol NetLibRoute {
var asURL: URL { get throws }
var decodedType: Decodable.Type { get } // This
}
And a matching computed property in my Routes enum:
var decodedType: Decodable.Type {
switch self {
case .people(_):
return Person.self
// And so on
}
}
The Problem
Currently, my networking code has a declaration something like this:
public static func get<T>(route: NetLibRoute,
type: T.Type) async throws -> T where T: Decodable {
// performing request on route.asURL
// decoding from JSON as T or throwing error
// returning decoded T
}
Which lets me call it like this:
let person = try await NetLib.get(route: Routes.people(1), type: Person.self)
However, this redundancy (and potential human error from mismatching route and type) really irks me. I really want to be able to only pass in a route, and have the resulting type be inferred from there.
Is there some way to get the compiler to somehow check the NetLibRoute enum and check its decodedType property, in order to know what type to use?
Ultimately, I want this networking function to take one parameter (a route) and infer the return type of that route (at compile-time, not with fragile runtime hacks or !s), and return an instance of the type.
Is this possible?
Potential Alternatives?
I'm also open to alternative solutions that may involve moving where the get function is called from.
For example, calling this get function on a route itself to return the type:
let person = try await Routes.people(1).get(type: Person.self) // Works, but not optimal
let person = try await Routes.people(1).get() // What I want
Or even on the type itself, by creating a new protocol in the library, and then extending Decodable to conform to it:
public protocol NetLibFetchable {
static var route: NetLibRoute { get }
}
extension Decodable where Self: NetLibFetchable {
public static func get<T>() async throws -> T where Self == T, T: Decodable {
// Call normal get function using inferred properties
return try await NetLib.get(route: route,
type: T.self)
}
Which indeed lets me call like this:
let person = try await Person.get() // I can't figure out a clean way to pass in properties that the API may want, at least not without once again passing in Routes.people(1), defeating the goal of having Person and Routes.people inherently linked.
While this eliminates the issue of type inference, the route can no longer be customized at call-time, and instead is stuck like this:
extension Person: NetLibFetchable {
public static var route: NetLibRoute {
Routes.people(1) // Can't customize to different ID Ints anymore!
}
}
Which makes this particular example a no-go, and leaves me at a loss.
Appreciation
Anyway, thank you so much for reading, for your time, and for your help.
I really want this library to be as clean as possible for host apps interacting with it, and your help will make that possible.
Are you wedded to the idea of using an enum? If not, you can do pretty much what you want by giving each enum value its own type and using an associated type to do what you want.
public protocol NetLibRoute
{
var asURL: URL { get throws }
associatedtype Decoded: Decodable
}
struct Person: Decodable
{
var name: String
}
struct Login: Decodable
{
var id: String
}
struct People: NetLibRoute
{
typealias Decoded = Person
var id: Int
var asURL: URL { return URL(filePath: "/") }
}
struct User: NetLibRoute
{
typealias Decoded = Login
var id: String
var asURL: URL { return URL(filePath: "/") }
}
func get<N: NetLibRoute>(item: N) throws -> N.Decoded
{
let data = try Data(contentsOf: item.asURL)
return try JSONDecoder().decode(N.Decoded.self, from: data)
}
let thing1 = try get(item: People(id: 1))
let thing2 = try get(item: User(id: "foo"))
Where you might have had a switch before to do different things with different Routes you would now use a function with overloaded arguments.
func doSomething(thing: Person)
{
// do something for a Person
}
func doSomething(thing: Login)
{
// do something else for a Login
}
doSomething(thing: thing1)
doSomething(thing: thing2)
I think the problem lays in this function.
public static func get<T>(route: Route,
type: T.Type) async throws -> T where T: Decodable {
// performing request on route.asURL
// decoding from JSON as T or throwing error
// returning decoded T
}
On the first hand, it uses concretions instead of abstractions. You shouldn't pass a Route here, it should use your protocol NetLibRoute instead.
On the other hand, I think that the type param is not needed. Afaik you can get the Type to Decode with the var:
NetLibRoute.decodedType
Am I missing something on this matter?
Apart from that, I'd rather go with struct instead of enum when trying to implement the Routes (concretions). Enums cannot be extended. So you won't be allowing the creation of new requests in client side, only in the library.
I hope I've helped.
PS: Some time ago I made this repo. Maybe that could help you (specially this class). I used Combine instead of async/await, but it's not relevant to what you need.
I want to use Alamofire to query my backend, encode the response using Alamofire's built-in Codable parsing and then publish an extract from the resulting Struct to be consumed by the caller of my API class. Say I have some JSON data from my backend (simplified, but shows the structure):
{
"total": 123,
"results": [
{"foo" : "bar"},
{"foo" : "baz"}
]
}
and the associated Codable Structs
struct MyServerData: Codable {
let total: Int
let results: [Result]
}
struct Result: Codable {
let foo: String
}
I can get, parse, publish, and subscribe all fine with the following:
func myAPI() -> DataResponsePublisher<MyServerData> {
return AF.request("https://backend/path")
.validate()
.publishDecodable(type: MyServerData.self)
}
myAPI()
.sink { response in /* Do stuff, e.g. update #State */ }
What I'd like to do is to publish just the [Result] array. What's the correct approach to this? Should I use .responseDecodable() and create a new publisher (somehow - .map()?) that returns a [Result].publisher?
While I think I understand the reactive/stream based principles my Combine-fu is still weak and I don't have a clear handle on the transformation of one publisher into another (I'm guessing?)
Thanks in advance!
In addition to using Combine API like map, Alamofire offers two publishers on DataResponsePublisher itself.
.result() extracts the Result from the DataResponse and creates an AnyPublisher<Result<Value, AFError>, Never>.
.value() extracts the Value from the DataResponse and creates a failable publisher, AnyPublisher<Value, AFError>.
So depending on what kind of error handling you want, this could be as simple as:
...
.publishDecodable(...)
.value()
.map(\.results)
I have a Codable struct that is part of my app, RemoteData. I’m building a reusable package that will fetch the data and store it in UserDefaults. The data fetching, DataFetcher class has a Codable generic parameter. I am subclassing DataFetcher to pass in RemoteData as the generic param.
// in my app
struct RemoteData: Codable {
var experimentOne: [Variant<[Page]>]
var experimentTwo: [Variant<Bool>]
var experimentThree: [Variant<String>]
}
All of the properties in RemoteData will be arrays of type Variant<T> where T is Codable:
// in my package
public struct Variant<T: Codable>: Codable, VariantProtocol {
public var experimentName: String
public var variantName: String
public var percent: Int
public var value: T
}
I’d like to be able to save this data in UserDefaults. I’d like to perform some filtering on the Variant array to see if this user should see that configuration. I’d like to save the data so that each experiment name is the key and the single variant the user should see is the value rather than the whole array. Although if the whole array is the only option, I’d be ok with that too.
However, since my DataFetcher doesn’t know what the properties are since it is just taking in a generic I don’t think I can do that. My first thought was to create a protocol that RemoteConfig confirms to and that the DataFetcher generic also conforms to.
// in my package, but subclassing in my app to provide url
open class DataFetcher<T: Decodable> {
var remoteConfig: T?
var url: URL
public init(url: String) {
self.url = url
}
func fetchAndSaveData() { ... }
}
That doesn’t work because I then need to specify T in Variant and I will only be able to have Variant arrays of one type.
I’m stuck here and not sure how to move forward.
Some context: JSONAPI is a standard way of writing JSON envelopes that includes stuff like pagination, linking to related objects and links to previous page, next page etcetera. Some of my calls use it, some of them don't. The ones that do use it should use a special parser for the results while the regular results just use the regular JSONDecoder.
I want to write the following code:
func parse<ResultType>(data: Data,
including includeList: String,
with httpResponse: HTTPURLResponse) throws -> ResultType where ResultType: Decodable {
switch ResultType.self {
case is some JSONAPIResult.Type: // Putting `some` here is not supported in Swift!
return try jsonAPIDecoder.decode(ResultType.self, from: data, includeList: includeList)
default:
return try jsonDecoder.decode(ResultType.self, from: data)
}
}
This doesn't build since we can't use some here like we can do in return types. Instead I have to specify the T JSONAPIResult needs to conform to making this thing too complicated.
To give you a complete picture, this is what JSONAPIResult looks like:
// using:
struct JSONAPIResult<T: Decodable>: Decodable, JSONAPIMetaContaining {
let data: T
let meta: JSONAPIMeta
}
What I instead ended up doing was:
// Ducktyping it through a protocol, not ideal but JSONAPIResult wants to know about T
switch ResultType.self {
case is JSONAPIMetaContaining.Type:
return try jsonAPIDecoder.decode(ResultType.self, from: data, includeList: includeList)
default:
return try jsonDecoder.decode(ResultType.self, from: data)
}
}
This code is a bit more brittle than I would like it to be since it depends on that protocol not on the actual type I should send to the jsonAPIDecoder (JSONAPIResult<T: Decodable>). Is there a way to check that ResultType is a JSONAPIResult without dragging it's nested generic T since I don't care about T here.
If I have:
import Moya
import RxSwift
import ObjectMapper
import Moya_ObjectMapper
provider.request(.callApi(id: id))
.mapObject(Thing.self)
.subscribeOn(ConcurrentDispatchQueueScheduler(qos: .background))
.observeOn(MainScheduler.instance)
...
struct Thing: Mappable, Equatable {
var id: String?
init?(map: Map) {
}
mutating func mapping(map: Map) {
id <- map["id"]
}
Making an http api call and getting back json like {"id: "123"} and it's all working great. A new Thing struct is made with the right id. But what if I want to add "flavor" to Thing and hard code {"id: "123", "flavor": "something"}.
i.e. let's just modify the actual http response body and add "flavor": "something" before it gets to the .mapObject method. Where is the right place to tap into that?
And it's not just adding it to the mapping func in Thing because "something" is different for each id. Might be flavor: "something1" and then flavor: "something2". I have this value in the same scope as callApi(id: id) so something like:
provider.request(.callApi(id: id))
.addJSON("flavor", flavor)
.mapObject(Thing.self)
.subscribeOn(ConcurrentDispatchQueueScheduler(qos: .background))
.observeOn(MainScheduler.instance)
But .addJSON is something I just made up. It doesn't exist. But there must be some simple solution for this?
Trying to modify the actual JSON feels dirty and at two low-level. But I've been there so no judging from me if it works. :)
I'd approach it by creating a special version of the Moya.Response extension methods available from Moya_ObjectMapper.
public extension Response {
/// Maps data received from the signal into an object which implements the Mappable protocol.
/// If the conversion fails, the signal errors.
public func mapObject<T: BaseMappable>(_ type: T.Type, context: MapContext? = nil) throws -> T {
guard let object = Mapper<T>(context: context).map(JSONObject: try mapJSON()) else {
throw MoyaError.jsonMapping(self)
}
return object
}
I'd add a similar method but with an additional parameter closure (T) -> (T). So it would essentially return the mapped object after doing another map which would add any necessary information you need into it.