I'm trying to understand the correct architecture for shared post state in SwiftUI using the new Observation framework.

I have a simple example where both ContentView and SavedView display PostView.

Observable class Post {
    var id: Int
    var content: String
    var title: String
    var isLiked: Bool = false

    init(id: Int, content: String, title: String, isLiked: Bool) {
        self.id = id
        self.content = content
        self.title = title
        self.isLiked = isLiked
    }

    func toggleLike() {
        isLiked.toggle()
    }
}


struct PostView: View {
     var post: Post

    var body: some View {
        HStack {
            Text(post.title)
            Text(post.content)
            Spacer()
            Button(post.isLiked ? "Liked" : "Like") {
                post.toggleLike()
            }
        }
    }
}

ContentView

struct ContentView: View {
    @State private var posts : [Post] = [] 

    var body: some View {
        List(posts, id: \.id) { post in
            PostView(post: post)
        }
        .task {
            if posts.isEmpty {
                let examplePost = Post(
                    id: 1,
                    content: "examplecontent",
                    title: "exampletitle",
                    isLiked: false
                )
                posts.append(examplePost)
            }
        }
    }
}

SavedView

struct SavedView: View {
    @State private var posts: [Post] = []

    var body: some View {
        List(posts, id: \.id) { post in
            PostView(post: post)
        }
        .task {
            if posts.isEmpty {
                let examplePost = Post(
                    id: 1,
                    content: "examplecontent",
                    title: "exampletitle",
                    isLiked: false
                )
                posts.append(examplePost)
            }
        }
    }
}

If I like the post in ContentView, the same post in SavedView is still shown as not liked.

I understand that in this example each view creates its own Post instance, so they aren't actually sharing the same object.

My question is more about architecture:

• How is this typically solved in real apps?
• Do apps like Instagram or X (Twitter) maintain a single shared source of truth for every post?
• Is the common approach to have a central store/repository (similar to Redux/TCA) where every screen references the same Post object by ID?
• Or do they simply refetch the data whenever a user navigates between screens?
• With SwiftUI's new Observation framework, what would be considered the idiomatic architecture?

I'm interested in how large social media apps handle this problem rather than just fixing this sample.

I'm using Apollo Server with TypeScript and GraphQL Code Generator.

My GraphQL schema uses camelCase field names:

type User {
  id: ID!
  createdAt: String!
}

The data returned from my database uses snake_case:

const user = {
  id: 1,
  created_at: "2025-01-01T10:00:00Z",
};

My query resolver simply returns the database object:

const resolvers: Resolvers = {
  Query: {
    user: async () => {
      return user;
    },
  },
};

I would like to resolve createdAt from created_at using a field resolver:

const resolvers: Resolvers = {
  User: {
    createdAt: (parent) => {
      return parent.created_at;
    },
  },
};

However, TypeScript reports an error:

Property 'created_at' does not exist on type 'User'.

It seems that the generated resolver types use the GraphQL type shape (createdAt), while at runtime the resolver receives the raw database object (created_at).

As a result, TypeScript only exposes:

parent.createdAt

but the actual value I need is:

parent.created_at

Questions

1. What is the recommended way to map snake_case database fields to camelCase GraphQL fields when using Apollo Server and TypeScript?
2. Is it possible to configure the generated resolver parent type so that parent reflects the database model rather than the GraphQL type?
3. Should I instead transform all database results from snake_case to camelCase before returning them from the query resolver?
4. How do people typically handle this pattern in Apollo Server + GraphQL Code Generator projects while keeping full type safety?

For example, what would be the idiomatic way to expose created_at from the database as createdAt in the GraphQL schema?