Run GraphQL on a Golang-based Query Optimization Engine
Scale and secure APIs and backends. No servers or infrastructure to manage.
Sign UpCore Kubernetes-based Architecture
- Most components in Golang
- Introspection in Scala
- JavaScript CLI, and SDK available
Run your GraphQL on an engine optimized with the best API & database techniques
A benefit of the declarative approach is optimizing the execution of queries. However, GraphQL queries are not exactly like database queries — GraphQL queries are hierarchical and the source of data is varied (is not in tables and views managed by the database system).
Deployment
You can deploy your GraphQL APIs on StepZen's cloud service, on your private cloud, or to a colocation data center.
Deploy on StepZen's Cloud
StepZen runs your GraphQL as a managed service on Google Cloud providing the following capabilities.
-
AutoScaling: StepZen automatically scatters your workload across our Kubernetes cluster. Scales to meet your traffic throughput.
-
Low latency: We typically see a 6-12 msec. latency in our optimized, in memory (for both data and runtime state) GraphQL engine.
-
Parallelized execution
-
A stable IP address to whitelist at your firewall - Whitelist IP address.
-
Global points of presence (PoP): Google Cloud has a global PoP footprint. Regardless of where your traffic originates, it enters the Google network at the nearest PoP and is subsequently routed to our servers within the Google backbone fiber optic network.
Private Cloud or Colo
StepZen can be deployed on Kubernetes (any recently released GA Kubernetes version is supported).
-
We can provision StepZen's managed service in any environment where we have access to a functional Kubernetes cluster - in AWS, Azure, and Google Cloud, any virtual private cloud (VPC), or a Colocation facility.
-
StepZen stores all metadata in a PostgreSQL database. For private managed service deployments as above, we recommend PostgreSQL 14. However, versions 12, 13 and 15 will also work.
-
We will partner with you to get StepZen running as a service in your VPC or Colo. See docs for the information we'll need from you.
Contact us to learn about regions and other public cloud deployment options and entitlements.
Performance
StepZen's in-memory, Golang-based query optimization engine delivers auto-parallelism, pushdowns, caching (various levels), N+1 optimizations, memoization, and more.
High performance & availability. Low latency.
The threaded and scaleout nature of StepZen's in-memory GraphQL optimization and execution engine, along with a very efficient Kubernetes deployment makes for below 10msec latency and easy scaleup to > 5000 requests/sec. Our availability, measured between January 1st, 2023 and 31st April, 2023 by running a query every 60 seconds from 6 global locations over the 4 month period exceeds 99.99%. Download the performance benchmark tool to assess the performance of a StepZen GraphQL implementation yourself.
Visibility into performance
You get real metrics that help you debug, optimize and plan on your 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
Security
GraphQL simplifies access to data. With that comes challenges. Is your GraphQL endpoint secure? Are backends secure from queries/mutations from your GraphQL APIs?
GraphQL Building Blocks
StepZen’s architecture is an assembly of declarative GraphQL building blocks and stitched together by data passing between the blocks. Each block represents a database, API or GraphQL backend.
Queries, mutations and subscriptions have simple enforcement mechanisms for authorization and authentication, and the path that a complex GraphQL executes is by calling a series of queries, and thus, all enforcement mechanisms naturally carry through.
TLS 1.2+, API Keys and JWT
-
All inbound and outbound traffic is protected by TLS 1.2+
-
Access to queries/mutations is protected by API Keys and JWT. You can write simple rules that check against the claims and allow or disallow access to the queries/mutations. For example, these rules can check for valid query arguments, or for roles.
-
When accessing backend databases, StepZen prepares the statement before execution (this is not an overhead since the preparation is done once and cached).
-
When accessing an HTTP backend, StepZen supports whatever protection mechanism the backend uses – key based, basic Auth, OAuth or JWT. We pass JWT context down to the respective backends.
Protect your data
StepZen is compliant with the General Data Protection Regulation (EU GDPR) and a data processing agreement (DPA) is standard for enterprise deployments.
Docs and Additional Resources
Management & Governance
Backends change. The GraphQL API evolves. New protection rules are needed. The more declarative your system, the better its performance, code simplicity, and governance.
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 importcommand, 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.