billdybas

What I don't see anyone talking about is how Private Cloud Compute is behind an iCloud subscription.

From what I can tell, this means any app that is using their foundation model is sharing against a user's pooled usage quota & Apple takes all the revenue upside if a user chooses to upgrade their plan.

Why would an app developer choose their model which has a minuscule 32K context window, might get throttled because of usage in another app, and doesn't share revenue over any frontier model vendor (where you can package/pass along token costs to your customers)?

> The hardest part was convincing people to download the Discord app on their phone as most of us didn't have it downloaded.

This was surprising to me – is this typical of most Discord users (primarily desktop users over mobile)?

Sure, but is that not what an online password manager is? :P

Yes. Mint also does this. From what I've heard, there are a lot of banks without APIs, so the next best approach is to login on behalf of users and scrape the data.

They're one of the few companies who are building GraphQL developer tools, so they have a financial incentive to have their name associated w/ GraphQL.

This piece, while somewhat valuable, is largely content marketing. First they sell you on the idea of "best practices." Then they'll follow up w/ a tool that, surprise, does all those "best practices" for you. "The modern marketer creates their own demand." Prisma is another GraphQL company that produces content like this.

Many GraphQL libraries take some sort of schema definition and then serve it at a route (eg. /graphql). To support multiple schemas, you'd just write a different definition and serve it at a different route. How you resolve the fields is up to you, but both can use shared underlying business logic in these resolvers.

In terms of maintainability, you have to take care that your changes to the underlying business logic don't break assumptions of each schema. And if you want to evolve one schema (eg. say, deprecate a mutation argument, rename a field and deprecate the old naming), you have to ensure that your underlying business logic is backwards compatible for any other schemas (and their clients) relying on it.

I agree. I think their recommendation is a bit overzealous.

I can see the argument if you have a web frontend that consumes data from multiple backend services – have one GraphQL service that manages them all instead of a GraphQL layer on each service.

But this breaks down greatly when you have different "Viewers". In a web app, the "Viewer" can be a logged in user. In an admin dashboard, the "Viewer" is very different – an employee acting on behalf of users. Service to service communication likely doesn't have a concept of a "Viewer".

I would propose that you have different schemas when you have these different views of the world or different permission boundaries. The business logic can be shared – you may just enforce different authorization checks at the GraphQL layer. You could also share GraphQL types that are common between schemas.