Why StepZen

GraphQL is emerging as the new standard for APIs, layering upon the investments in REST APIs and data systems. While GraphQL APIs are significantly easier for the application teams to consume, they can represent a challenge to the API teams tasked with building them. We believe that APIs built declaratively are simply better - leading to first implementation with fewer lines of clean code, faster time to deploy, and APIs with built-in performance, cost, and reliability optimizations.

When you program declaratively you are configuring a system - you are also providing the system with universal rules that can be applied across all queries, and in different situations. The resulting code is more fault-tolerant, reduces repetition of software patterns (follows DRY principles), and is easier to understand and maintain. Importantly, it allows the platform to do things for you that you would otherwise have to code yourself.

Our world-class team has worked on APIs and databases with companies from startups to the Fortune 100 and in all industries. We bring this background and unique point of view to the world of GraphQL and build our product with an eye to helping teams get up and running, delivering a flexible GraphQL layer in days, not weeks or months.

• Data: Your Most Precious ResourceThe backends that deliver data to GraphQL are diverse, and the data is your most precious resource. StepZen provides a way to modernize your stack, accelerate application development and still leverage years of investment in REST API and database technologies.
• Fast Time to Value - Declaratively!StepZen provides a unique declarative approach to building GraphQL. Your GraphQL API or federated API is composed from declarative building blocks - resulting in smaller and more intuitive code, better runtime performance, and faster time to value.
• Query Optimization EngineBecause the API is built declaratively, and by leveraging the backgrounds of the StepZen team, we have built an in-memory Golang-based query optimization engine that is much more than just a router.
• SecurityYou have a single endpoint that may expose more than a REST endpoint, especially if you federate multiple services in a GraphQL API. So granting access to the endpoint may generate more risk than granting access to a single REST endpoint. StepZen gives you the ability to control access to the GraphQL schema that lies beyond the endpoint - to protect your data, your APIs, and your data sources.
• Managing ChangeGraphQL APIs evolves. You are constantly adding or changing backends, parameters, queries and mutations. The combination of a declarative approach and a framework in which everything is just text files, APIs built in StepZen fit easily and naturally into your CI/CD pipeline.
• Federation & Graphs of GraphsIn large enterprises, federated GraphQL APIs (graphs of graphs) are often the right structure for enabling API strategy across teams and domains. StepZen's declarative directives enable GraphQL federation in the same way as you build a single GraphQL API. Furthermore, you have choice. You can also quickly enable subgraphs for Apollo Federation.
• GraphQL-as-a-ServiceStepZen’s architecture is designed to be high throughput, low-latency. You can consume GraphQL-as-a-Service on StepZen cloud, and for our enterprise customers, we can deliver StepZen in private clouds.

We believe that the backends that hold your data are some of the most precious resources you have, and that you should not need to modify them to support new application needs for which you are building GraphQL APIs. Therefore we have invested in the ability to take almost any form of data — REST, SOAP, SQL, NoSQL, GraphQL — and make it compatible with GraphQL. Furthermore, we have built a mini-database engine for the GraphQL API tier that is performant above (low latency and high throughput for applications calling the API), and stingy below (not imposing additional burden on your backends as far as possible).

We also believe in choice: Graphs built in StepZen are compatible with other approaches you might have. And, while we are proud of our public GraphQL-as-a-Service, we also support deployments into your private clouds and data centers.

StepZen is built on the principle that a declarative approach to building GraphQL APIs leads to fewer lines of code to write, and faster time to success. This approach comes from the founders’ experience with databases where a few lines of the developer code like create table customer (name char(20), age int) leverage millions of lines of database management system’s code, and hard things like layouts, checkpointing, transactions, query optimization etc. are handled.

Think of StepZen as doing to the world of GraphQL what databases did to the world of data.

In StepZen, a GraphQL API is composed using declarative building blocks. Each building block connects to a source of data and outputs a graph. There are three building blocks:

