This post is on a very short look into some API calls I hit with Auth.
Let me come again with my Data Model to show some isolation I’d planned for Auth and Data.
Now, for the Cover Story,
Any 2 HTTP calls are completely berserk, they are independent. It’s the HTTP header/ the cookie that identifies 2 calls with the same user, from IMAD :).
This throws insight into sessions and user management on the Server-side. But thanks for the interns, Hasura all-rounds the session store and the cookie business, even rendering user_info for any logged in user.
Recall from the last story that, client-end of things are just to make HTTP calls and the API gateway does the authentication and upstream forwarding.
It’s surprising that even the Auth Service is a Postgres Schema, with the same query structure and form.
Note: My app is built on parallel lines with the Data Modeling. Following up on the last post, I remind readers, that I’ve captured shots & snips of okHttp logs (Retrofit) I get on the Android Monitor while I emulate these calls on my device.
If you were to make a guess that my request & response POJO objects are ready, then I wouldn’t deny :)
Register an User
An elementary step for any sovereign app :)
Log the User In
It’s really cool on how Hasura manage multi-sessions for an user across devices. I’ve personally noticed this feature.
Maybe, they map the user_id inside a Cookie object to point to a list of user_tokens?
Log the user out
A simply task of deleting the cookie set by the session-store on the server.
Note: This is just a demo of the few features I tried out with Hasura API calls and my auth_tokens & sessions are long gone :)
This is kind of how Hasura manage users in your project’s console.
It’s a cakewalk to make API calls, tasting the broth, but cooked with sheer efforts by the Chef, Hasura.
I’ve briefly written about Postman collections and request grouping in the prequel blog. Find my Postman Collection for Auth APIs here.
Watch out for the next story :)