Migrating a Parse backend
How we took a first generation Swift app with Parse backend and brought it back from the dead.
At Blackbelt Labs we recently had a client come to us with an app that needed to be revived. The backend had been built using Parse provided by Facebook. Meanwhile Parse has gone open source and the Facebook hosting option is not available anymore. Because of this the app stopped working. In order to get it to run again we had to do at least two things.
- Find a new hosting solution for the Parse backend
- Make the app work with the new backend
Finding a Parse alternative
So what we had to find was either an option to get Parse to work again or hook the app up to a new backend solution — Firebase came to mind.
After some research it turned out there were roughly two options if we kept Parse. Either we host our own Parse server on something like Heroku, Digital Ocean, our basement or we choose a managed version from companies like Sashido.io, Back4App and so on. Since the target of this project was just to revive the app as soon as possible we decided to use Sashido.io. We liked that they were operating in the same timezones as us and also they seemed like a quite early stage startup which we hoped would mean fast support. Since we had found a promising solution that allowed us to keep using Parse we headed on to the app itself.
Migrating from Swift 1 to Swift 3
The app had been built in Swift 1. We are now at Swift 3 with Swift 4 on the way. Some people might remember how naughty working in Swift 1 could be back in the day so I was prepared for battle when I opened the project in my current version of XCode. Of course I was greeted with a lot of errors and warnings. This was also my first time working with this app as I had not been part of the team that built it. I decided to just get it to build first. This meant getting rid of all the errors. There is an automatic migration that XCode does for you which was helpful but didn’t solve all the errors and warnings. I then started wielding through the error jungle line by line looking up API changes when needed. Sometimes this was easy and sometimes this was more tricky. The trickier parts were when I had to update core graphics components on which our app heavily relies.
For example, this….
let subPath = CGPathCreateMutable()CGPathMoveToPoint(subPath, nil, x, y)CGPathAddQuadCurveToPoint(subPath, nil, x, y, x, y)
turned into this:
let path = CGMutablePath()path.move(to: CGPoint(x: x, y: y))path.addQuadCurve(to: CGPoint(x: x, y: y), control: CGPoint(x: x, y: y))
At some point I got the app to build. Before it was time to hook it up I had to update our version of Parse to the most recent one. After trying to manually move the framework I decided to try the quick route and used cocoa pods. This worked instantly. The app was now without errors and ready to be hooked up to our backend!
Parse hosting with Sashido
The first thing I had to do was get an account with Sashido.io. They give everyone a 14 days trial with full features. It went smooth and fast, you don’t even have to give them your paypal or credit card credentials upfront. In their dashboard you get a little tutorial with a code snippet to hook up your app. I fiddled the snippet into our existing code and it worked right away.
Deploying cloud code
Our app also used some cloud code to work with Twilio. Sashido provides you with a private Github repo to upload your cloud code. You just clone the repo, put your code in and push it. It is automatically built and deployed. After this our app was ready for a first test run — what can I say, it worked pretty much right away!
Setting up push notifications on Sashido
The only thing that was missing now was push notifications. All you need to do for this to work is set them up and upload your P12 file to Sashido. This is done with a simple drag&drop. In the beginning I had some problems here because my setup was not correct, unfortunately in this case Sashido only tells you when push notifications have failed but there are no logs. I had to send my first support request. It took maybe 2-3 hours to get a reply where they gave me the log for my failed push notifications. While the support was swift it would have been nicer to just have the logs instead.
Parse debugging issues
After we got push notifications to work we sent the app for our first feedback round back to the customer. They came back to us with some minor bugs and two new feature requests. To make these features work we had to write some cloud code. This is when our decision to go with a managed solution came back to haunt us. Since we didn’t have a local server to test our cloud code I had to always push to the server to test my changes. I wrote a quick git alias for this to speed up the feedback loop.
alias splurge="git add . && git commit -m 'another attempt at debugging' && git push origin master"My only way to trouble shoot the code was either to use good old console.log with my code that sat on the server or come up with some interface in the cloud code to expose data back to me. After spending what felt like way too long on getting some basic functionalities set up I sent another support request about how to debug the cloud code. A big problem was that it turns out Parse server has a problem with console.log — as in, it just does not work. Unfortuntely I did not know this. I will write this fat so no one ever has to suffer the way I did again. Use console.info or console.warn if you need to log something on the Parse server. When I found out that this actually worked I was done very quickly.
Conclusion
Anyways — at this point we had revived the app completely and even added two features. It went smoother and faster than expected. The decision on whether you want to use a managed hosting solution, a self hosted solution or a new framework comes down entirely to your expertise with Parse and Node or something like Firebase. For me I didn’t have much or any experience in any of those so I stayed as close to what we already had as possible. At some points it would have been nice to have a local server to trouble shoot but in the end the only blocker was that I could not use console.log. Other then that a really smooth experience considering I had never worked with Parse and I had not written the app that needed to be revived. Would I use Parse if I had to build an app like this today? I’m not so sure. Googling for errors or potential solutions did not always leak up to date results or any results for that matter. For this project I think we did the right thing, kept it very lean, made our customer happy quickly and provided them with a user friendly no strings attached backend solution.
Reach out to us at Blackbelt Labs if you need help with reviving your Parse based app.
