[Do not merge] 2.0 with schema stitching #382

freiksenet · 2017-08-15T13:04:45Z

This is a WIP take on schema-stiching and schema merging. This will be published to a pre-release tag. See src/test/testingSchemas.js for examples..

API

makeRemoteExecutableSchema({ schema: GraphQLSchema, fetcher: Fetcher }): GraphQLSchema

Given a GraphQL schema (can be a non-executable client schema made by buildClientSchema) and a Fetcher, produce a GraphQL Schema that routes all requests to the fetcher.

introspectSchema( fetcher: Fetcher, context?: {[key: string]: any} ): Promise<GraphQLSchema>

Use fetcher to build a client schema using introspection query. For easy of use of makeRemoteExecutableSchema. Provides a client schema, so a non-executable schema. Accepts optional second argument context, which is passed to the fetcher.

Fetcher

type Fetcher = (
  operation: {
    query: string;
    operationName?: string;
    variables?: { [key: string]: any };
    context?: { [key: string]: any };
  },
) => Promise<ExecutionResult>;

Usage with apollo-link

import { HttpLink, makePromise, execute } from 'apollo-link';

const link = new HttpLink({ uri: 'http://api.githunt.com/graphql' });
const fetcher = (operation) => makePromise(execute(link, operation));
const schema = makeRemoteExecutableSchema({
  schema: await introspectSchema(fetcher),
  fetcher,
});

Usage with apollo-fetch

import { createApolloFetch } from 'apollo-fetch';

const apolloFetch = createApolloFetch({ uri: 'http://api.githunt.com/graphql'});
const fetcher = ({ query, variables, operationName, context}) => apolloFetch({
  query, variables, operationName
});
const schema = makeRemoteExecutableSchema({
  schema: await introspectSchema(fetcher),
  fetcher,
});

Usage with a generic HTTP client (like node-fetch)

import fetch from 'node-fetch';

const fetcher = async ({ query, variables, operationName, context }) => {
  const fetchResult = fetch('http://api.githunt.com/graphql', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ query, variables, operationName })
  });
  return fetchResult.json();
};
const schema = makeRemoteExecutableSchema({
  schema: await introspectSchema(fetcher),
  fetcher,
});

mergeSchemas

mergeSchemas({
  schemas: Array<GraphQLSchema | string>,
  resolvers?: (mergeInfo: MergeInfo) => IResolvers,
  onTypeConflict?: (
    left: GraphQLNamedType,
    right: GraphQLNamedType
  ) => GraphQLNamedType
})

type MergeInfo = {
  delegate(
    operation: 'query' | 'mutation',
    rootFieldName: string,
    args: any,
    context: any,
    info: GraphQLResolveInfo
  ) => any
}

schemas

schemas can be both GraphQLSchema (but it has to be an executable schema) or strings. In case they are strings only extensions (extend type) will be used. Passing strings is useful to add fields to existing types to link schemas together.

resolvers

resolvers is an optional a function that takes one argument - mergeInfo and
returns resolvers in makeExecutableSchema format.

mergeInfo and delegate

mergeInfo currenty is an object with one propeprty - delegate.

delegate takes operation and root field names, together with GraphQL context
and resolve info, as well as arguments for the root field. It forwards query to
one of the merged schema and makes sure that only relevant fields are requested.

mergeInfo.delegate(
  'query',
  'propertyById',
  {
    id: parent.id,
  },
  context,
  info,
);

onTypeConflict

onTypeConflict lets you customize type resolving logic. Default logic is to
take the first encountered type of all the types with the same name. This
methods allows customization of this, for example by taking other type or
merging types together.

Example

import {
  makeRemoteExecutableSchema,
  introspectSchema,
  mergeSchemas,
} from 'graphql-tools';
import { HttpLink, execute, makePromise } from 'apollo-link';

