Take a look at Google Maps or Google Search.

You specify what you want, and Google delivers the answer. How? You don't know, and typically don’t care. The hard work is done by Google, and not you, the consumer. Google does not program each and every query that might get asked. Instead, it figures out at the time the query is submitted, the best way of answering it. Of course, it might cache popular queries.

Or take a look at a database query.

select product.id, product.title from products, category
where category.label = “kitchenware” and
product.categoryid = category.id

You specify what you want, and the database produces the right answer. How? You don't know, and typically don’t care. The hard work is done by the database, and not you, someone who wants the data.

This is the declarative world. A world in which the developer, the user, the consumer declares what they want, and the system assembles the right bits to satisfy it. It cannot possibly imagine all pieces of information that might be requested, and in all ways it can be requested. The execution logic has to be assembled when the request is made (query execution plan, caching excluded).

There is a different world--the procedural world. The developer anticipates what forms of requests will be made, and carefully programs her way through all of them. All of server side code (that you fullstack developers write), and all the JavaScript code (that you front-end developers write) uses procedural logic--full of if-then-else logic, error handling etc.

Neither is good nor bad, they are just different. As a developer, procedural code gives you more control. As a user, declarative code gives you more flexibility.

The world of APIs (where StepZen's cofounders spent a decade together), is procedurally built. What that means is that all the ways in which a user-developer of the API might request the data are programmed. You get APIs that do precisely what the API developer wants them to do. If some other way is needed, then either the API has to change, or a new API has to be built.

Let’s take an example. An e-commerce experience that requires the delivery status of all the open orders might be coded by calling an API: /deliveryStatus?email=”jane.doe@example.com”&status=”open”

Furthermore, the API developer would have written some logic like:

Fetch orders from customer system for “jane.doe@example.com”

For each order: Fetch shipments from order system

For each shipment Fetch delivery status from the carrier If undelivered, add to the return answer

Now imagine errors. What if the delivery system does not respond? Now imagine changes. What if the frontend wants only those orders that are shipped by FedEx? Now imagine multiple order systems. Which one should we get the information from? Now imagine a completely different experience: “fetch price of products based on location.” OMG, the whole set of problems repeats themselves.

And the challenge here is not just complexity of the code in these. It is the time taken to code it (which means that the user experiences cannot be changed as quickly as the market demands). It is the brittleness of code. It is the creeping of concerns. It is the replication of business logic in multiple places. And for the frontend developer, it is another set of OpenAPI specs, opening up Postman, reading docs, seeing what parameter goes where. It's pain for the backend developer, pain for the frontend developer.

What if APIs could be built using declarative techniques? Like SQL, if there were one API that abstracts all the backends away and the frontend developer just asks for what she wants? Where the hard work of connecting the dots, of errors, of caching, of optimization, of scatter/gather etc. were all done by API middleware? What if the logic for execution just depends on the introspection of the backends--what they take as input, and what they produce as output?

This is what we are doing at StepZen. Our vision is One API for All Your Data.

Get the data you want. Using APIs built through configuration. And run zero infrastructure.

StepZen as a company is quite young. But Steprz (the StepZen team) are veterans, having built databases, API management systems, and run services in the cloud.

Obviously, our first steps will be just that--first steps. We believe in the power of GraphQL. So initially (perhaps always?) our APIs will be GraphQL APIs. We know backends have complexity. So initially we will give you a set of popular SaaS backends. We know the power of developers. So we will give you a set of connectors and schemas that you can stitch together, modify and add, creating your own "One API for All Your Data." And we will give you all of that, as a service. So that you have to run zero infrastructure.

We are just getting started, and we hope you will join us in our journey.