Jump to content
Server Maintenance This Week. ×

Building a Website with Filemaker Backend - can Filemaker cope?


This topic is 2185 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

Hi all,

 

many thanks for reading my post.

 

I am working on a project with my sister who currently builds our databases at work with filemaker. 

 

We are working on a website together for release in late 2014 or early 2015.

 

As with all websites, there's a frontend and a backend.

 

We would like to develop the backend "usernames, passwords, user data, dates, times, data fields etc" within a filemaker database (that my sister can build), and then have a professional web programmer build the frontend using javascript or html 5 or something similar. 

 

I have a few questions:

 

1) Is this a stupid path to go down factoring in growth and scalability? If, hypotheically the website grew to 1000's of people a day (I'm sure it wouldn't!) but, would a filemaker hosted (pointinspace.com etc) backend be able to cope with the large amount of information requests from a javascript web frontend in a speedy manner? ie, I wouldn't really wonder why the page took 10+ seconds to load?

 

2) As 99% of web hosts don't host filemaker files, we would have to split front end hosting and backend hosting between a normal host (bluehost, godaddy etc) for the frontend and a filemaker host (pointinspace.com, worldcloud.com etc) for the backend. Could that be a huge lag potential?

 

3) If we went down this path, how to the two connect? Is the best connection between a full website and filemaker database just PHP? or are other connection methods preffered from small strings of data (no images etc, just data fields). 

 

3) Should we just grow a pair, give up on FM and develop the backend in MySQL or something similar?

 

We are so close to starting the project, but I'm really struggling to find information on large scale websites that actually host the user data on a filemaker server backend, that get the speeds you would expect from a standard website.

 

Would love whatever help you could throw my way!

 

Many thanks,

 

Simon

Link to comment
Share on other sites

One way to consider is using php and MySQL for the website, and using FileMaker as a back-end admin/management system by using the MySQL tables as External SQL Source connections in FileMaker, thereby enabling you to use FileMaker and MySQL tables in a very integrated way :-)

See http://www.filemaker.com/support/technologies/sql.html

Link to comment
Share on other sites

FileMaker does not scale well to the 1000's of requests a second level... single-threading, use of the XML engine to publish data and a different approach to web interactions are all part of that...

 

That said, a lot of websites never get close to that - http://apachescricket.com/ has been running directly off various FileMaker versions for over 10 years...

 

That site is on a web provider for front end, and a different database hoster for the backend... it works fine. Low load, but some complicated data behind it.

 

HTH

Link to comment
Share on other sites

  • 4 years later...

So...now is 2018 and a lot of water went under the bridge.

Would anyone with expertise update this discussion, please?

How would I go on building a web site for a travel agency, that uses FMS to manage all its business, where users can login and exchange data with the agency about an enrolled travel?

They tell me that ODBC/XML is not considered secure anymore.

Custom web publishing hosted by the agency hardware?

Thanks

Trevix

Link to comment
Share on other sites

This topic is 2185 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.