Why StepZen

Implementing GraphQL the right way means connecting backend data efficiently and delivering flexible APIs at the speed that frontend teams need the data. It means handling errors, managing access, securing the API and the backends, being highly available, reliable, and scaling as the business does.

The challenge is how to make the right choices for your GraphQL implementation, for now and the future.

With StepZen, you get started quickly by coding the schema with a few lines of declarative code. Your API runs on StepZen - is concise and declarative with built-in performance, cost, and reliability optimizations.

Build, deploy, and run a GraphQL API in just a few lines of code.

type Article {
  id: ID!
  title: String!
  description: String
}
type Query {
  articles(username:String!):[Article]
    @rest(endpoint: "https://dev.to/api/articles?username=$username")
}
successful graphql

Executive Summary

StepZen is built on the principle that a declarative approach to building GraphQL APIs leads to the first implementation with fewer lines of clean code and faster time to deploy. And because StepZen runs your GraphQL as-a-service, your API comes with built-in performance, cost, and reliability optimizations.

When you program declaratively you are not only configuring a system - you are providing the system with universal rules - 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.

Choosing StepZen for your GraphQL implementation is the right choice for now and the future:

  • Core Problem SolvedMaking data available to digital experiences at speed is not as easy as it sounds. While anything can be programmed, programming your way out of integration, scale, availability, performance, security, etc. is not easy. StepZen's declarative approach helps you deliver a concise, declarative API with built-in performance, reliability, and cost optimizations.
  • Build Time SavingsStepZen makes your team productive by helping it build out the data layer by assembling GraphQL snippets. Connect REST, database, JSON, and even GraphQL backends efficiently, and accelerate time to first implementation with a few lines of declarative SDL code.
  • Operational SavingsStepZen is a GraphQL-as-a Service engine. Running on StepZen your API is always on - you get built-in performance, cost, and reliability optimizations. In other words, protocol translation, key management, access control, error handling, caching, and so on are handled and optimized for you.
  • Easy StartYou can create, deploy and run your first API with seamless connections to REST, database, or GraphQL backends with a few lines of code. Your API is flexible, concise, intuitive, and built to scale.
An image depicting a chart showing a comparison of StepZen and open source tools
Build Flexible API Fast

Assemble from Building Blocks

With StepZen you build GraphQL using simple directives and composability that gets your teams up and running, delivering flexible APIs in days, not weeks or months. StepZen is built on the principle that a declarative approach to building GraphQL APIs leads to a faster first implementation and automatically takes care of various tasks and considerations in the API lifecycle without the API developer having to learn new skills or write complex code.

Put another way, you get started faster, and over time and lifecycle of the GraphQL API, you write less code, need fewer skills and get far fewer maintenance headaches with StepZen.

The need to build things quickly and focus on the parts that are high value without reinventing the wheel is ever more pressing. This need for scaffolding is especially vital in a world of API-driven composite services and developers moving up the stack. We need new middleware for this play, and GraphQL is emerging as a key element of it.

Rachel Stephens
RedMonk

In StepZen, the code you write to create an API is the same code that helps deploy, scale, and optimize the API.

In other approaches, the code you write to create an API is just the beginning. You write more code to deploy, scale, optimize and make that API robust. You need more skills, and you must maintain those skills and code through the lifecycle of the API.

Developer TaskSubtaskUsing StepZenUsing Other GraphQL Libraries
Create Your APIConnect to any backend data sourceConfigure schema & write a few lines of code.Write schema and resolver code
SchemaAutomatic, or Configuration & few lines of code.More difficult. New code, if-then-else logic, libraries, and skills required.
Mocking
PerformanceCaching
N+ 1 Optimization
Pushdowns
Connection pooling (e.g. database)
Handle ChangesAdd and change Backends
Perform Compile-time Checks
Deal gracefully with request spikes
Federation/Support for team structures
Protect using Keys and JWT
Deploy at Scale
No mysterious black boxes

Declarative Schemas and Resolvers

