Sean HeberMar 19

It seems to me that most people, when wrapping up a big project that consumed their life for awhile, get excited, happy, and want to throw a party.

I, on the other hand, get weirdly depressed and dismayed. I question if it was worth it. I wonder if anyone will care or notice. I fear I wasted my time or that it was pointless. It's sort of a depressing time, mentally, in a strange way. I try to fight it, but the darkness is there anyway.

So anyway, just finishing up a huge Tapestry code project.

Show threadSean HeberMar 19

And before you get excited, it's not very user-visible. And that's why it hurts, maybe. It's important. It'll help in the situations it was meant to solve. But will you notice it day-to-day? I dunno. Ideally not if it's working correctly, anyway.

If you write 13,000 new lines of code in a forest and no one is there to review it, does it make a feature?

Show threadSean HeberMar 19

It was probably the most complex thing I've ever built.

I removed CKSyncEngine and did it all myself solving the problems we needed solved. Maintaining a synced database of items with unique IDs supporting cascade deletes and automatically handling conflicts without much participation from the server which knows nothing of our needs.

Do you know how hard that is? No, most people don't and never will.

Do you know how many ways it can go wrong? So many ways. Have I found them all? I don't know.

Show threadSean HeberMar 19

It's not just a replacement for CKSyncEngine - it's much more. One of the key problems we had was how CloudKit replays deletion tombstones going way back. Tapestry would download feed items, make a CKRecord, and put it in iCloud to sync to other devices. Then later when the item gets old, we delete them. Over time, with busy feeds, you're looking at hundreds of expiring items per day for some people.

If you reinstall the app, it'd replay those deletions as CloudKit "catches you up" on new sync.

Show threadSean HeberMar 19

Those replays are a total waste of time but it's just how it works. It could take *hours* to restore the relatively small number of actually current records as CloudKit replays dead records the new install never had in the first place. Thousands and thousands of them.

I had to rearchitect *everything* to redesign it around this one unchangeable behavior.

Show threadPaul Haddad Mar 19
@bigzaphod I think the suggested approach for this is to do a first time straight fetch out of the zone, then grab changes but ignore the replay data until it catches up.
Show threadSean Heber
@paul yeah, I considered just doing it that way, but you still get fed the replay data which is pretty dumb and still takes a long time. I don't know why they don't embed a date of creation or something into the change token. When you make a new one, you don't need any replay that predates it. Seems like that'd be an "easy" fix for this. But 🤷‍♂️
Mar 19 at 9:34pmWeb
Show threadPaul Haddad Mar 19
@bigzaphod I'm sure, hoping there are reasons its done this way, but no idea. You can I think trim the amount of data that comes in the replay, but don't remember details.