Server Side Swift with Perfect - Part 7: Server Side | Ray Wenderlich

In this screencast, you will learn how to better organize the code in your Server Side Swift with Perfect projects, by refactoring to use basic controller objects.

This is a companion discussion topic for the original entry at

Part 7’s subtitle is missing.
It does not include “track …” tag.

@klarheit Thanks for the heads up on this! I’ve put in a request for subtitles and will get those uploaded as soon as I receive them. Sorry for the delay!

@klarheit Subtitles are now up. To turn subtitles on click the icon in the lower right corner of the video player and select “English [Subs]”

Hi @rwenderlich ,

First i want to thanks you for your great jobs with these tutorials !

I have take a look inside the code and i don’t understand why but when you perform a getById request and you don’t find any response because your id for example didn’t exist it won’t failed or crash because you create manually an object Acronym. That mean you should check the property results of Acronym before send back response.

Have a good day :slight_smile:


Hi @loikos - which route are you talking about? I’m looking at AcronymAPI.swift, and there are some routes that try to get an acronym (like delete or update), but if the acronym doesn’t exist, getAcronym will thrown an exception, which results in the route returning an error. But maybe you’re looking at something else?

@rwenderlich I’ve got a question. Wouldn’t it be better to return from AcronymAPI methods, dictionaries ([String: Any]) instead of strings?

Earlier you had a dictionary and returned it as JSON setting JSON as header.
Now you have a dictionary, encode it as String and then return it as String setting JSON as header.

Wouldn’t be it more “clear” if AcronymAPI’s methods returned Dictionaries instead of String? If you have a dictionary, you can always encode it. But if you have it encoded as String, you have to do more efforts to decode it back to Dictionary eventually. And it’s harder to look what it is inside.

In these examples, to accomplis this, you just need to change function return type from String to [String:Any], remove the .jsonEncodedString() at the end of the return call, and from the BasicController methods, use .setBody(json:) instead of .setBody(string:), basically the call that there was before in the main.

Only thing that requires some additional efforts in this example, is in the case of error, you can not return a String but you have to throw an Error. In a simplified way, it can be done typing

extension String: Error {}

and then

throw "Invalid parameters"

but makes furtherly more organized in my opinion, as you are no more returning data and errors in the same format (String).

What do you think?

i’m looking at the following function :

let getObj = Acronym()
var findObj = [String: Any]()
findObj["id"] = "\(id)"
try getObj.find(findObj)
return getObj
} ```

if you try with an unknown id for the database the function will not throw by my experience but send you back a default Acronym object !