<commit_before>Querying The Distributed Structure
===================================

We now have three different services which are each responsible for maintaining
a small bit of the application. While this has many benefits, one rather large
annoyance is the difficulty to create a summary of our application using data
that spans many services.

One way to solve this is to create a service known as an "API gateway" which,
unlike the services we have encountered so far, does not maintain any sort of
internal state. Instead, this service just has a single schema that describes
the entire cloud. This has a few major benefits that are worth pointing out:

* The distributed nature of the cloud is completely hidden behind a single endpoint
* Authorization is maintained by a single service
* Various network optimizations only need to occur in a single place
* The list of external mutations is in one place


Let's begin by creating a new file called ``api.py`` in our directory with the
following contents:

.. code-block:: python

    # external imports
    from nautilus import APIGateway, ServiceManager

    class RecipeBookAPI(APIGateway): pass


    manager = ServiceManager(service)

    if __name__ == '__main__':
        manager.run()


If you try to run this file as is, an exception will be thrown since we have
not provided the service with a schema that describes the complete topology of
our cloud.

Normally, supporting this schema involes bouncing a lot of different queries
between various ModelServices and their connections in order to create a single
report. This easily becomes very difficult to maintain, is prone to bugs,
and leads to a significant amount of code duplication (which is bad). Nautilus
makes the creation and evaluation of this schema significantly easier.

Rather than basing your object types on an SQLAlchemyObjectType like
before, services that you wish to use as representation for an external service
should be based on the SerivceObjectType. Add the following code block at the
end of the api gateway file:

.. code-block:: python

    from graphene import String, ObjectType, Schema
    from nautilus.api import ServiceObjectType, Connection<commit_msg>api docs now reference nautilus-registry<commit_after>Querying The Distributed Structure
===================================

We now have three different services which are each responsible for maintaining
a small bit of the application. While this has many benefits, one rather large
annoyance is the difficulty to create a summary of our application using data
that spans many services.

One way to solve this is to create a service known as an "API gateway" which,
unlike the services we have encountered so far, does not maintain any sort of
internal state. Instead, this service just has a single schema that describes
the entire cloud. This has a few major benefits that are worth pointing out:

* The distributed nature of the cloud is completely hidden behind a single endpoint
* Authorization is maintained by a single service
* Various network optimizations only need to occur in a single place
* The list of external mutations is in one place


Let's begin by creating a new file called ``api.py`` in our directory with the
following contents:

.. code-block:: python

    # external imports
    from nautilus import APIGateway, ServiceManager

    class RecipeBookAPI(APIGateway): pass


    manager = ServiceManager(service)

    if __name__ == '__main__':
        manager.run()


If you try to run this file as is, an exception will be thrown since we have
not provided the service with a schema that describes the complete topology of
our cloud.

Normally, supporting this schema involes bouncing a lot of different queries
between various ModelServices and their connections in order to create a single
report. This easily becomes very difficult to maintain, is prone to bugs,
and leads to a significant amount of code duplication (which is bad). Nautilus
makes the creation and evaluation of this schema significantly easier.

Rather than basing your object types on an SQLAlchemyObjectType like
before, services that you wish to use as representation for an external service
should be based on the SerivceObjectType. Add the following code block at the
end of the api gateway file:

.. code-block:: python

    from graphene import String, ObjectType, Schema
    from nautilus_registry.objectTypes import ServiceObjectType
    from nautilus_registry.fields import Connection
{'fraction_non_alphanumeric': 0.046, 'fraction_numerical': 0.0, 'mean_word_length': 4.502444987775061, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2727524', 'n_tokens_mistral': 1065, 'n_tokens_neox': 999, 'n_words': 650}