miniMongo mobile performance



I am just wondering if there are any limitations to how much data you can put in miniMongo. I am pulling results from the iTunes api and store episodes in mini mongo to populate a list in which people can select episodes.
Only when the select them, i store them in persistent mongo.

I develop on my Macbook in chrome and its very smooth, but whenever I try it on my phone or ipad or iOS simulator, they search and scrolling in the list becomes pretty laggy.

I for one channel I fetch 680 entries from the iTunes API, of which each item just holds maybe 12 key value pairs. Nothing extreme.

What I do in the template.created function is calling the iTunes API 'getFeedHead', Session.get( 'channel' ).url, instance.headSize, ( error, result ) ->
        if result
   result )

            instance.episodeHandleHead = Meteor.subscribe( 'episodes', result.episodes )

and then I pass the result to the published which fills the client side collection

Meteor.publish ‘episodes’, ( data ) ->
instance = @

data.forEach ( item, idx ) ->

    # add templates to collection
    instance.added( 'episodes',,
        # identifier:         if item.guid then item.guid[ 0 ] else null
        index:              idx
        title:              item.title[ 0 ]
        description:        item.description[ 0 ]
        stream:    item.enclosure,  ( value ) ->
                            if value.$ and value.$.url
                                return value.$
        duration:           duration
        summary:            if item[ 'itunes:summary' ]     then item[ 'itunes:summary' ][ 0 ] else null
        publishedDate:      if item.pubDate                 then moment( new Date( item.pubDate[ 0 ] ) ).toISOString() else null


This creates the episodes only in the browser which is what I want. It’s temp data.

Finally I have a SearchSource on the client

if Meteor.isClient
@Episodes = new Meteor.Collection( 'episodes' )
options =
    keepHistory: 0
    localSearch: false

fields = ['title']
@EpisodesSearch = new SearchSource( 'episodes', fields, options )

# set up client datasource
EpisodesSearch.fetchData = (searchText, options, success) ->
    err         = null
    console.log("seach options Collection",searchText, options)
    if !options
        options     = {sort: { 'publishedDate': -1 }, limit: 20 }

    data = null
    if searchText
        # get rid of surrounding spaces
        searchText  = searchText.trim()

        selector    =
            $or: [
                    $regex: searchText
                    $options: 'ig'
            ,   description:
                    $regex: searchText
                    $options: 'ig'
        data = Episodes.find( selector, options ).fetch()
        data = Episodes.find({}, options).fetch()

    # return result
    success(err, data)

which searches the client side collection. Works like a charm…on a macbook. Not on iOS or Android.

So my question is if this is a limitation of mobile phone hardware or is it some kind of Blaze issue?

I am considering to store the episodes on the server in a temp storage per user and then subscribe to the server collection instead of loading everything in mini mongo. I dont know if that would be faster, it probably would consume less memory because minimongo will only hold the current set that is request by the subscriber.

Any thoughts?


Nobody having a clue or suggestion?


Why not try to use pagination? You do not really need 680 Episode on the client…

Topics to research: InfinityScroll


Think you don’t understand. The 680 episodes in the client is a form of
cache, for quick search in the client collection. However, I already
changed it by storing them in mongo to counter the performance issue, but
now I have to deal with cache expiry stuff etc.
But it is better than a sluggish mobile browser.