async function makeMergedSchema() {
  // Create remote executable schemas
  const PropertyLink = new HttpLink({
    uri: 'https://v7l45qkw3.lp.gql.zone/graphql',
  });
  const PropertyFetcher = operation =>
    makePromise(execute(PropertyLink, operation));
  const PropertySchema = makeRemoteExecutableSchema({
    schema: await introspectSchema(PropertyFetcher),
    fetcher: PropertyFetcher,
  });

  const BookingLink = new HttpLink({
    uri: 'https://41p4j4309.lp.gql.zone/graphql',
  });
  const BookingFetcher = operation =>
    makePromise(execute(BookingLink, operation));
  const PropertySchema = makeRemoteExecutableSchema({
    schema: await introspectSchema(BookingFetcher),
    fetcher: BookingFetcher,
  });

  // A small string schema extensions to add links between schemas
  const LinkSchema = `
    extend type Booking {
      property: Property
    }

    extend type Property {
      bookings(limit: Int): [Booking]
    }
  `;

  // merge actual schema
  const mergedSchema = mergeSchemas({
    schemas: [PropertySchema, BookingSchema, LinkSchema],
    // Define resolvers manually for links
    resolvers: mergeInfo => ({
      Property: {
        bookings: {
          fragment: 'fragment PropertyFragment on Property { id }',
          resolve(parent, args, context, info) {
            return mergeInfo.delegate(
              'query',
              'bookingsByPropertyId',
              {
                propertyId: parent.id,
                limit: args.limit ? args.limit : null,
              },
              context,
              info,
            );
          },
        },
      },
      Booking: {
        property: {
          fragment: 'fragment BookingFragment on Booking { propertyId }',
          resolve(parent, args, context, info) {
            return mergeInfo.delegate(
              'query',
              'propertyById',
              {
                id: parent.propertyId,
              },
              context,
              info,
            );
          },
        },
      },
    }),
  });

  return mergedSchema;
}

Known issues

Production ready checklist

Documentation
Example app(s)
Blog post / announcement
Get rid of lodash and other extra deps
Validate usage in production for several people
Move all tests to not use .to.not.be.undefined, really hard to debug. use .to.deep.equal for full response

stubailo · 2017-08-15T17:35:03Z

Made the tests pass by adding @types/lodash package!

One idea: What if instead of prefixing field names, we put them in a nested field? Like:

# current
query {
  Booking_bookingById {
    ...
  }
}

# proposed
query {
  Booking {
    bookingById { ... }
  }
}

stubailo

Some initial comments, more to come

stubailo · 2017-08-15T17:49:26Z

src/stitching/TypeRegistry.ts

