perf: add a raw graphback using fastify graphql benchmark server

[machi1990]

This follows up my reading on
https://www.nearform.com/blog/implementing-a-graphql-gateway-with-fastify/

Checkout the numbers from the first two rows of the stats table:

When I was writing this I also had ideas:

• of a blog post for writing a graphback template / app with fastify.
• using fastify for graphql-serve instead

WDYT?

[wtrocki]

@machi1990 I have no words how awesome this work is! It is really deserving short blog post or tweet about how we improved performance. I will also check how we can get Apollo to work the same - what is causing 200% decrease.

I will also apply those patterns to datasync starter.

[machi1990]

@machi1990 I have no words how awesome this work is! It is really deserving short blog post or tweet about how we improved performance.

Let's wait for #2057 and once that is merged, we'll see myself and @craicoverflow how we can make this happen.

I was also thinking of a simple blog post on how to write a graphback template, but this can also be section in our docs (I'll need to think more about this idea). For now, I am leaning towards:

• creating an issue to offer a plain fastify template (this won't have anything to do with Graphback templates improvments #2035), this template can go with the tweet / blog post about perf...
• creating an issue to update graphql-serve to use fastify. If @wtrocki and @craicoverflow agree with me on this.

I will also check how we can get Apollo to work the same - what is causing 200% decrease.

I do not think I'll be looking into that for now. If you'll be up for it, I'll be looking forward to your findings.

I will also apply those patterns to datasync starter.

Yeap.

[craicoverflow]

@machi1990 these numbers look great - to be honest I don't have a strong understanding of their meanings other than startup time, so I am happy for you to use fastify with GraphQL Serve!

[machi1990]

@machi1990 these numbers look great - to be honest I don't have a strong understanding of their meanings other than startup time, so I am happy for you to use fastify with GraphQL Serve!

Sure, here is the lowdown.

1. request count - the higher the better (total number of requests sent within a second).
2. Latency (in milliseconds) - the lower the better, time it takes to process the request and receive a response
3. Throughput in megabyes, total load transfer, the higher the better.
4. Startup, the time it took to receive the first OK response, the lower the better

The rest are just noise in terms of resource consumptions e.g memory and cpu (their measurement is not that precise but gives us an indication of how we much resource a graphback can consume during startup). The lower the better, especially in constrained container environments where you'd spin several instances (scale horizontally) of your graphback application.

[wtrocki]

Investiging in serve makes no sense for me - graphql serve it is not going to be used in production due to in memory db that cannot be swapped. Work that I'm doing now - using container with schema provided will greatly benefit from fastify but there are limitations (keycloak etc).

[machi1990]

Makes no sense for me - graphql serve it is not going to be used in production due to in memory db that cannot be swapped. Work that I'm doing now - using container with schema provided will greatly benefit from it.

Okay, I hear the argument but in my case, be it in dev or prod environment, i'd prefer a performant version of my app especially if the investment cost is the same. But this is not priority for now, we can revisit it later.

[wtrocki]

creating an issue to offer a plain fastify template (this won't have anything to do with #2035), this template can go with the tweet / blog post about perf...

That will be cool - will do that as well for container/datasync-starter

[machi1990]

creating an issue to offer a plain fastify template (this won't have anything to do with #2035), this template can go with the tweet / blog post about perf...

That will be cool - will do that as well for container/datasync-starter

I've opened #2065 to track this. It is a good first issue and a great way for someone to get familiar with various Graphback's concepts