Is there a limit to the number of models for one application?

Ember Data
1

A friend of mine was put in charge of completely rewriting their company’s customer interface. They work in the health sector and their product / client is used by over 10 huge, national health insurances. Their MySQL databases are over 400 GB big and contain over 1000 different tables.

It is a vast amount of data.

The current client is an age old Java behemoth. It became unmaintainable and they want to switch for a web client for various reasons: better control, easier updates, easier installation (= none), etc.

He asked me, whether Ember.js would be a good choice for that. Naturally I said yes.

However, I see a huge problem: The number of models that would be loaded by the client. If they account for similar tables, partitions and hidden / access restricted tables, they’d probably still end up with about 500 to 800 different models. It is insane.

This also poses a UI/UX problem; how would you want to put 800 different models in one UI? I couldn’t think of a proper structure. That’s why I recommended to split up the app into as many different parts as possible. This would become easier if engines landed, but that’s another story.

Anyhow, they’d still be left with about 100 to 300 models per app. Would that number of models have an impact on performance? Are there benchmarks for this scenario?

I could imagine that ember-data or the browser could crush under this sheer amount of data, as every single model class is it’s own JS object.

Do you have any experience with this huge amount of models per app?

Thanks a lot.

2

Seems like ember-data handles this quite well. We ran a quick benchmark with 1000 models and while it took some time to build (initially), it had virtually no impact on the user experience.

3

I think your biggest challenge is going to be how big the local store gets and how much data you expect the client to store in memory, especially on mobile clients which are more memory bound… If you need a large amount of data you can push it into the store. If you have a lot of read only type data I would also consider using service objects that act as singletons and only need loading once.

Using the router and having multiple models loaded at once will add complexity to your routes code in Ember.

Also, depending on what you are trying to do with your modeling, there is nothing that says that you have to have 1 to 1 mapping between server side and client side models. The models you build in Ember (with Ember Object) or Ember Data (with DS Model) are really the abstraction that your front end app needs. Depending on the nature of what you are modeling you might be able to build some useful abstractions that simplify the way models in your Ember app work. And then use the Serializers and Adapters to normalize to this abstraction. So in theory many models on the API side map into a small set of semantically meaningful models on your client side.

But glad to hear that ember data is handling your use case well. Would be great to see an example of the extreme case.

1 Like