Run GraphQL on a Golang-based Query Optimization Engine
Scale and secure APIs and backends. No servers or infrastructure to manage.Sign Up
Core Kubernetes-based Architecture
- Most components in Golang
- Introspection in Scala
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).
StepZen's in-memory, Golang-based query optimization engine delivers auto-parallelism, pushdowns, caching (various levels), N+1 optimizations, memoization, and more.
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
GraphQL simplifies access to data. With that comes challenges. Is your GraphQL endpoint secure? Are backends secure from queries/mutations from your GraphQL APIs?
Secure your GraphQL API
StepZen supports access to queries based on API keys and permissions through JSON Web Token (JWT). All inbound and outbound traffic is protected by TLS 1.2+.
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.
Secure backend data sources
Backends are protected by cryptographically encrypted keys that cannot be accessed by anything except your GraphQL endpoint. When accessing backend databases, we always prepare the statement before execution (this is not an overhead since the preparation is done once and cached).
We run hermetically sealed development, which ensures that ingress and egress from StepZen is limited to specific calls.
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.
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.