The release of DayBack for FileMaker last month has started a very exciting time for us here at SeedCode! Bringing the Calendar to a new code base and seeing it successfully deployed in the real world has been nothing short of thrilling. We’ve recently added mobile support and are looking forward to the future enhancements of DayBack for Pro and Go.
- FileMaker Server is a powerful tool, and it can do a lot. However, this ability to multi-task tends to lead to deployments where it’s simply trying to do too much. On the web publishing side things like portals on target layouts, server side scripting, huge data sets, etc. often put a considerable load on the server. Can we architect DayBack to do this kind of work in the browser and therefore put a lighter load on our FileMaker Server?
- Supporting server side processes requires a different level and type of support than client side ones. This is not just the case for FileMaker Server, but any server based application. Supporting the server often requires working on a specific machine with specific issues that extend well beyond your app, web servers, permissions, program versions, etc. can all affect how things run. By minimizing our server side footprint we hope to minimize the need for this kind of support.
Here is what fmxj lets you accomplish:
- Build complex queries and perform HTTP POSTs to your FileMaker Server.
- HTTP POSTS can be done directly to the FileMaker Server’s XML WPE or a simple PHP relay can be used to get around cross-domain issues and provide more authentication options.
As always, we love to take any opportunity we have to share our code, and I’m personally looking forward to keeping you posted on our progress.
Great work! Thinking beyond the curent project… any chance this will evolve into a newer, better way to automate migrating FM native screens and functionality into a web browser? (Yes, sounds like a more robust scalable version of IWP!?!) And, better yet… thinking Mobile First… dynamically reconfigure for desktop, mobile and smart phone applications (i.e., Android and iOS)? Just a thought!
Thanks for the post and kind words!
Let me know if that makes sense or if you’ve got any other questions.
Jason, still loving this, but (gasp!) thinking over wider implications a bit more. So… a couple of new questions:
– Have you explored how this performs at scale? I’m assuming performance will basically be gated by the XML API. Does that sound right to you?
– Do you envision using fmxj.js on public web pages (with the scale & load issues that could bring), or do you see this as being targeted to Web Viewers (and perhaps browsers limited to more of a typical FileMaker workgroup-sized scale)?
Right, the XML Gateway is still the only way in. (PHP API is just an XML wrapper too). We’re finding that using our PHP relay is probably going to be the most practical deployment, but that too, just does a cURL to the XML Gateway.
Our purpose is definitely the latter, in that DayBack will have subscribers that will connect to their known FileMaker server(s) as one of their potential data sources, and these would be people in that FM workgroup already.
For public sites, I remain skeptical, but there are public sites out there, and I think the key to them staying up is keeping their server footprint light. No scripts, no portals, etc., and that’s what we’re going for here.
I also think CWP performance is getting some residual benefits from WD, and I think we’ll continue to see that.
I’ll have some of whatever is in your water… It’s obviously making you super switched on. Love how simple this appears to be to implement, masking the obvious power that it brings into easy reach.
And without any complex installs or workrounds.
Top marks and kudos to all.
Now all I need is a project that requires me to learn how to best use this.
Thank you for sharing your work. I believe that a library such as fmxj.js, combined with a client-side library such as AngularJS will be a powerful combination, and could be one of the best future methodologies for building CWP-type sites.
Another advantage that I see is that it takes a step closer to writing chunks of UI code which can be shared between Pro (Desktop), Go, and a browser. I believe that, with the passing of time, more and more efficient techniques for writing this sort of UI code will be discovered and shared, and thus it will become easier and easier to write this type of UI code. I would even go as far as saying that this combination can open the door to deployment on non-iOS mobile devices in a native (albeit hybrid) app form.
Thank you again for sharing and getting the ball rolling in this direction. As is evident from my comments above, I believe that it has much potential.
“a step closer to writing chunks of UI code which can be shared between Pro (Desktop), Go, and a browser” indeed. Thanks for your support, Steve!
Sam Barnum from 360Works has an Angular library for FileMaker on Git Hub that I’ve been meaning to get into., so you might want to check that out as well. We’ve also heard some rumblings about some node.js adaptations which could be very exciting…stay tuned!
THANK YOU, Brian! That means a lot.
High praise my friend.