• @rest connects a REST, SOAP, or OData backend, and even a NoSQL database
• @dbquery connects a SQL backend
• @graphql connects a GraphQL backend, enabling both connections to systems like Shopify that expose a GraphQL interface, as well as to build a graph of graphs in larger organizations

The composition of these building blocks leverages a fourth directive: @materializer.

StepZen also has powerful introspection techniques so the task of creating these building blocks can be reduced to one line code like stepzen import curl or stepzen import postgresql. Run this command and StepZen introspects the backend and generates the building block code for you.

Given this approach, an API can be created in a few lines of code. And just like the world of databases, these few lines of code then leverage over 500,000 lines of codes written by StepZen engineers to do query optimization, data protection, deployment, scale-out, and so on. The hard things that we do are the hard things that you do not have to do, leading to a faster time to success for your GraphQL initiatives.

Having built many database systems (Db2, Derby, and research that went into Postgres while one of the co-founders was doing his PhD at Berkeley), we know that a significant benefit of declarative approach is optimizing the execution of the queries. However, GraphQL queries are not exactly like database queries–for one, they are hierarchical in nature, and two, the source of data is whatever the backends are, as opposed to tables and views managed by the database system.

That is why we built an in-memory Golang-based GraphQL query optimization engine that delivers:

• Automatic parallelism
• Pushdowns
• Caching at various levels (controllable by you)
• N+1 optimizations
• Memoization
• . . . and much more.

With standard GraphQL libraries, you have to do all of these yourself. With StepZen, they get done for you without you having to write a single line of code. And there are some other competing technologies that claim that converting a GraphQL query into a database (i.e. postgres) execution is the best way to process GraphQL. It is not!

Unlike REST endpoints, which have bounded scope, GraphQL queries can have (in principle) unbounded scope. GraphQL makes data access easy – it makes data liquid. However, with that comes a challenge: ensuring that data is not exposed when it should not be.

So “Can GraphQL APIs be secure?” StepZen’s view in this unequivocally “Yes!”

We take protecting your data, your APIs, and your data sources seriously. 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.

• 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 either 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, we always prepare the statement before execution (this is not an overhead since the preparation is done once and cached).
• When accessing an http backend, we support whatever protection mechanism the backend uses–be it key based, basic auth, Oauth or JWT. We pass JWT context down to the respective backends so that they can have further checks and balances.

The GraphQL API evolves. You are constantly adding or changing backends, parameters, queries and mutations. or new protection rules need to be added. How do you manage all of that? The answer lies in your CI/CD process.

Imagine that your API was just code, written in your favorite GraphQL library, with resolvers as functions that are opaque to any analysis. How would you know what the change impact would be? It would be nearly impossible.

That is why a declarative approach works much better. You have a type Customer that is returned by an @rest call. Now you know exactly what might be affected if the backend changes. Even a simple grep would do a pretty good job. StepZen takes it further. Because stepzen import is such a core part of how the API gets set up, StepZen supports all changes made from the import step to be in a separate extend file, with deltas clearly specified from the import. Now when you re-import for any reason, all the previous work is not lost, in fact, it can be reapplied! .

Furthermore, at StepZen we are not big fans of GUI-driven development. GUI setup sounds great; however it really messes up the CI/CD process. That is why, in StepZen, all building blocks and their compositions are just text files. And deployments of these text files is through the CLI. Configuring the CLI to be part of your CI/CD process is trivial.

In many organizations, APIs are built around organizations or domains. For example, a B2C retail business might have customer APIs, eCommerce APIs, marketing APIs, and others. These APIs are typically built by semi-independent teams, and usually have some common lightweight structures (like authentication, documentation, etc.), but otherwise are constructed independently. And they might appear in the same portal for the API consumer, but there is nothing that connects them.

Because GraphQL APIs are designed to “stitch” data together, GraphQL represents an opportunity to connect APIs easily - even those built by independent teams.A GraphQL API can answer a query like this: listing all the products a customer has bought and the date they bought them:

