Do not understand how kratos work

[sentend]

Hello, I'm having trouble understanding how correctly I need to configure kratos for my project (express + react). Do I understand correctly that I only need docker and SDK for the correct configuration (I need ory/client or ory/kratos-client ?) and I want to make requests to kratos on the backend via express?

do i need to create config for kratos like kratos.yml or identity.schema.json ?

[vinckr]

Hello @sentend

Running software like Ory Kratos yourself is not easy! You dont need docker or the SDK even, you can also install Ory bare metal and call the API directly without the SDK.
I would recommend to check out the Quickstart; that gives you a simple enough setup using Docker.

If you just want to use Ory without getting a deeper understanding how it works, I would recommend Ory Network. It will safe you a lot of work to get a self-hosted deploy running.

[sentend]

Hi @vinckr, yes I saw this quickstart, but actually I still have questions :D

I want to make my own ui, but use Ory Kratos for authentication

I'm running ory kratos in docker (im basically using quickstart.yml without ui image), I have kratos.yml + identity.schema.json, but I don't really understand how I can call the api?
For example, I have endpoint /registration in my express, and route /registration, then how can I get the flowId in route so that when I click submit I have user registration ?

[thomastthai]

Hi @sentend! The docs for the Ory suite of apps are comprehensive but could be enhanced to be easier to follow and the separation of the self-hosted apps and cloud services can be more distinct.

How is your progress?

[vinckr]

Hey @thomastthai
If you have ideas or feedback on how to improve the docs, feel free to create a discussion/issue or pull request in https://github.com/ory/docs.
every contribution helps 🙏

[thomastthai]

@vinckr, I am currently exploring and assessing the Ory suite. So far, the way the suite is built using building blocks of services looks very promising especially how lightweight the parts are.

The docs are dense from a technical perspective, which is often the case with devs writing docs. Writing docs from the potential consumer perspectives can be challenging.

Where the docs can use some improvement is making it easier for a wider audience to easily comprehend how the parts work together. The connection between self-hosted Ory services and your cloud services could be more distinct. From my experience, I found myself reading the docs and it's focused on your cloud services and often asking, "But how does that apply to self-host?"

I am taking notes as I read through the issues, discussions, and the few web tutorials out there. From those notes, I will follow-up with questions and share my documents from a less technical and consumer perspectives.

[vinckr]

Thanks for the feedback.
I agree that there is a lot of room for improvement on the documentation.

As for seperation of self-hosted / Ory Network docs, there we have the struggle between duplicating a lot of the documentation (since most of it applies to both self-hosted and Ory Network) or causing confusion what applies to what if we dont duplicate. Anyway your feedback helps and I also have some ideas how to improve this going forward.

Feel free to also use our GPT bot that is trained on the documentation; take it with a grain of salt but generally it has really good answers. You find the widget in the bottom right of the screen when you visit the docs.

[thomastthai]

... there we have the struggle between duplicating a lot of the documentation (since most of it applies to both self-hosted and Ory Network) or causing confusion what applies to what if we dont duplicate.

One of my exceptionally wise secretaries used to say, "Clarity is a gift and you're are giving me mud," when I asked her for something that needed more details or lacked context.

What she would advise in this situation is to clearly state that the information applies to both, the Ory Network, or self-host. For example:

Browser apps use the https://{project.slug}.projects.oryapis.com/self-service/{flow-type}/browser endpoint to initialize flows such as sign in, registration, profile changes, and so on.

That endpoint looks like it's for your Ory Network/cloud services; where as, the endpoint for self-host may instead be:

https://something.different.com/self-service/{flow-type}/browser

Such distinction, when stated clearly, helps minimize confusion and unnecessary questions.

[thomastthai]

Tutorials like, Ory & Supabase Url Shortener Part 1: Backend, are excellent examples of how to implement different services with the Ory ecosystem. Turning the various examples in the example directory into tutorials, like the URL Shortener, would remove more friction from onboarding, growing the Ory user base, converting some customers to your Ory Network, and generate more revenue.

For instance, the flutter-ory-network is a fantastic example to write a tutorial on how to implement BLOC, user sign on and registration in Flutter. That tutorial would reach a wide audience and organically exposes more potential customers to Ory.