RestFM – The fourth synchronization tool reviewed

By July 21, 2014News

We’re moving past the three best known products for Filemaker synchronization into the more recent additions,. The next three products we’ll review are not as well known, but the still have a lot to offer.

For those new to the series, we reviewed MirrorSync three weeks ago in a previous post, and two weeks ago we reviewed GoZync. Last week we presented our review of SyncDek2Go. If you want to read a bit about our testing environment and our tester you can read about it in our first post.

This time around we’re reviewing RestFMSync, which is a synchronization feature from within the RESTfm API, made by the team at Goya Ltd.

For those not familiar with the RESTfm API, well you should be. 🙂 From their website, RESTfm is:

RESTfm turns your FileMaker Server into a RESTful Web Service, so you can access your FileMaker Server databases via HTTP using a common REST architecture with easy to understand API calls.

This is a great tool, and while we love the tool and the idea in general, here we’ll just be reviewing the synchronization portion of the tool.

As with the last reviews, we’ll start with a review of the tools and it’s features from our intern Patrick.

RESTfm accesses FMS using HTTP instead of using FMP networking protocol this allows for better connectivity and speeds. It avoids having to open and close files and instead just grabs the records it needs. Also it is able to use different data formats to send data based on the circumstances. A unique feature that isn’t exactly a positive is that RESTfm does not support container field syncs as of yet, so there won’t be any container sync information on this tool.

Since this tool is so unique I wasn’t sure what to expect on the integration front. My instinct was that it was going to be the most complicated of the lot, but I was pleased to find myself wrong. While everything did not go flawlessly, it didn’t turn out to be as difficult as I feared it would. From Patrick:

This integration can be a bit cumbersome since it needs outside applications installed. To start you need to install RESTfm. That is accomplished by installing the Microsoft URL Rewrite module (if you are on a pc, macs don’t need to install anything like this). Then unzip RESTfm into the FMS webserver root directory. After getting that all squared away it then goes to creating tables, layouts, importing scripts etc. The usual sync tools affair. If you follow the guide carefully and use the sample solutions as resources integration is easy. In total it took me about an hour or hour and a half to get RESTfm integrated.

However I did run into weird errors that made it so I was unable to sync. I spent countless hours pouring over the scripts trying to find something to fix the error, as well as being in frequent contact with their support. They offered helpful advice that would fix an error but another one would just pop up after. The biggest error was telling me there was field missing even though I had copied and pasted the table exactly how it was (except for the fields specific to RESTfm). After what felt like an eternity it just magically started syncing. It just worked and I have no idea why.

Be weary about editing your files after getting to work though. After I added matching fields in both the local and hosted files they ended up not working again and I got the same error as before. Like before I waited a long time doing many different things, then out of no where it would just work.

My impression was that it is a good tool, that just needs a bit more work to be great.

With the product integrated we moved onto the sync process. Remember that container fields are not supported, so there will be no data for them. Patricks thought were very straightforward.

Pretty standard syncing with this one. It is not the fastest sync tool but it is not the slowest either. It is actually pretty comparable to GoZync in terms of it’s speed. The major difference is that RESTfm is not able to sync containers quite yet.

So on to the speed test results.

Pulling From Server
50 Records 100 Records 500 Records 1000 Records 5000 Records
10 Fields 10 seconds 15 seconds 1 minutes 6 seconds 2 minutes 9 seconds 10 minutes 36 seconds
50 fields 30 seconds 56 seconds 4 minutes 31 seconds 8 minutes 57 seconds 44 minutes 30 seconds
Pushing To Server
50 Records 100 Records 500 Records 1000 Records 5000 Records
10 Fields 25 seconds 47 seconds 3 minutes 41 seconds 7 minutes 4 seconds 37 minutes 24 seconds
50 Fields 40 seconds 1 minutes 14 seconds 6 minutes 6 seconds 12 minutes 18 seconds 62 minutes 14 seconds

In summary RESTfmSync is in the middle of the road, not the fastest or the slowest. If they had container synchronization I would be very interested to see where it would land as that is one area there seems to be more separation in performance.

As before in choosing features to list and compare, we tried to focus on features that were quantifiable and concise, but weren’t covered in other analysis. For RESTfmSync they provide (what we consider the preferred answer is in green, the less ideal answer in red):

The ability to choose what fields to synchronize Yes
Tools to help deploy local offline copies No
Developer can control the synchronization direction Yes
Synchronizes container fields No
Provides field level merge to manage conflicts Yes
Supports Server to Server synchronization No
Open Remote required Yes
Requires UUID Yes
Deletions synchronize both directions Yes
Requires additional hosted files Yes
Resume incomplete synchronization No
Requires FileMaker Server Yes
Field level conflict management Yes
 Approximate first time to integrate  1 Hour 30 Minutes *
Time to integrate once familiar 50 Minutes
* The one caveat on the first time to integrate, this includes only time spend actually moving forward, not time spent in troubleshooting and debugging. Including that time it was more like 8 hours.

This one was more of a mixed bag. I want to include some of Patricks final thoughts:

I don’t know how I feel about this tool. It offered extremely consistent syncs, I knew just about when each sync would finish. The biggest deterrent is the random “Field not found” error. It might be something with my setup or with RESTfm itself. If it was not for that it would have my full endorsement. Besides that I would recommend this to people as long as they don’t need to sync containers. 

I think this is the most interesting tool reviewed so far. Relying on a REST API to get the work done is an interesting method. Give this one some time and it may be a real competitor.

As in the last reviews, we’ll we have another one coming next week. If you’d like us to expand our testing to include something you feel we may have missed, or just want to chime in with your thoughts or say something nice about RESTfmSync or Goya. Please leave a comment below.

Court Bowman

Author Court Bowman

Court Bowman has been working with in the IT field his whole life, working as a network engineer, database developer in Oracle and Progress and as a IT director for several firms. He has been working with FileMaker Pro since version 2 and has been a reoccurring speaker at the FileMaker developer conference. Apart from his expertise in FileMaker Pro he has experience in system architecture and design, data modeling and database architecture. He also has years of experience as a process and workflow consultant and has helped with the design and deployment of hundreds of systems in FileMaker and on the web.

More posts by Court Bowman

Join the discussion 3 Comments

  • Nihm Brisby says:

    Do you feel any or all of the solutions are suited to *always* using sync? Would love an approach that could give the best of WAN and LAN for small single-site businesses that only need the ‘cloud’ for back up and the occasional trade show /road trip. Thanks again!

  • Court Bowman says:


    Good question. The features lists can be your guide a bit. It really comes down to cost vs needs. If you are always syncing both GoZync and MirrorSync are good choices if you have FileMaker Go in the mix.

    If you have ongoing development and less savvy users GoZync may get the edge because the new version deployment is a bit cleaner for users. If not MirrorSync is a bit cheaper and just a bit faster to get going initially. You really can’t go wrong with either.

Leave a Reply

All rights reserved Cleveland Consulting.

Call Now Button