Hello, I’m working with websockets in Ember and trying to devise a best-practice approach for live updates to the UI.
Initially I had created an Ember service which utilized the ember-websockets addon and received formatted websocket data and simply called JSON.parse followed by store.pushPayload(parsedData). This approach did what I wanted it to do in that it properly updated the Ember store with new records from websocket updates.
The problem arose when I started doing some stress testing and immediately noticed that my websocket receiver was being heavily slowed down by the above process. I got some initial improvements by swapping out the ember-websockets for plain JS websocket usage but the main bottleneck is still with the store.pushPayload.
My use case is I basically have a table of read-only data (basically a logviewer) which I want to update in realtime with incoming websocket messages. From my testing, it seems that leveraging Ember data to provide the live updates to the views is creating a performance bottleneck. I was curious if there was any best practices or alternative approaches that anyone is following.
My thoughts are Ember data might be too much overhead since we are just dealing with an array of read-only data; the store really shines when you have models that require the full spectrum of CRUD operations.
My thoughts are Ember data might be too much overhead since we are just dealing with an array of read-only data; the store really shines when you have models that require the full spectrum of CRUD operations.
I think you nailed it right there. Ember Data records are great for all the use cases they are intended for (CRUD stuff, etc) but certainly not for everything, especially high volumes of data, data that doesn’t conform to a “record” shape, and so on. I used to work on a trading application and we ran into much the same issue with our market data updates. They took up way too much RAM over time (ED records are “heavy” and fairly persistent by design so getting rid of them was difficult) and require a lot of serialization overhead. NBD for CRUD apps, not great for use cases like yours.
I think in the past Ember Data has been too heavily emphasized as “the way to do data in Ember” when it is in fact only one way. So definitely don’t think of an alternative approach as wrong or weird or anything of that sort. I’m not sure I can offer a whole lot in the way of best practices since once you step outside Ember Data every use case will be very different, but definitely recommend keeping the data in some sort of store-alternate service so it can be injected anywhere… try and keep any serialization/munging fast and minimal… if you need bindings and you’re using more “classic” ember you’ll probably want to use EmberObject and EmberArray, and in Octane I think there is some nuance to making complex state like arrays and objects tracked properly.
Thanks, this is great insight and confirms my suspicion with ember data being the bottle neck for this particular use case. Had some trouble finding others with this experience through countless searches so appreciate the feedback from someone who’s worked with high volume data in Ember.