{
    customer (email: "john.doe@example.com") {
                            name
                            purchased {
                                        orderedOn
                                        name
                            }
                    }
}

The above snippet stitches customer and order data into one response.The API to support this GraphQL query might be built by one team, or it might be an assembly of the work of many teams.For the GraphQL API consumer, it does not matter - they get an endpoint that has the data stitched together.This stitching, at its core, is a merge of JSON objects(with both customer data and order data, coming from the respective backends being JSON objects themselves), resulting in a new JSON object.The end result is a JSON object that has the shape of the query.

With this core capability of GraphQL, a simple federation architecture can be built. It is a tree of graphs, with each subgraph (or a set of subgraphs) managed by different teams.

There are two approaches for stitching graphs together — one based on queries, the other based on objects. StepZen supports the query - based stitching model in a simple declarative way because it delivers advantages from code, performance, and governance perspectives.

You compose graphs in StepZen using @graphql and @materializer. This is relatively trivial to do and maintains the independence of the underlying graphs. For this, it does not matter whether the graphs being composed together are built in StepZen or not. For more, see Declarative GraphQL Federation.

Note: We believe that, especially in larger organizations, having a choice of implementations and flexibility is important, so StepZen supports two declarative mechanisms for building this graph-of-graphs.

You can compose graphs in StepZen as described above and also in Apollo. Apollo supports a different form of declarative composition (it uses object-based stitching). Graphs built in StepZen (or proxied in StepZen using @graphql) are ready for Apollo Federation (you have to specify the @key annotation, and we take care of the rest, including creating _service, _entities, even @link, @required etc.) For more, see Enable Subgraphs in StepZen for Apollo Federation.

It has been said that success is 1% inspiration and 99% perspiration. In this world, getting to the aha of your API up and running is inspiring, but then the hard work of keeping it running, scaling, error-free just starts. StepZen founders have a ton of experience running services at scale (at Apigee, and later at Google’s Kubernetes Engine). That is why we have set out to build a GraphQL-as-a-Service. You create your API simply (see above), and give it to us, and forget about it. We take care of giving your uses the best experience around your APIs..

Now, GraphQL-as-a-Service does not mean public cloud only. While we are proud of our public cloud that delivers > 99.99% availability, extreme scale (>5000 TPS) without you having to do anything, and with full NAT support for access to private endpoints, we also know that public clouds are not for everyone. That is why, StepZen’s GraphQL-as-a-Service is available in your private VPCs and in your private clouds.

Having built databases and APIs before, the StepZen team is uniquely positioned to bring a wealth of best practices in API database optimization techniques to the world of GraphQL APIs.

• The backends that deliver data to GraphQL are diverse, and that data is your most precious resources. StepZen makes it easy to GraphQL-ize the data from any backend - run a simple stepzen import command and StepZen introspects the backend and creates your schema. Or write it yourself with a few lines of declarative code, and @rest, @dbquery, and @graphql directives.
• StepZen's declarative approach to building GraphQL APIs (including federated GraphQL) results in smaller and more intuitive code, better runtime performance, and faster time to value.
• Because the API is built declaratively, and because of the backgrounds of StepZen employees, we have built-out a special query optimization engine that is more than just a router.
• StepZen has simple declarative constructs to secure your GraphQL API.
• With the declarative approach, and a framework in which everything is text files, APIs built in StepZen fit easily and naturally into CI/CD pipelines.
• In large enterprises, a graph of graphs is the right structure for GraphQL and also the entire API strategy. StepZen enables GraphQL Federation using declarations in StepZen, and even supports building and enabling subgraphs that plug in to alternative technologies like Apollo Federation.
• Finally, StepZen’s architecture is designed to be high throughput, low-latency. You can consume GraphQL as-a-service on StepZen cloud, or, for our enterprise clients, we can deliver StepZen in your private cloud.