We might call the StepZen approach Schema-first, Directives-driven - you first define the schema (SDL), coding it with directives that help you deliver a concise and intuitive GraphQL API, and because the API runs on StepZen, performance, cost, and reliability optimizations are built in.

For example, Figure 1 shows the code to generate a GraphQL endpoint against dev.to. A line of a declarative snippet tells the system to call the right API, pass the right parameters, and parse the response back. There are no libraries to import, and you write safer code - directives are parsed at API creation time, enabling StepZen to catch errors that would only otherwise show up way down the line.

If you were to write resolver code to achieve the same thing, you would end up with many more lines of code and logic, which might look like Figure 2.

Figure 1: Declarative code to generate dev.to endpoint

type Article {
  id: ID!
  title: String!
  description: String
}
type Query {
  articles(username:String!):[Article]
  @rest(endpoint: "https://dev.to/api/articles?username=$username")
}

Figure 2: Resolver (pseudo) code to generate dev.to endpoint

sdl.js:

type Article {
  id: ID!
  title: String!
  description: String
}
type Query {
  articles(username:String!):[Article]
}

resolver.js:

resolvers: {
  articles(parent, args) => {
    fetch (url: “https://dev.to/api/articles”, query: [args])
    // Code to parse, extract and return the resolved data
    // Code to deal with errors
    // Code to deal with caches
    // Code to deal with 1 + N optimization
    // Code to deal with mocking
    // Code to deal with pagination
    // Code to deal with pushdowns
    // Code to deal with monitoring, tracing
    // Code to log things
    // Code to access and manage JWT, or other backend API Keys
    Resp.id = …
    …
    }
  }
}

You might argue that a lot of this code can be written into shared libraries, and only invoked in the resolver. And therefore, on the surface, this resolver approach looks similar to the StepZen model. There is a huge difference. The resolver code is a black box. There is no way for the GraphQL engine to understand what is going on in the resolver–it can only execute it. There are no deployment checks to be done, and importantly, no runtime security, performance, and scale to happen automatically.

Put another way, the opaqueness of the resolver model prevents the runtime from doing anything intelligent.

Fewer lines of code required

Getting Started Quickly

As you saw above, it is simple to create a running endpoint in StepZen: create your SDL, add a few lines of declarative code, and instantly deploy it on StepZen. StepZen's directives-driven approach eliminates lines of code by letting you configure protocols, mapping, authentication, deployment scripts, performance optimizations, and more.

There are no resolvers to write and maintain, no data connections to code, and no GraphQL servers to build and manage. The code you write to create the API is approximately the code you need to write to run, manage and maintain that API.

Connect data sources

A core problem that API developers have is that they have backends :-) And not one, not two, but dozens, maybe even hundreds. The fissiparous tendency of data exceeds any unifying force! The challenge becomes one of producing a consistent GraphQL API when the backends can all be different. The challenge is compounded when the data from the various backends must often be mixed and matched.

Various backends connection through an API level, then connecting to GraphQL

Despite a name that makes it sound like a general purpose query language for traversing graphs, GraphQL is primarily about designing your APIs more effectively, and being specific about access to your data sources. In StepZen, you build and connect your data in a configuration-based system and with powerful custom directives:

  • @rest, @dbquery, and @graphql for seamlessly connecting REST, SQL and NoSQL database, even GraphQL API backends
  • @materializer for combining data returned from two types into one. Useful when you're making a call to two separate endpoints, separate backends or assembling multiple GraphQL types from a nested JSON response.
  • @sequence for executing multiple queries in a sequence that returns a single result. This allows for complex sequencing of API and database calls to populate a query without the need to write difficult asynchronous call handling.

Introspect and transform JSON to SDL

StepZen comes with a set of introspection capabilities. You can, for example, issue stepzen import mysql, answer a few questions, and get a GraphQL endpoint against your MySQL without writing any code.

If you have a REST backend, visit https://json2sdl.com, where you can paste your JSON and receive an instant SDL.

Mock your data

