Have you used Google App Maker? It is not really as full featured, secure or as quick to deployment as FM can be.

FM has its limitations. I would not say it is slow in the cloud. That really depends on the solution and the cloud hardware. The new Data API is going to be a big asset to the platform once it is out of beta.

What do you mean by "slow while using with cloud"? DO you mean when it's hosted?

I've not found that experience at all. Of course I design with those practices in mind to keep the speed as quick as possible. I've used systems hosted on servers all over the country and haven't found huge issues.

FileMaker is 20+ years old, which means it is well-seasoned and has some modernization to incorporate. I'd go with FileMaker over other apps at the moment.

Build the apps your business needs with App Maker

It’s easy to get used to doing things a certain way. This can be a good thing if you're prepping for the World Cup, where practice, repetition and routine can make you a champion. But if you're like the rest of us who rely on certain processes to get things done at work—like budgeting or filing expenses—“trusting the process” doesn’t always feel rewarding.

Today, we’re making App Maker generally available to help you rethink how your teams operate. App Maker is G Suite’s low-code application development environment that makes it easy for teams to build custom apps to speed up workflows and make processes better.

Apps to fill business gaps, built for your needs

Analysts estimate that the right custom mobile app can save each employee 7.5 hoursper week (that’s a week’s worth of lunch breaks!). Yet, too few businesses have the means, let alone the resources, to invest time and effort in building custom apps. Why? Because their IT budget centers on big enterprise apps like CRM, ERP and SCM and beyond those priorities, IT executives’ attention focuses on security and governance.

App Maker was created to enable your line-of-business teams to build apps for the jobs these bigger apps don't tackle. With App Maker, you can revamp company processes like requesting purchase orders or filing and resolving help desk tickets, as if you designed and built the processes yourself....

Not sure why the full blog posting was placed in the FileMaker forum, when only a link is needed. This is a “competing” product...maybe? Anyway, this is an addition to an already crowded field of onlineonly application makers, which is a no go for me and clients.

I'm doing a presentation this fall at our local technology association on "low-code" solutions with the goal of showing a variety of solutions, but culminating with a demo of FileMaker that destroys all doubt as to who is the king in that space. Does anyone have any reasoned comparisons with other development platforms and FileMaker? I am interested in someone answering the OP's question about MS power Apps as well. THANKS!

The biggest dissatisfaction I have with filemaker is that it doesn't work that good when a server is accessed via internet.

Yes, the database can be designed to perform better while hosted in cloud but that needs extra work. Filemaker has to pull every needed related data then do the calculation in local computer instead of making that calculation on the server and serve the result.

For example, if I'm showing a list of 50 records which has fields from 3 different tables then it takes a while to load.

I'm glad to see google and microsoft are bringing their solutions too and hoping that filemaker also improve their performance while accessing from cloud.

If that's really that big of a problem, nexgen, then you can split up your tables so that fewer fields are required to get the requisite data. FileMaker assuming that you want all the data in the record(s) you have requested probably makes sense in the majority of use cases. The first step to solving the problem is admitting that it's there and working with it. If you have big images in the record, remove the images field to another table, and store a thumbnail in the one you need. If you have a REAAAAAAALLLYY wide table and list views then one-to-one relationships between the parts that are often used (or in the list view) and seldom used (for instance in a form view) is a good way to improve performance. That one time when you need the rest of the data to work with the record is only calling ONE record.

That assumes that you have adhered to all the other "best practices," like eschewing unstored calcs or large images (or BLOBS) in a list view.

These are practices that are common sense with any database engine. Yes, FileMaker is slower, but that needn't be a deal breaker, because of all the other stuff you get on top of the pure data.

Oh, and I access my client's files over the internet all the time. Sometimes I can tell that I am not on the internal network, and sometimes I totally can't tell that there is a plethora of dusty switches, routers, dubious ethernet cables, telephone companies, VPN encoding and other bottle-necks between my desk and their hot and crowded server rack.

The biggest advantage of filemaker is that I can design it as I use it. And often the tables gets wider than what we had imagined initially, there might be more related fields needed from different tables then what we had thought at the beginning etc... etc... A small imagined application gets bigger and bigger as time goes on because of all that nice and easy capabilities of Filemaker.

As I mentioned earlier, the database can be designed to perform better but that will require additional work. For example, now a days, if I have any related fields in list view then I make it an auto-enter field for improving performance. Now, I have to do extra work to make sure that the auto-enter field update whenever it gets changed in the related table.

Doing all that extra work devalues the biggest strength of Filemaker which is easy RAD platform.

Yes, it's a very good RAD platform (some say the best), but that does not mean that it prevents you from creating inefficient designs.

Can you paint like Rembrandt? You have exactly the same tools available that he used. Why not?

I'm not criticizing or saying you should go back to paint-by-numbers kits, but a blank canvas is a blank canvas. If you accept the challenge of a large rectangle of white gesso, then an assumption could be made that either you will accept that the learning curve is long and fame and fortune will be elusive if you go it alone, or that you will want to dedicate considerable effort to studying the techniques of those who have gone before.

I agree with some of what you say Jeremy, but some of FileMaker’s more senior features are far from impressive when hosted on the Internet. On large data sets sorting, particularly if you have to include a field from a linked table, summary fields and replace field contents can be embarrasingly slow, regardless of structure, if they need to be included within the production of an on-screen report.

There are a few things that can be done so a FM solutions run pretty fast when hosted on external servers:

- Avoiding ustored calculations (changing them by stored fields and linking them to the interface logic instead of the data structure - this involves additional considerations like concurrency conflicts)

- Avoiding summary fields (here it's difficult to find an alternative when summary calculations are based on found sets after search results for instance as Andy mentions, when running reports)

- Use PSOS (for instance, for replace field contents or loops)

Splitting data in different tables and then relating them with 1 to 1 relationships as jfletch comments, can improve performance when there are text fields and containers that store lots of data, since FM loads all fields when loading a record, even if not all of them are displaying in the layout. The only thing to consider here is that this has a performance penalty if any of the fields stored in the related table has to be shown in a list or table view, or has to be used for sorting (which wouldn't make much sense anyway to have them in the related table).

In any case, I agree that not much can be done to improve performance FM databases "hosted in the cloud" in the following scenarios:

- sorting data based on fields from related tables

- summary fields that need to recalculate after performing searches, specially if showed in sub-summary parts

- browsing data in list or table view when there the layout display fields from related tables

bigtom Can you please elaborate further on the disadvantages of "Google App Maker". It will save all of us from unnecessary time checking out Google App Maker.

I am really tired of extra coding for storing unstored fields (and making sure they get updated) and creating extra fields for storing datas for the field from the related table which I'm going to put in layout.