Entity design: creating a new entity vs. adding to an existing entity

Schema Design
,
1

Hiya folks!

We have several teams, one for each entity in our portal: Accounts, Apps and Users. Each team managed its own subgraph in the federation, with the Users and Apps teams adding data to the Account entity (likes account owner and apps).

A fourth team that’s dealing with the business aspects of the account - subscription plans, billing, assigned CSM etc. - would also like to get on the federation train.

Naturally they’ll have their own physical subgraph, so no one steps on anyone’s toes in source control. The only decision we need to make is whether we let that business-account team create a new entity (“BizAccount”?), or add their data to the current Account entity - much like the Users and Apps team do.

This sounds like a decision that some of you have already dealt with - can we benefit from your wisdom and experience here? What should dictate the decision here?

Thanks in advance!

1 Like
2

Hi @deebugger , without some more information, I am not sure if there is an exact right answer that I can provide, but I’ll give you some general thoughts and options based on my experience.

Let me first tackle the question of whether or not to let them create a new entity since that is the easiest question: Yes, you should absolutely allow them to create a new entity if that solves a problem for the business.

However, by creating a new entity, you lose the power of federated entities if each team creates their own representation of the same core business objects. It is often tempting for teams to create their own representations of a domain model that does not federate (or “join”) to other domain objects so they teams can live in their own silos and not step on each other’s toes, but this just moves the complexity to the client side since the clients now have to know all of the different domain models to get what they need, so it really doesn’t solve any problems for the business.

Now let’s ask the question of whether they should create a new entity or not by asking a few more questions:

  1. Is there a business-wide (or at least cross-team) recognizable key of the account entity that truly represents an account?
    • Yes points towards shared entity
  2. Does the fourth team use this key for their account object?
    • Yes points towards shared entity
  3. Is the other team prepared to tackle any newer authorization patterns and differences that federation introduces?
    • Yes points towards shared entity
  4. How will the clients need/want to query for this data? Would they prefer it on the account object?
    • Preferring it on the account object points towards shared entity
  5. If they create a new account object, are they also prepared to create their own Queries
    so that clients can get access to their object, or would they rather just contribute the fields to something already accessible?
    • Prefer to use something already accessible points towards shared entity

I would generally always aim to contribute to entities where you are referencing the same object, especially if the client thinks of them as the same thing. If they are different objects with different keys, don’t try to shoehorn them into the same entity because they have similar shapes.

1 Like
3

Hey @andywgarcia - what’s up?

This is exactly what I was looking for: a set of decision points to help us get to a solution that will benefit everyone, so thanks for your input - it’s very helpful!

In the internal discussion we had about this, I was always pushing for a shared entity, where team 4 would add fields to the Account entity, but it was based more on a hunch (since we’re all new in this federation business). I guess my gut instincts were right, and now I have some solid ground to stand on:

  • The key is indeed shared
  • Clients shouldn’t usually care where the data is coming from (SalesForce, billing DB or the core database) - they just want an account to query about
  • There’s no point in creating new queries because clients would usually need billing and core data, so we might as well package them in a single query

I have to admit that I didn’t fully understand your question about the authorization patterns - could you elaborate more about this aspect? (but only if you have the time - you’ve done more than enough to help out already!)

Thanks again - much appreciated!