Because a GraphQL API is strongly-typed it lends itself to mocking, which enables StepZen to return simulated data for GraphQL operations based on your schema. If you want to learn the structure of a GraphQL API but aren’t picky about the data yet, if you’re working on a frontend that will query a GraphQL API for data but the full backend implementation is not ready yet, or if you want to use mocks for testing, you can do so using StepZen’s mocking capabilities. You can annotate your schema with directives:

@mock and @mockfn directives mock results type-by-type, so you can create mock queries in your schema. This can be helpful for creating stubs, because you can be sure that the returned value you test will be the same.

Use prebuilt APIs

While you will always have private APIs, developers are increasingly building experiences using some public, SaaS APIs - and often mixing services from public APIas with data from private APIs. We have a growing ecosystem of GraphQL endpoints for popular SaaS APIs in the GraphQL Studio that you can directly import into your project, and write zero lines of code.

StepZen GraphQL Studio

Deploy your API

In StepZen, there is no infrastructure for you to build or run. We run StepZen as a service–all you do is to create your SDL + directives code, and it gets automatically deployed to StepZen, and is always on, with 99.99%+ availability, a generous free tier, and is protected by API keys and JWT access control.

The code you write in StepZen to get a working API is a few lines in the SDL. The same code helps StepZen deploy, scale, and optimize the API for you.

StepZen simplifies those few lines with introspection capabilities and prebuilt APIs, available in the GraphQL Studio. And because we run the API for you, you have no infrastructure to boot up, no keystore to secure your keys, and no API optimization headaches.

Fewer errors, fewer headaches

Compile Time Checking

A Graph is a graph because it has edges. In StepZen, edges are created using the @materializer directive. For example, let us extend the example in Figure 1 by adding some GitHub information to the articles.

