Actually I’m building all my database schema and the graphql api, but I have a question about phoenix 1.3 generators and project organization with absinthe
This will generate a migration, tests, controllers, a “producer” schema and a “Producers” file that works as a boundary (get by id, delete etc…), in normal examples of absinthe you create a resolver folder with files that work exactly like the boundary file in phoenix 1.3, so… in Phoenix 1.3 this “resolvers” can be replace by the boundary file, no? (of course need to change the definitions fiels but is not a big work I suppose)
PD: I see the DDD structure as you work in projects with c#, correct me if I’m wrong
This is a great question, and really an area of on going discussion. There’s basically 2 approaches depending on how you think about resolvers
Option 1) Resolvers are like controllers. In this scenario you maintain the resolvers separately from your boundary / context files just like you would controllers, and you call those context files from your resolvers.
Option 2) Resolvers sit at the boundary. In this scenario it’s up to the boundary file to know how to resolve content inside its boundary, and the Schema takes on the role of a regular controller stack, calling out to these boundary functions to do what it needs.
Although my first reaction when I heard about the Phoenix 1.3 plans was to go with Option 1, I’m increasingly convinced that Option 2 is the way to go. There’s more to be said here but I’m gonna leave it at that for the moment and expound as necessary.
FWIW I’m doing an umbrella app with my Ecto stuff separated from my GraphQL stuff. My graphql is not a 1-to-1 mapping of my actual schema, so the separation is important to me.
My Ecto App has Contexts, and My Graphql App has resolvers that use the Contexts (and then my web app uses absinthe plug).
The advantages of this for me are that it’s really easy to enforce how things are accessed. For example, there are some has-many relationships that can only be accessed via the parent object. I don’t expose any get/list functions for these in my context. It sets up the Context as the source of truth for how to access things.
The main disadvantage for me is that I can’t used absinthe-ecto. The helper methods there are super handy - but they also require direct access to the schema. I’ve ended up splitting up bits and pieces of it to use in my ecto app and my graphql app respectively but it’s still a work in progress.
