Services should announce their API contributions when they run

[AlecAivazis]

The api gateway should respond by adding the relavant bits to the schema. Published data could include:

• mutations
• connection

[AlecAivazis]

Some requirements are:

• name of node
  • handled by name of type definition
• fields in node
  • handled by field definitions
• connection
  • if announced by the atomic service, I need some way of pulling it out
  • this can be done with special __<foo>__ syntax

[AlecAivazis]

One option is a structured json payload:

{
    "name": "recipes",
    "fields": [
        {
            "name": "name",
            "type": "String",
        }, {
            "name": "cookTime",
            "type": "Int",
        }
    ],
    "connections": [
        {
            "name": "ingredients",
            "target": "ingredients",
            "type": "many" 
       },
       {
            "name": "author",
            "target": "user",
            "type": "one",
        }
   ]
}

[AlecAivazis]

To keep the services de-coupled, I probably want to avoid the connections attribute in the above spec. So connection services must announce themselves and have the api connect the two nodes in its schema. That specification could look something like the example below. This allows for additional meta-data concerning the relationship.

{
    "name": "favoriteRecipes",
    "fields": [
        {
            "name": "recipe",
            "type": "ID",
            "connection": "many",
        }, {
            "name": "user",
            "type": "ID",
            "connection": "one",
        }, {
            "name": "dateLiked",
            "type": "String"
        }
    ]
}

[AlecAivazis]

This means that connection services need to know the kind of relationship ('one' || 'many') when it's specified. How would that look?

[AlecAivazis]

Could be something along the lines of:

class Connected(nautilus.ConnectionService):
    services = [
       (Service1, 'one'),
       (Service2, 'many')
    ]

[AlecAivazis]

I'm not really convinced that the above spec is the right one for connection model serialization. One major issue is that the logic required to differentiate the two relies on conventions which make me think that they should just have different formats all together (rather than relying on the existence of a particular field). An alternative is:

{
    "name": "favoriteRecipe",
    "fields": [
        {
            "name": "dateLiked",
            "type": "String"
        }
    ],
    "connection": {
        "from": {
           "service": "user",
           "type": "one",
        },
        "to": {
            "serivce": "recipe",
            "type": "many",
        }
    }
}

One downside is that this limits connections to only connecting two nodes. This might not be a problem in a graph-based api

[AlecAivazis]

If i tried to support more than a single, directional relationshp, this format would be increasingly more complicated. If the underlying connection service manages multiple entries, they could always publish many copies of this event for each relation

[AlecAivazis]

It also doesn't make sense to think of one or many for the origin of the connection because i think it will always be one in this paradigm.