Essentially, we built this whole step nearly to completion locally on our machines using a pretty standard Rails setup and gemset which worked really well until we had to integrate with Parse. Getting our baby Rails app to share data with a prebuilt database on Parse proved to be a pretty big speed bump. Naturally, we spent some time searching out a solution and eventually thought we’d found one. Enter parse_resource.
This gem provides a wrapper for Parse’s REST API in an attempt to make it feel like you’re working with ActiveRecord. According to their docs: “Ruby/Rails Developers should feel right at home”. That seemed like a good sign so we decided to include it in the gemfile, run “bundle install”, and get to work. On the surface it seemed like we’d found a straightforward solution and we were excited to implement it but it wasn’t long before we ran into some problems.
Before I go any further I want to say how impressed I am that the original author and maintainer regularly responds to issues, questions and pull requests from the small community of devs working with his gem. It doesn’t seem like he has a lot of time but he’s at least active and helpful.
Like I said, parse_resource has been (and continues to be) a bit of a headache for Taha and I. First, the methods provided by the authentication gem we were using, Sorcery, stopped working for us. So we removed it and tried to move on. Then the same thing happened with a few more of our gems; namely SimpleForm, Carrierwave, and (oddly enough) Hirb.
With these types of roadblocks popping up it was time Taha and I took a step back and talked through our next steps. We decided to approach the problem differently by learning more about our tools and then implementing them. So we set up a separate repo and spent an afternoon learning about Parse, reading issue logs for parse_resource, and trying to work out why some of our gems had failed on us.
This strategy worked for us and because we had done a lot of the build already, we had a good codebase to work off of and rebuild from. For example, our signup forms, which were now broken, could be fixed using regular Rails form helpers. The Rails helpers would work where SimpleForm had failed, so we removed the offending gem and rebuilt. Fixing the signup and login forms was the little victory we needed to regain some confidence; it gave me the traction I needed to start working on having a user sign up on the web app and then log in from the native iOS app. And that task turned into a victory too; by the end of the day, Matt and I logged in to Merch from his iPhone and I got to check off another piece of functionality as ‘complete’.
We’re still working out an authentication system for the web app but it should be finished today. After that we’ll be tackling image uploads for a user’s Avatar potentially without the help of Carrierwave (it doesn’t play well with parse_resource). Those challenges will be for other posts but I will say that so far on this project I have learned so much more than I was expecting and my confidence with coding and development in general has gotten a real boost despite the obstacles. Those obstacles are learning experiences for Taha and I, and as frustrating as they are, the feeling of overcoming just one of them is enough to keep us coming back for more.