Run GraphQL on a Golang-based Query Optimization Engine

High performance. Low latency.

The threaded and scaleout nature of StepZen's in-memory GraphQL optimization and execution engine, along with a very efficient Kubrenetes deployment makes for below 10msec latency and easy scaleup to > 5000 requests/sec. Download the performance benchmark tool to assess the performance of a GraphQL implementation.

Visibility into performance

You get real metrics that help you debug, optimize and plan on your My StepZen dashboard. You can also access detailed logs that, depending on your plan, can be spooled to you continuously so that you can use your tools to understand and improve whatever you measure.

Minimized additional load on backend systems

Your backends were likely designed before GraphQL. So while GraphQL must be performant, it must also be careful with how it uses backends. StepZen processes GraphQL outside of the backends (unlike other systems that process GraphQL inside your production database) and:

• Parallelizes the execution

• Optimizes the order in which the various backends are accessed

• Minimizes the load on the backends by:

  • aggressive (but controllable) caching at all levels of GraphQL (query plan, query result, backend responses etc.)
  • using batching and data loader patterns for database, REST, and GraphQL backends (to avoid the N+1 problem)
  • memoization to reduce re-execution

Docs and Additional Resources

• Free Performance Benchmark Tool

• Measure API Performance (docs)

• Your Dashboard My StepZen

Your choice of development process

A GraphQL endpoint is typically built by more than one developer in the same GitHub repo. Deployment of a live endpoint happens using an admin key and can be coordinated across teams through GitHub actions.

The StepZen CLI, written in JavaScript, calls GraphQL endpoints for management tasks: deployment, un-deployment, introspection, and so on. You can string these together into your team’s development processes.

Manage change with min. coordination between teams

When working with federated graphs, or a graph of graphs, dependencies between the subgraphs are minimal — the query/mutation called by the enclosing type must be present and executable.

While coordination is never zero, it is minimal. If teams are clear about which query/mutation is used by someone else (done via a simple analysis of @materialzer), independent changes can be made relatively easily.

Prevent leaks across teams with query-based federation

StepZen minimizes the exposure by using query/mutation based federation, as opposed to resolver based federation. Better safety is ensured when the team that owns the subgraph of the enclosed subtype does the right validations of their query endpoints (after all those query endpoints can be called independently of the enclosing type).

Plug your API build and deploy into a CI/CD

Workflows using the stepzen import command and those using a code editor create files on your desktop that you then deploy (or check into GitHub and deploy from there). StepZen does not have a GUI to create your API. The text file model lets you easily hook into your favorite CI/CD pipeline. You can also import our node-based SDK into your CI/CD code.

Reflect backend changes in the deployed endpoint

StepZen code is intuitive - except for the connectivity to backends, there are few dependencies.

• A best practice is to keep the result of a stepzen import command, which generates your schema, in a separate file, and any changes made after that is created are kept in an extension file.
• Simple diffs then allow an automatic determination of the impact. This simplicity negates the need for a schema registry.

Docs and Additional Resources

• Autogenerate GraphQL Schemas using stepzen import

• Write GraphQL Schemas with Custom Directives

• Secure Your Schema and Endpoint

• StepZen CLI Reference

• StepZen GraphQL Directives Reference