I’m looking for guidance on the best practices for handling intricate data flows as my large-scale online application, which was developed with Ember.js, grows.
The majority of our data management requirements have been met by Ember Data, and although it has worked well for small to medium-sized apps, we are beginning to have difficulties as our app grows. In particular, we’re having problems with:
Managing highly nested relationships: It’s getting harder to efficiently retrieve or update certain of our models since they contain intricate, deeply nested relationships (such as several levels of hasMany or belongsTo). Are there any methods or accessories that could make managing these relationships easier?
Management of the state: It gets harder to maintain UI state across several routes and components as our app gets bigger. Does anyone know how to handle this in a scalable manner using Ember Concurrency or another tool?
Enhancing performance: We’ve begun to observe performance problems, especially when working with big datasets or numerous components that are produced at once. Are there any general best practices or optimisations unique to Ember that could assist us enhance rendering speeds and performance in general?
Any advice, trends, or resources that have helped others in like circumstances would be greatly appreciated. Have you found any community tools or techniques useful for handling large-scale applications? I’d also like to know what you think if anyone has any experience moving from Ember Data to a more customized solution.
@JesicaW I have edited your post to remove the off-topic/spam link. Please do not continue to add spam links to posts here and keep discussion on-topic (Ember).
While I’m pretty sure this is a mostly LLM-generated spam post and not a legitimate question the topic is interesting so I’m going to leave it open and respond.
The legacy hasMany API is basically unusable at scale (so is store.findAll) because it’s based on fetching “all the things” and with any non-trivial dataset this becomes crazy. At my company, for example, we don’t use hasMany or findAll and instead lean on direct queries to the related resource e.g. /books?author_id=xyz`
Legacy Ember Data caches everything and you have no control over what is cached. This can cause application memory to build up very fast and clearing the cache/store is difficult (at least anecdotally). Cache control is a first class citizen in the new Ember Data design iirc so this is great news.
If you have control over your backend, and if it’s JSON:API you can reduce number of requests and request size using pagination, sparse fieldsets, include support, etc.
Legacy Ember Data isn’t a great fit for every scenario. It’s focused around a resource-oriented data architecture so if your data doesn’t match that it feels awkward. This is another thing that will be much more flexible in the future.
Management of the state: It gets harder to maintain UI state across several routes and components as our app gets bigger. Does anyone know how to handle this in a scalable manner using Ember Concurrency or another tool?
This is one of the bits (other than the spam link) that suggests the entire point of the OQ was spam. Ember Concurrency is not really a state management tool, it’s a concurrency/task tool. This is an obversimplification but It’s like a better async/await with cancelation (if you will).
I don’t personally find managing state difficult in an Ember application because there are some great tools built in.
services: a construct for global classes (which include state) that can be used anywhere it’s needed. I find this a really nice abstraction vs something like Providers
autotracking: Ember’s reactivity model is super simple to use and not tied to components at all meaning you can have services or other class that manage their own state, and 0 extra code is needed to efficiently re-render
Ember Data store: if you’re using Ember Data you already have a store service which holds your cached records which have been fetched from your backend(s)
3rd party libraries: there’s also nothing stopping you from using a third party state management library (although if you need it to participate in the reactivity model you might have to do a little extra work to integrate it) I typically find this isn’t really necessary though.
,