We believe attaching containers and functions to API gateway is a difficult way to build an API, and this alone does not address concerns about data storage or modeling. By contrast, ChiselStrike is designed around creating a smoother developer experience - not trying to build what we can out of existing cloud components just because it's possible, but rather delivering on the API and developer workflow we all want to use.

Heroku is a platform as a service solution with support for a variety of languages, that is very much it's own unique way of developing working. Comparatively, ChiselStrike is TypeScript-specific and is driven from simple git-based workflows, with a minimum of commands and extra technology to understand. We're a backend platform that frontend developers will absolutely love and pushing to the server requires no extra steps.

A good question that requires a nuanced answer! We are mostly fans of REST over GraphQL but may have some GraphQL support in the future.

GraphQL is a way of exposing a data model all the way to an HTTP endpoint that is an alternative to REST, but tends to expose too much raw data and internals, sans logic, directly to a client.

Why did we focus on REST? Well, we think REST is better. The effort of developing a well-conceived "best practices" REST API is often a reason many people will adopt GraphQL, whereas our framework helps you do REST in a very straightforward way. We don't force you to be RESTful, but we make REST super easy.

Ultimately, we believe GraphQL is often not the best choice for a client-facing API, but is more of a query language somewhat similar to SQL, that all too often gets plumbed all the way into user-land. Since our database is abstracted away by our data model, users of ChiselStrike never have to write SQL - so the need for something like GraphQL is eliminated. Additionally, our REST API "CRUD" builder supports query-string ordering and filtering for all endpoints, so many of the "search like" features of GraphQL are also not needed. And you'll get all of that built-in with ChiselStrike.

We think GraphQL is often good for prototypes but often breaks down as applications grow. As products mature, they will we often find that they need more business logic into the "request/response" call-chain. This requires custom logic that is so easy to do in ChiselStrike, whereas GraphQL does not allow for expressing business logic.

In short, we see GraphQL as being an alternative to SQL, and exposing GraphQL to the client as mostly unnecessary. REST APIs are, we feel, usually easier and more friendly to consume by a frontend (or a developer!). Architecturally, the separation of behavior between the client and the backend logic should be maintained and exposing a raw data model to the client is not a sustainable answer. REST provides this easy separation and the ability to put custom logic between the request and response.

A lot of the logic we have doesn't even require any extra code to install. Our built-in policy language, for instance, can filter out personally identifiable information (PII) based on user roles. Alternatively, you could build an endpoint that behaves differently based on the state of the system or user credentials. All of this requires a more flexible system than the raw GraphQL data layer.

TLDR: We like REST better, if you want to make it things easy, and we definitely do.

Node JS is a runtime for running Javascript outside the browser. Our platform is powered by Deno, in part, under the hood - we are fans!

Node is definitely one big piece of the puzzle in building a backend solution on Javascript or TypeScript, but only one piece. With a hand-rolled Node solution you will need to write and maintain much more code (API layers, authentication, access control, ORM glue, etc) than if developing on ChiselStrike. Additionally, you'll likely have to deal with scaling and security ("DevOps!") and have to manage the data layer, including developing and running database migrations. ChiselStrike's all-in-one solution is complete and cohesive and requires one tool to learn and use, not 10.

Our philosophy is to make backend development feel effortless so you can spend more time on the frontend and business logic that is unique to your applications.