type Article {
  id: ID!
  title: String!
  description: String
  github: Github
    @materializer (query: “github”)
}
type Query {
  articles(username:String!):[Article]
    @rest(endpoint: "https://dev.to/api/articles?username=$username")
  github (username: String!): Github
    @rest (endpoint: “https://github.com…”, configuration: “github_config”)
}

Here StepZen knows that the edge that connects GitHub to Article is by executing the query github with the correct parameters. We also know that the query github returns data of the type Github.

Voila! At compile time we know that the edge, when called, will return the right data type.

Contrast this with an Apollo like code:

type Article {
  id: ID!
  title: String!
  description: String
  github: Github
}
type Query {
  articles(username:String!):[Article]

}
resolvers: {
  articles(parent, args) => {
    fetch (url: “https://dev.to/api/articles”, query: [args])
    Resp.id
    …
  }
  Article {
    github (parent) => {
        // Code to deal with extracting args from parent
      fetch (url: “https://github.com/…”, query: [parent.username])
      …
    }
}

At compile time, there’s no way of knowing whether the resolver for Article.github returns the right type! Using open source tooling, compile-time checking is almost impossible. StepZen does it for you automatically.

Built for speed

High Performance

There is no GraphQL without performance. After all, one of the reasons why GraphQL exists is to ensure that the frontend gets only the data it needs, no more and no less, to ensure good performance. But does your GraphQL implementation defeat that principle?

Various small components communicating

Caching

Digital experiences need to be snappy. According to Google, a half a second delay in a web page load causes 20% drop in traffic. When GraphQL is delivering the data for experiences, it needs to be performant above, and stingy in its use of backends below. A key to doing this well is to use caching pervasively.

There are many aspects to caching:

  • memoization of calls within a single query,
  • caching of backend responses across multiple calls and multiple schemas, and
  • caching schema elements so that fragments of responses materialized during the execution of one query can be used to efficiently assemble the response to another.

All this is complicated and hard to do, especially when the runtime system is highly parallel. You need to address time to live for cached entities, eviction, memory management within each node, distribution of cached entries across a cache cluster, respecting cache header directives from backends, and cache policy directives from schema and headers, and handling race conditions and errors, and how the cache has to behave when only some, not all, of the elements of a type are fetched.

In StepZen, caching is automatic. The system knows when the backend call is a REST call and sets up a cache with a default TTL of 1 min. Because StepZen uses multiple servers to handle traffic, these caches are available within the execution of a query, and across queries. You can always override our cache behavior with a directive:

@rest (..., cachepolicy: ON|OFF|DEFAULT|FORCE)

When the backend is a database (called using @dbquery directive), we ensure that the database connections remain open, and we remember which database calls were made before so that they do not have to be re-executed.

Doing caches correctly (without errors and lockouts) and efficiently (without high costs or low hit ratios) is hard.

It is nearly impossible for the system to do some of the caching and pushdown optimizations when you are using other GraphQL libraries. You can do it in more code, using more skills, and increase the maintenance issues, but why do it when StepZen does it automatically for you.

N+1 Database Optimization

Imagine a GraphQL schema with customers and orders, both coming from a database system, and say you want to issue a query:

{
  customers (city = “Miami”) {
    orders {
      createdOn
    }
}

If we know that the three declarative directives are:

type Customer {
  id
  orders: Order
    @materializer (query: “ordersByCustomer”)
}
type Order {
  createdOn: Date
  …
}
type Query {
  customers (city: String!): [Customer]
    @dbquery (type: “mysql”, query: “select * from customers where city=?”)
  ordersByCustomer (id: ID!): [Order]
    @dbquery (type: “mysql”, query: “select * from orders where custId=?”)
}

Then we can issue one query to solve for the classic N+1 problem:

select * from customers, * from orders inner join orders on (orders.custId = customers.id and customers.city = “Miami”)

As a result, with StepZen you are performant above (by issuing one database query as opposed to possibly hundreds), but equally importantly, you are stingy below, conserving your database resources as far as possible.

No blackbox resolver system can do this. And yes, you can do it in code, but you will have to learn SQL intricacies (handle name conflicts, for example), AST parsing (to determine what portions of the incoming query can be lopped off), you will have to JSONify the returned response, and then feed it back to Customer and Order. This is serious stuff.

It is nearly impossible for the system to do this level of database optimization when you are using open-source tooling.

If you have the skills, you can do it with more code, but you will increase maintenance issues. But why write and maintain the code when StepZen does it automatically for you?

Pagination

One standard trick in GraphQL is to paginate the responses. The GraphQL API returns some meta information (in the form of edge cursors, pageinfo and nodes), and the frontend requests additional information only when needed. Awesome, but who actually implements it?

A single consistent approach to pagination is ideal - one where that code need not change even if the underlying backend is changed. However backends support a variety of paging styles including next cursor, page number, row offset, and GraphQL pagination. StepZen maps a backend to the GraphQL pagination specification through three lines of configuration, added as a parameter to @rest. For example, the backend “https://reqres.in/api/users” supports page based pagination, and each call returns total number of pages in a field called “total_pages”:

pagination {
  type: PAGE_NUMBER
  setters: [{field: “total”, path: “total_pages”}]
}

StepZen automatically generates edge, node and pageinfo for you! We support OFFSET and NEXT_CURSOR based backends, too. This allows the front end to issue a query like this, even though the backend has no clue about edges, nodes etc.:

{
  users(first: 10, after: “0x7666534211dftygh..”) {
    edges {
      node {
        email
      }
    }
}

Using standard libraries, you must learn how to convert backend responses to opaque cursors on the way out, and on the next calls, generating the right backend code based on the opaque cursor being passed down. And you have to figure out how to create edge, node and pageinfo data. And do that for every backend you have.

Pagination is an important performance optimization, but hard to do because backends are varied.

Yet GraphQL wants to treat it all in a consistent way of edges, nodes and pageinfo. StepZen does this automatically for you - you specify which form of pagination is supported by the backend, and we do the rest!

Pushdowns

Many subsystems are optimized to collect extra information and send them. For example, in Twitter, one can ask for pinned tweets information in addition to user information. But how do you know how to ask for it? You must parse the incoming query, realize that it is requesting pinned tweets information, and construct a backend call with &expansions=pinned_tweet_id. When the query does not ask for pinned_tweet_id, then this information should not be requested (to get a faster response). How is the right query be generated?

For our GraphQL system, let’s assume that there are three types–Customer, Order, Delivery–and that the last two come from one GraphQL backend (that might have been implemented by your eCommerce team). In case the user requests:

{
  customer(email: “john.doe@example.com”) {
    orders {
      createdOn
      delivery {
        Status
      }
    }
  }
}

then the GraphQL backend should be sent the query:

{
  orders (custId: 1){
    createdOn
    delivery {
        Status
    }
  }
}

whereas if the user query is:

{
  customer(email: “john.doe@example.com”) {
    orders {
      createdOn
    }
  }
}

then the GraphQL backend should be sent the query:

{
  orders (custId: 1){
    createdOn
  }
}

In StepZen such parsing and submission of the right query to the backend is automatic. If you are using standard GraphQL libraries, then you have to understand the parse tree of the query (AST), split the query, ship it down, and merge the responses back. And what if there is a fourth level that comes from a different subsystem? While not impossible to do, it is extremely hard to get it right. In StepZen, it is all automatic.

While not impossible to do, pushdowns can be extremely hard to get right. In StepZen, it is all automatic.

When the backends are flexible in terms of what they can execute, a developer working with open-source tools must have skills in abstract syntax tree (AST) parsing and complex split/merge logic.

Measuring Latency and Throughput of Your GraphQL System

Performance is an important issue for any API and especially for those that drive user experiences. It's well understood that user engagement with an application drops quickly with increases in latency. This blog lays out some of the important considerations for a high performing GraphQL system and tips about what to measure and track.

Download the StepZen GraphQL Benchmark tool to track your own system's performance and keep the following tips in mind:

  • Measure it using a workload that is near realistic.
  • Measure it on a production system, and not on something set aside for testing.
  • Measure regularly, and compare the performance you get with what you got previously.
  • Make sure you know the reasons for any significant differences you observe.

Stay nimble. No API is static.

Manage Change

No API is static. You are constantly adding or changing backends, parameters, queries and mutations. As you saw above, in StepZen it is really easy to get started. But how easy is it to change?

Change your backend database

When changing data sources you don't have to change the response the GraphQL API your frontend is consuming. So you can swap out the datasource behind your responses without having to rewrite resolvers.

On the backend, let’s say your current database is MySQL, your code might look like:

@dbquery (type: “mysql”, ..)

In many cases, all you need to do is to change it to:

@dbquery (type: “postgresql”, ..)

And that is it. StepZen handles the drivers, the connection pooling, and all the headaches that come along with.

Add new backends via an interface

You might have a database that keeps track of your high-value customers, and a different database to keep track of your other customers. Or your logistics provider might by UPS and DHL (whereas it might have been only UPS when you were not doing international shipping).

In either of these cases, it is trivially easy to set up an interface, and one or more concrete implementations. StepZen does the right routing and aggregations across multiple backends. You just declare multiple backends servicing the same query on the interface, and evolve your system by adding or subtracting the backends.

Evolve GraphQL Types

Because types and “resolvers” are not tightly coupled, you can evolve types without having to re-write resolver code, and you can take advantage of GraphQL’s @deprecated directive to signify to consumers when types evolve. For example, given the following type:

type User {
  id: ID!
  firstName: String
  lastName: String
  email: String!
}

Consider a situation where we need to migrate to a new backend where the firstName and lastName fields are now supplied by a single field, fullName. We can rewrite our type as follows:

type User {
  id: ID!
  firstName: String @deprecated(reason: “select the `fullName` field instead”)
  lastName: String @deprecated(reason: “select the `fullName` field instead”)
  fullName: String
  email: String
}

With StepZen, we can use this type with both the old backend and the new backend. When used with the old backend, the firstName and lastName fields will be populated, while the fullName field won’t. And vice versa for the new backend. This flexibility makes it possible to migrate backends and evolve types with the flexibility required to manage change at both the API consumer and API producer side.

The best APIs evolve as business needs do - and without repeated rewriting and redeploying, which can be an expense for API consumers.

StepZen makes it easy to create and deploy your API quickly but also ensures you can evolve seamlessly with your business.

Built for teams and how they work

Facilitate Teams with Federation

Federation (if you exclude the appropriation of the term by Apollo to mean something very specific) refers to the fact that independent teams, in larger organizations, might produce subgraphs that represent their domain, and these subgraphs need to be combined into one graph to enable applications that need data from multiple domains. Read on to learn how StepZen can replace your existing API gateways and load balancers. Requests to your (micro)services with a subgraph are optimized by StepZen.

Federated architecture (FA) is a pattern in enterprise architecture that allows interoperability and information sharing between semi-autonomous de-centrally organized lines of business (LOBs), information technology systems and applications

Wikipedia

There are three levels of federation.

  • A name-conflict free, but independent union of the subgraphs. It allows applications to connect to one GraphQL endpoint, but individual requests are routed to one and only backend subgraph. In API terms, the one graph is a proxy.
  • A connected single graph where types are linked to other types, and the same type can be hydrated from multiple backends. This gives an application one view over the entire set of subgraphs, and allows any request to connect with more than one backend (if that is what needed, transparently, of course to the request).
  • A single graph that compensates for the backend implementations, delivers features that backends do not have, and delivers performance and scale that is not determined by the least functional or least performant backend.

In StepZen, setting up federation is easy:

  1. stepzen import graphql creates a proxy for the GraphQL subgraph you want to connect to. You can add prefixes to avoid name conflicts. With that, you have a working federation, albeit a name-conflict free union of the backends.
  2. Now you can connect some dots—you can stitch types together in this proxy layer using @materializer and @sequence directives, whether backends follow Apollo’s pattern of “concerns”, or follow schema stitching principles.

With caching, pushdown optimization, and scale and parallelism built in, you need not add any new API gateways or load balancers and get awesome performance even if your subgraph deployments are not ideal. In StepZen, you have complete flexibility for how you slice and dice your Graph across teams: you can build one graph, you can build one or more subgraphs, and you can even combine multiple subgraphs built using other popular GraphQL libraries into one graph using StepZen.

Basic stitching

There are three main tasks in stitching data from multiple backends.

  • Ensuring that there are no name conflicts.
  • Creating a unified schema that is not just a union of the subgraphs, but is “one graph” where types are stitched across multiple backends.
  • Executing the stitched graph at scale and performance.

Change graph structure as your teams evolve

You can change the structure of your graph by changing only a few lines of code. Imagine you built a graph in StepZen where Customer, Order, Delivery were all in one graph. As your teams grow, you might want to split the order/delivery into its own subgraph by having a team own that. It is trivial to do that in StepZen. Three really quick steps.

  1. Extract Code and Create a Subgraph

    Take the Order, Delivery code from above and create a new endpoint, say at “https://acme.stepzen.net/ecommerce/_graphql” with the following code:

    type Order {
      id: ID
      createdOn: Date
      delivery: Delivery
        @materializer (query: “deliveryByOrder”)
    }
    type Query {
      ordersByCustomer (id: ID!): [Order]
        @rest (endpoint: “https://orders.acme.com/customer/$id”)
      deliveryByOrder (id: ID!): Delivery
        @rest (endpoint: “https://delivery.acme.com/order/$id”)
    }
  2. Create a Proxy for that Subgraph

    stepzen import https://acme.stepzen.net/ecommerce/_graphql

    This will create a partial endpoint that looks like this:

    type Order {
      id: ID
      createdOn: Date
      delivery: Delivery
        @materializer (query: “deliveryByOrder”)
    }
    type Query {
      ordersByCustomer (id: ID!): [Order]
        @graphql (endpoint: “https://acme.stepzen.net/ecommerce/__graphql”)
      deliveryByOrder (id: ID!): Delivery
        @graphql (endpoint: “https://acme.stepzen.net/ecommerce/__graphql”)
    }

    Note the @graphql because unlike @rest and @dbquery backends, this will call an @graphql backend.

  3. Add back the rest of your code

    And now you can add your Customer details like this:

    type Customer {
      id
      orders: Order
        @materializer (query: “ordersByCustomer”)
    }

And that is it. You basically split your code into two parts (step 1 & 3), and you used stepzen import to automatically create a proxy. Really, that’s it! Is your GraphQL library this flexible with splits and combinations?

Optimize the enterprise graph

As your teams build their own subgraphs, if they are not using StepZen, then they are probably working through all the issues highlighted above. Some would have been solved. Some will need to be solved. Some might be where Team A has done the right job, but Team B has yet to get to it. Did they get pagination right? Filtering? Is the implementation robust for scale? As you think about it, all the issues that StepZen handles for a graph would be needed for the enterprise graph. Caching. Pushdowns. Pagination. Filtering. You can do all of that by creating your enterprise graph in StepZen:

stepzen import TeamAendpoint
stepzen import TeamBendpoint

And from there on, it is like building a graph in StepZen. Create edges. Automatically cache. Automatically pushdown. Do pagination with three lines of configuration.

Control access. Prevent abuse.

Protect Your Endpoint

In StepZen, any endpoint by default is protected by an API key. You have to do nothing.

It is straightforward to add JWT- based protection. You can also easily declare your endpoint to be public. For example, this added to your config.yaml makes it public:

ruleset:
- query: “[ALL]”
  rules:
    - predicate: true
      action: allow

And if you want to allow some mix and match–some queries are public, some are not, simple declarations get you that too.

For even more sophisticated protection, StepZen partners with Google Cloud's Apigee API Management solution to deliver the best of API management to StepZen GraphQL endpoints.

Always on. always there.

Deploy and Scale Your Endpoint

StepZen automatically deploys your endpoint. There is nothing for you to do. We also scale it automatically–again, there is nothing for you to do. An advantage of StepZen scaling everything just right is that the backends that your endpoint calls see a stable IP. So you can whitelist that IP and allow traffic from the StepZen SaaS service to go through your firewall.

Getting a GraphQL API right is more than simply creating it. StepZen makes the creation easy, takes care of most of the issues around performance, maintenance, deployments, security, etc. The code you write to create the API is approximately the code you need to write to run, manage and maintain that API. Your API runs with built-in performance, cost, and reliability optimizations:

  • Endpoints are automatically deployed. Scale and parallelism built in.
  • Automatic caching, N+1 database optimization, configurable pagination, automatic pushdowns, and more.
  • Easy to add or change backends, parameters, queries and mutations.
  • Endpoints protected by an API key by default. JWT- based protection easy to add.

If you are using other popular GraphQL tools, then the code you write to create an API is just the beginning. You need more code and more skills to get it to perform, deploy, scale and modify.

successful graphql

Summary

With StepZen you build GraphQL using simple directives and composability. Whether your backends are REST, databases, GraphQL, your team can be up and running, delivering flexible APIs in days, not weeks or months. StepZen is built on the principle that a declarative approach to building GraphQL APIs leads to a faster first implementation and automatically takes care of various tasks and considerations in the API lifecycle without the API developer having to learn new skills or write andn maintain complex code.

You get started faster, and over time and lifecycle of the GraphQL API, you write less code, need fewer skills and get far fewer maintenance headaches with StepZen. The code you write to create an API is the same code that helps deploy, scale, and optimize the API. In other approaches, the code you write to create an API is only the beginning. You must write and maintain more code to deploy, scale, optimize and make that API robust.

Choosing StepZen for your GraphQL implementation is the right choice for now and the future.

Which path will you take?

This site uses cookies: By using this website, you consent to our use of cookies in accordance with our Website Terms of Use and Cookie Policy.