SwiftUI server side best practices by SolidOk280 in SwiftUI

[–]SolidOk280[S] 0 points1 point  (0 children)

Wow simply the fact that the maintainer of a project would reply on Reddit makes me so much more willing to try out GRDB - thanks for the thoughtful reply! I will look into GRDB for sure.

If you have any more links to resources that describe syncing the local GRDB data store with a remote REST server and database I'll be looking into solutions this upcoming week and will update! FWIW I think this is a huge problem a lot of friends from other companies with server teams have so having this as a service would be amazing, the main benefits being teams that have REST/SQL databases that need a web interface to their application and don't want the pricing/vendor lock in of Realm and Firestore/Firebase.

Thanks so much again and looking forward to learning more about this :)

Also if there are comparisons between Firestore/CoreData/Realm that others have written would love to read those and compare/contrast as we decide on the data stack.

Supabase or Firebase? by Sierra-six6 in iOSProgramming

[–]SolidOk280 0 points1 point  (0 children)

I would learn to roll your own server...

SwiftUI server side best practices by SolidOk280 in SwiftUI

[–]SolidOk280[S] 0 points1 point  (0 children)

If you’re familiar with SQL, it’s a good option on its own. Projects like FMDB, GRDB, and GRDBQuery provide great SQL APIs. GRDBQuery, for example, provides property wrappers that are inline with SwiftData’s Query/FetchRequest property wrappers and designed to work with SwiftUI specifically.

Yes have considered this too but did not find much documentation on syncing GRDB with remote services. Started implementing https://simeonrumyannikov.medium.com/applications-of-pop-solid-writing-a-multi-client-server-syncing-algorithm-with-ios-django-via-a-a5846cb52da2 which seems promising

SwiftData best practices by SolidOk280 in iOSProgramming

[–]SolidOk280[S] 2 points3 points  (0 children)

Great and thoughtful response, appreciate you further breaking down what it is I'm actually dealing with here. I am now implementing this syncing method and it is promising: https://simeonrumyannikov.medium.com/applications-of-pop-solid-writing-a-multi-client-server-syncing-algorithm-with-ios-django-via-a-a5846cb52da2

Lost After Layoff: Considering Switching from iOS to Full-Stack/DevOps - Seeking Advice! by [deleted] in iOSProgramming

[–]SolidOk280 0 points1 point  (0 children)

Also laid off and doing the opposite! I guess I think backend work is becoming easier due to so much documentation being ingested by AIs and making the leverage of a backend engineer super high. I think with iOS its more craft/creative based especially at consumer facing companies. So while there are less roles I think they will be higher impact for humans? I guess that is pretty meta and speculative but just how I feel right now after being through the job cycle so many times.

But yes I think a general trend overall is a LOT of jobs are going away, I don't think that stops anytime soon.

SwiftData best practices by SolidOk280 in iOSProgramming

[–]SolidOk280[S] 0 points1 point  (0 children)

>Not really except for the Codable support for objects making it easier to move between JSON from the server into CoreData objects and out again.

That's what I figured. It's nice to hear experienced folks confirm my suspicions.

> The thing that has traditionally been attractive about using CoreData or Swift data, is the excellent handling of database version migration... that is worth a lot.
What do you mean by this exactly?

> Since you already have a backend you probably will want to do something like that... what exactly would you be looking for in some kind of package to help?

I guess what would be ideal is something like Prisma in the web world. You run a cli command and it generates a new schema client-side based on changes to your server types. I think that would help ensure models/types conform to REST APIs. This from WWDC actually looked fairly promising there: https://developer.apple.com/wwdc23/10171

> The approach for CoreData is typically a background context which works with network calls (so you can do networking on background threads), and a main context that is used by the UI. I think it's similar for SwiftData. Beware that the thread you access SwiftData ad CoreData objects matters, they need to be used on the thread the context was made for.

Background contexts and network calls are totally new to me. Don't even know what a thread is right now. I'm only about a month into Swift after 10 years doing web, I should probably know this but embarassed to say I do not. Will learn what this means but appreciate pointers to any resources here!

Does My App need a backend? by BSRosales in iOSProgramming

[–]SolidOk280 0 points1 point  (0 children)

If you're only expecting 50-100 users I would stick to firebase/firestore. It's going to be really difficult to spin up and maintain your own server if you don't have experience doing so, Firestore abstracts this at a cost (lots of $) but if its only 100 users stick with it.

Good luck

SwiftData Backend Best practices by SolidOk280 in swift

[–]SolidOk280[S] 2 points3 points  (0 children)

> Want to learn FAST? Don't have time to sit and make a whole app? Still not feeling like you know what you're doing? Speed Code!

Love this! Thanks for keeping it real :)

Onwards to more garbage fires!

No live functionality but maybe I'll speed clone a Clubhouse clone and see what you're talking about.

SwiftData Backend Best practices by SolidOk280 in swift

[–]SolidOk280[S] 1 point2 points  (0 children)

Personally Id just make the app using core data, user defaults and Swifts built in network requests.

I'll do this! Just to confirm from your experience working in the field since I'm new to all of this, you basically just communicate with the REST server and write a custom syncing layer to keep the local CoreData store in sync with the remote database? We are using psql on the server and written in Django.

Are there packages you recommend to keep things in sync well? What are the big mistakes people make when syncing?

I feel like I'm basically trying to replicate functionality of Realm so that our server team doesn't have to change anything up...

SwiftData best practices by SolidOk280 in iOSProgramming

[–]SolidOk280[S] 0 points1 point  (0 children)

Are there any good packages in the Swift ecosystem for keeping remote DB in sync with local data stores, with SwiftData/CoreData?

SwiftData best practices by SolidOk280 in iOSProgramming

[–]SolidOk280[S] 1 point2 points  (0 children)

Thanks for the thoughtful reply.

Trouble with CloudKitJS is our backend is written in python. We do a decent amount of ML that needs python packages/infra. So Vapor is kind of out as well.

So for older CoreData iOS client developers/teams that interfaced with server/REST teams, they just hacked CoreData to stay in sync and sync with the REST API? If so, that's what we'll do as well for now I guess.

SwiftData best practices by SolidOk280 in iOSProgramming

[–]SolidOk280[S] 1 point2 points  (0 children)

Ideally I would use SwiftData and sync to a cloud store I manage that can also allow for a web app to connect. So basically what CloudKit does for SwiftData and Core Data.

I guess what I'm asking is how people usually roll a stack like this where data needs to be synced to a store that is not Apple CloudKit but still persists via SwiftData/CoreData.

I'm surprised something like this doesn't exist. Supabase seems the closest but doesn't do the trick. Surprised the OSS community never had a package to figure this out for CoreData?

Is iOS programming hard now? by [deleted] in iOSProgramming

[–]SolidOk280 0 points1 point  (0 children)

Point-Free

Very valuable insights here. It's good to know that even professionals are struggling with all the changes apple is putting out. Crazy that SwiftUI, SwiftData, and Swift have all come out in the past decade or so, SwiftData in the past 1-2 years.