Questions about Stitch design decisions

Hello all, I would like to discuss some problems I see in how Stitch works compared to other similar tools.

Here the problems I see currently.

Problem 1. Stitch uses SDK’s but for what? SDK’s are pretty 90’s early 2000, Since the GraphQL release, there is no need since you interact with your database only through the API. I know not all people use GraphQL but why not give instant REST API the same way we have GraphQL?

Problem 2. You need the SDK for authentication since Stitch is a ‘Serverless App’ I think the auth logic should be baked in in Stitch without me having to use an SDK, more modern solutions like Strapi give you GraphQL endpoints for Login/Register/LostPassword, so I can simply make a Login Mutation instead of installing the SDK or make a Registration form which triggers a Register Mutation without any packages.

Problem 3 Because all the SDK does regarding auth is storing the token in localStorage is it very hard to keep track of the current state of the User and if he is really authenticated, I know it is easy to check but not so easy to keep track as for example with endpoints that give me more information.

Any chance we will see improvements here?

Hi Ivan – Great questions, let me tackle them in order –

  1. I don’t particularly agree with the characterization SDKs as out of date, they are simply a different method of interaction between the frontend/backend. The SDKs provide a lot of query power out the box which some folks find very helpful. In addition to GraphQL, we prove incoming webhooks which let you define custom REST endpoints, but are looking at potentially expending this functionality.
  2. You can certainly call our client API endpoints directly if you don’t want to work with the SDKs. We are considering either header-based authentication or GraphQL-native endpoints in the future and are always looking for feedback to help prioritize improvements like this.
  3. Expanding on Q2 – Many folks find authentication provided by the SDKs to be simpler and require less round tripping than an API-based approach.

Overall, we try to cater to a wide variety of developers and different development styles and are always looking at ways of being more flexible.


Yeah I think I was a bit to hard going on SDK’s, they are a great tool for people that interact with the mongo database, however it would be nice to have an option in the future to not use them if you don’t need it a solution would be like described above to have mutations for authentication.