+
+  public getSchema(name: string): GraphQLSchema {
+    if (!this.schemas[name]) {
+      throw new Error(`No such type: ${name}`);


This should be "no such schema" - do we even need these getters though? Would it be easier to just make schemas public?

Then it won't type check :)

Wait really? Why not?

stubailo · 2017-08-15T17:50:12Z

src/stitching/TypeRegistry.ts

+    return this.linksByType[name] || [];
+  }
+
+  public getLinkByAddress(typeName: string, link: string): SchemaLink {


Maybe getLinkByFieldName?

stubailo · 2017-08-15T17:52:42Z

src/stitching/addSimpleRoutingResolvers.ts

+
+export default function addSimpleRoutingResolvers(
+  schema: GraphQLSchema,
+  // prolly should be a fetcher function like (query) => Promise<result>


Yep - I'll want this for the demo. Might write it

stubailo · 2017-08-15T18:14:39Z

src/stitching/mergeSchemas.ts

+  const queryFields = registry.query.getFields();
+  return fromPairs(
+    links.map(link => {
+      const [schemaName, field] = link.to.split('_');


Hmm, I think it would be better if we took two separate arguments for schema and field name, instead of splitting them on _. This couples it to the serialization we choose in a different part of the code.

Yeah, whole namespacing related code is a bit of a hack and will be better once we figure out proper namespaces.

timbotnik · 2017-08-15T23:31:50Z

RE: prefixing - my initial use-case is to merge an existing in-production schema with a new one. This means that actually I don't want to prefix my existing schema at all, that should be supported shouldn't it?

stubailo · 2017-08-16T00:01:37Z

@timbotnik say more? Oh you mean you just want to graft a new one onto an existing one?

I think it would make sense to be able to have no prefix at all.

timbotnik · 2017-08-16T00:20:41Z

@stubailo yes "grafting" is a good word for it ;-) Also, if you knew for sure that there would be no namespace conflicts, it could be useful to support a non-prefixed merge in general.

Thinking through a general case for non-prefixed merges, something that would be amazing would be if there was a way to handle de-duplication. I'm thinking more here about things like custom scalars and "utility" types that could be imagined to resolve exactly the same way on either endpoint.

Maybe more complicated, but also worth considering that an interface type might be shared between two schemas but each schema provides a different implementation.

stubailo · 2017-08-16T00:24:00Z

Yeah - I think the deduplication is probably going to be a future thing. Do you think it's critical for your initial use case?

timbotnik · 2017-08-16T00:26:51Z

@stubailo I don't think it's critical at all, however the "custom scalar" thing is probably the thing that will look the strangest - like having Timestamp and Void [NS]_Timestamp and [NS]_Void in the final schema.

stubailo · 2017-08-16T00:30:47Z

Yeah, that's a great point. We should definitely work towards that. Having a concrete production use case would be super great.

freiksenet · 2017-08-16T06:40:06Z

@timbotnik We didn't really plan for "grafting" use case, some of the code would probably be shared, but I don't think we will support it in first iteration. However it seems that there are lots of use cases in schema merging, so I'll definitely think on how to allow some customization of how stuff will be merged, maybe providing functions to resolve type conflicts.

(Having said that, we really don't know what is the end goal of what we are doing, it's very much explanatory thing and a way to collect schema use cases. Maybe grafting is a very common one and then we'll certainly support it)

freiksenet · 2017-08-16T06:41:24Z

@timbotnik Re: de-duplication, our longer term plan involved having namespaces that can depend on other namespaces for shared types. Thus you could have 'common types' as one namespace and use scalars and shared types from there.

freiksenet · 2017-08-16T06:43:10Z

@stubailo This could work for field namespacing, but we would still need namespaces for types. I'm not sure :)

stubailo · 2017-08-16T15:54:10Z

package.json

@@ -49,24 +49,26 @@
  "homepage": "https://github.com/apollostack/graphql-tools#readme",
  "dependencies": {
    "deprecated-decorator": "^0.1.6",
+    "lodash": "^4.17.4",


Hmmm for the final release it would be super awesome to not include lodash - for client side use that really kills the bundle size.

Yeah, we can either inline them or use lodash/function modules.

timbotnik · 2017-08-17T01:59:59Z

@freiksenet I think perhaps the definition of "grafting" is getting confused. By this, all I mean is that I want to use an existing "local" schema (that I already have clients using in production), and merge a new schema onto it. Since the existing schema is already in use in the wild, I don't want to introduce a prefix on that schema. I think the only feature ask here is to allow me to turn off prefixing for this one schema during the merge.

stubailo · 2017-08-17T03:32:57Z

Just published 2.0.0-alpha.1! You can install with npm install graphql-tools@next!

freiksenet · 2017-08-17T05:03:22Z

@timbotnik Ah, now I get it. Yeah, I will separate namespacing from merging today.

…

On Thu, 17 Aug 2017, 5.00 timbotnik ***@***.***> wrote: @freiksenet <https://github.com/freiksenet> I think perhaps the definition of "grafting" is getting confused. By this, all I mean is that I want to use an existing "local" schema (that I already have clients using in production), and merge a new schema onto it. Since the existing schema is already in use in the wild, I don't want to introduce a prefix on that schema. I *think* the only feature ask here is to allow me to turn off prefixing for this one schema during the merge. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#382 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKjiBznbY9X96nZZKYL0Xval4VRzpyxks5sY56ggaJpZM4O3jxQ> .

trevordmiller · 2017-08-18T16:17:05Z

I'm excited for makeRemoteExecutableSchema! Thank you.

stubailo · 2017-08-18T20:29:53Z

BTW here's my sample code from the talk at GraphQL NYC! This only works with 2.0.0-alpha.5 - the API for future alphas is a bit different.

import * as express from "express";
import * as bodyParser from "body-parser";
import { graphqlExpress, graphiqlExpress } from "apollo-server-express";
import { makeRemoteExecutableSchema, mergeSchemas } from "graphql-tools";
import { createApolloFetch } from "apollo-fetch";

async function run() {
  // XXX fix typings
  const universeSchema = await makeRemoteExecutableSchema(
    createApolloFetch({
      uri: "https://www.universe.com/graphql/beta"
    }) as any
  );

  const weatherSchema = await makeRemoteExecutableSchema(
    createApolloFetch({
      uri: "https://5rrx10z19.lp.gql.zone/graphql"
    }) as any
  );

  const schema = mergeSchemas({
    schemas: [
      { prefix: "universe", schema: universeSchema },
      { prefix: "weather", schema: weatherSchema }
    ],
    links: [
      {
        name: "location",
        from: "Event",
        to: "weather_location",
        resolveArgs: parent => ({ place: parent.cityName }),
        fragment: `
          fragment WeatherLocationArgs on Event {
            cityName
          }
        `
      }
    ]
  });

  const app = express();

  app.use("/graphql", bodyParser.json(), graphqlExpress({ schema }));

  app.use(
    "/graphiql",
    graphiqlExpress({
      endpointURL: "/graphql"
    })
  );

  app.listen(3000);
  console.log("Listening!");
}

try {
  run();
} catch (e) {
  console.log(e, e.message, e.stack);
}

Here's the query and result:

Also here are my slides for the talk: https://www.slideshare.net/sashko1/modular-graphql-with-schema-stitching

stubailo · 2017-08-19T16:25:20Z

I added tests that check for local schema merging, remote schema merging, and a hybrid of the two.

Should help us catch bugs with remote schemas! Already found one :]

nnance · 2017-08-19T18:12:05Z

@freiksenet @stubailo this is amazing stuff. so much progress in such a short amount of time. so I have been very busy decomposing our production graphql server over the last couple of weeks. I have decomposed them into something we call GraphQL modules. It's in the perfect state to use this project to test a production use case. The only problem is that I will not be able to share the project. However, we are currently merging/stitching 6 modules together at build time to make up our GraphQL server including a pretty large set of common types so it should be a good use case. I will be able to share snippets as I find problems.

Would this be helpful?

stubailo · 2017-08-20T02:07:29Z

Absolutely! Please let us know whatever problems you run into, and also what features are missing for you to be able to use the tool :)

Super excited to see people getting pumped about this.

timbotnik · 2017-08-21T04:25:27Z

src/stitching/addSimpleRoutingResolvers.ts

+  }
+
+  const resolvers: {
+    Query: ResolverMap;


Remote schemas are not working if they have root types that are not called Query or Mutation, such as

schema { query: RootQuery mutation: RootMutation }

b/c the schema actually needs to be transformed as well to replace RootQuery => Query etc

You get errors like Error: "Query" defined in resolvers, but not in schema

Fixed that.

gilesbradshaw · 2017-08-23T21:19:04Z

How easy to get this working over websockets?

stubailo · 2017-08-23T21:20:24Z

@gilesbradshaw you could easily get queries and mutations over websockets working with the right fetcher passed in, but for subscriptions it gets a bit more complicated for sure. That would be a big extra feature on top of this.

stubailo

This needs a changelog entry 😛

freiksenet · 2017-10-03T08:18:38Z

@sashko 🖕

This is ready to ship now :)

Fixed!

lifeiscontent · 2017-10-03T08:46:42Z

@freiksenet where can I find the documentation for this now that this is merged?

pozylon · 2017-10-03T18:17:13Z

Awesome this seems to be done, but I just tried it and aliases don't work anymore if routed through makeRemoteExecutableSchema.

martijnwalraven · 2017-10-03T18:21:08Z

@pozylon: Can you elaborate on that and maybe include a code example that shows what doesn't work?

pozylon · 2017-10-03T18:29:20Z

Of course, sorry, here you go with the query:

{
  orders {
    status
    created
    updated
    ordered
    confirmed
    fullfilled
    currency
    it: total(category: ITEMS) {
      amount
      currency
    }
  }
}

I run it in GraphiQL and that was the result without proxying:

{
  "data": {
    "orders": [
      {
        "status": "CONFIRMED",
        "created": 1506586141020,
        "updated": 1506586183279,
        "ordered": 1506586183294,
        "confirmed": 1506586183294,
        "fullfilled": null,
        "currency": "CHF",
        "it": {
          "amount": 5958,
          "currency": "CHF"
        }
      },...

And that's what happens with proxying through the stitching:

{
  "data": {
    "orders": [
      {
        "status": "CONFIRMED",
        "created": 1506586141020,
        "updated": 1506586183279,
        "ordered": 1506586183294,
        "confirmed": 1506586183294,
        "fullfilled": null,
        "currency": "CHF",
        "it": null
      },...

total is of type "Money" which has a currency and amount (String + Int)

martijnwalraven · 2017-10-03T18:31:29Z

@pozylon: So are you saying it works if you remove the it alias for total?

pozylon · 2017-10-03T18:34:46Z

@martijnwalraven: exactly, if i call it without the alias it's all fine.

martijnwalraven · 2017-10-03T18:36:51Z

@pozylon: Great, thanks for explaining. @freiksenet, do you have any idea what could be causing this?

gviligvili · 2017-10-04T04:25:41Z

I have a micro service (A) which has no protection.
so I stitch it to my main app server (B) which has protection.

is there a recipe on how to (B) can protect (A) queries? Like to if the user authorized or validate logic first?

pozylon · 2017-10-04T05:42:40Z

@gviligvili: Use a middleware together with apollo-fetch based Fetcher and cancel requests when appropriate. https://github.com/apollographql/apollo-fetch

freiksenet · 2017-10-04T08:49:09Z

@lifeiscontent we'll merge in the docs asap, see https://github.com/apollographql/tools-docs/pull/134 for progress.

@pozylon Thanks, i'll check it.

freiksenet · 2017-10-04T09:06:13Z

@pozylon Fixed in #411

Techbinator · 2017-10-04T11:28:06Z

Hello again,

I have a small issue stitching a schema that was automatically generated with postgraphql library(https://github.com/postgraphql/postgraphql).

The service works fine on it's own but when i try to mergeSchemas i get "Unhandled promise rejection (rejection id: 1): Error: No such type: Query".

I already stitched 3 other services and it works perfectly.

You can find here the generated schema https://gist.github.com/filtudo/40ffe1bf27863d736e1646f9576dab4d

And here a link with the graphiql schema docs
https://pasteboard.co/GNmvbyz.png

Any help or guidance would be greatly appreciated.

Cheers

freiksenet · 2017-10-04T12:47:29Z

@filtudo The reason it doesn't work is because it refers to Query type in each payload. We handle Query type specially, tbh I didn't envision Query used this way. I wonder how common such use case is in practice.

Ping @sashko @jbaxleyiii @martijnwalraven

Techbinator · 2017-10-04T17:48:05Z

@freiksenet

Any chance on "tackling" this issue on your side(since postgraphql i would say is a pretty decently used library) or i should start thinking of alternatives/hacks for this case?

Thank you

freiksenet · 2017-10-05T10:45:57Z

@filtudo It seems to be a common pattern in many APIs to support Relay, so I will fix it, yes.

freiksenet · 2017-10-05T10:59:08Z

@filtudo Fixed in #413

freiksenet · 2017-10-05T11:13:22Z

@filtudo Published as 2.2.1.

@pozylon Your bug is fixed in 2.2.0.

Hey folks, this is part of main release now, please create new issues if you have any problems with schema stitching, it's hard to track this thread cause it's closed.

freiksenet requested a review from stubailo August 15, 2017 13:04

stubailo force-pushed the schema-stitching branch from 1e62433 to ff5d9b2 Compare August 15, 2017 17:42

stubailo changed the title ~~[WIP] First take on schema stiching~~ [WIP] First take on schema stitching Aug 15, 2017

stubailo previously requested changes Aug 15, 2017

View reviewed changes

stubailo reviewed Aug 16, 2017

View reviewed changes

stubailo changed the title ~~[WIP] First take on schema stitching~~ [Do not merge] 2.0 with schema stitching Aug 17, 2017

stubailo mentioned this pull request Aug 18, 2017

Feature request: allow .json schema files in makeExecutableSchema #366

Closed

timbotnik reviewed Aug 21, 2017

View reviewed changes

This was referenced Aug 21, 2017

Allow for multiple remote endpoints apollographql/apollo-client#84

Closed

Feature Request: graphql Server Chaining apollographql/apollo-server#4

Closed

Implement new schema stitching API

8133dca

freiksenet force-pushed the schema-stitching branch from 4a2e62f to 8133dca Compare October 2, 2017 11:41

stubailo previously requested changes Oct 3, 2017

View reviewed changes

freiksenet added 3 commits October 3, 2017 11:06

Don't include arguments that shouldn't be there

8d64bf3

2.0.0-alpha.26

aafb08d

Add CHANGELOG

c2a0768

freiksenet merged commit a834411 into master Oct 3, 2017

freiksenet deleted the schema-stitching branch October 3, 2017 08:41

Redmega mentioned this pull request Nov 3, 2017

[gatsby-source-graphcms] Add GraphCMS Plugin gatsbyjs/gatsby#1867

Closed

4 tasks

This was referenced Feb 7, 2018

[Idea] Create Apollo on Dependency Injection level kamilkisiela/apollo-angular#460

Closed

Is it possible to lazy load resolvers? apollographql/apollo-link-state#175

Open

[Do not merge] 2.0 with schema stitching #382

[Do not merge] 2.0 with schema stitching #382

Conversation

freiksenet commented Aug 15, 2017 • edited Loading

API

makeRemoteExecutableSchema({ schema: GraphQLSchema, fetcher: Fetcher }): GraphQLSchema

introspectSchema( fetcher: Fetcher, context?: {[key: string]: any} ): Promise<GraphQLSchema>

Fetcher

Usage with apollo-link

Usage with apollo-fetch

Usage with a generic HTTP client (like node-fetch)

mergeSchemas

schemas

resolvers

mergeInfo and delegate

onTypeConflict

Example

Known issues

Production ready checklist

stubailo commented Aug 15, 2017

stubailo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timbotnik commented Aug 15, 2017

stubailo commented Aug 16, 2017

timbotnik commented Aug 16, 2017

stubailo commented Aug 16, 2017

timbotnik commented Aug 16, 2017

stubailo commented Aug 16, 2017

freiksenet commented Aug 16, 2017 • edited Loading

freiksenet commented Aug 16, 2017

freiksenet commented Aug 16, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timbotnik commented Aug 17, 2017

stubailo commented Aug 17, 2017

freiksenet commented Aug 17, 2017 via email

trevordmiller commented Aug 18, 2017

stubailo commented Aug 18, 2017 • edited Loading

stubailo commented Aug 19, 2017

nnance commented Aug 19, 2017

stubailo commented Aug 20, 2017

timbotnik Aug 21, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gilesbradshaw commented Aug 23, 2017

stubailo commented Aug 23, 2017

stubailo left a comment

Choose a reason for hiding this comment

freiksenet commented Oct 3, 2017 • edited Loading

lifeiscontent commented Oct 3, 2017

pozylon commented Oct 3, 2017

martijnwalraven commented Oct 3, 2017

pozylon commented Oct 3, 2017

martijnwalraven commented Oct 3, 2017

pozylon commented Oct 3, 2017

martijnwalraven commented Oct 3, 2017

gviligvili commented Oct 4, 2017 • edited Loading

pozylon commented Oct 4, 2017

freiksenet commented Oct 4, 2017

freiksenet commented Oct 4, 2017

Techbinator commented Oct 4, 2017 • edited Loading

freiksenet commented Oct 4, 2017 • edited Loading

Techbinator commented Oct 4, 2017 • edited Loading

freiksenet commented Oct 5, 2017

freiksenet commented Oct 5, 2017

freiksenet commented Oct 5, 2017 • edited Loading

freiksenet commented Aug 15, 2017 •

edited

Loading

freiksenet commented Aug 16, 2017 •

edited

Loading

stubailo commented Aug 18, 2017 •

edited

Loading

timbotnik Aug 21, 2017 •

edited

Loading

freiksenet commented Oct 3, 2017 •

edited

Loading

gviligvili commented Oct 4, 2017 •

edited

Loading

Techbinator commented Oct 4, 2017 •

edited

Loading

freiksenet commented Oct 4, 2017 •

edited

Loading

Techbinator commented Oct 4, 2017 •

edited

Loading

freiksenet commented Oct 5, 2017 •

edited

Loading