Search code examples
siesta-swift

Model architecture and persistance for Siesta

I am pretty new to Swift and coming from Restkit, I found Siesta and it seems like a solid library solving a common problem. At the moment I am trying to figure out how to deal with the model layer of my app and its persistance. CoreData is an approach pushed by Apple, while something like MagicalRecord makes it even easier.

However, Siesta does not handle CoreData and it is not clear to me how the caching works (or how far it is implemented:

Siesta currently does not include any implementations of EntityCache, but a future version will.

http://bustoutsolutions.github.io/siesta/api/Caching.html

From the example, I can see you define models just in Swift code: https://github.com/bustoutsolutions/siesta/blob/master/Examples/GithubBrowser/Source/Model/User.swift

So: is this the best approach to the model layer or does CoreData/MagicalRecord have a role? How is caching done in this case, will it survive between app launches?

Thanks!

Solution

  • The first question is this: what problem does a local database (like Core Data or Realm) solve for you? Depending on the answer, you may not need one — or Siesta may not work well for you.

    “I just need caching”

    Siesta does in-memory caching for free. If all you need is caching to speed things up while the app is running (i.e. prevent redundant requests, show data across VCs, etc.), then you probably don’t need to bother with either EntityCache or a local database.

    Most apps fall in this category.

    “I need offline access”

    If you need persistent caching for offline access or doing a fast launch with stale data, that’s what EntityCache is for. You still may not need a local database; a simple key-value cache will do. Unfortunately:

    1. A public EntityCache implementation is out of scope until after Siesta 1.0 is finalized.
    2. Siesta’s current caching APIs are currently not well suited for working with models. Update: The caching API is now well-equipped to cache models, parsed JSON or other ADTs, or raw bytes.

    “I need a queryable database”

    Perhaps your need is not just caching. Perhaps you want to grab data from many different API requests and query it, e.g. “select all previously fetched widgets whose supplier location is in Mozambique.” That is clearly a job for a database.

    At this point, you aren’t just caching; you’re keeping local state synchronized with remote state, and querying both the remote and the local copies independently. That’s a messy problem with very circumstance-dependent solutions, and well beyond the scope of Siesta.

    You can make Siesta work with a local DB, but it gets messy. Your life will be easiest if you can avoid mutating the local DB, keeping it a one-way mirror of the authoritative data from the server.