Replies: 12 comments 1 reply
-
Another quick question please. |
Beta Was this translation helpful? Give feedback.
-
@zjjt in order to support refresh tokens, after login a refresh token cookie should be set (e.g. an UUID). This token should be stored in the User database entity as well. |
Beta Was this translation helpful? Give feedback.
-
@zjjt I guess the best way to get familiar with the architecture is to play around with it. My philosophy is to keep the domain and usecase modules free of any libraries, except for libraries like kotlinx.datetime. |
Beta Was this translation helpful? Give feedback.
-
@ESchouten Thanks a lot for taking the time to reply. I am currently dissecting the project and i have learned a great deal about clean architecture from it (still learning though) and i am still trying to wrap my head around the reflection part for the auto generation of the graphql schemas. Thanks for your detailed answer. I'll make sure to learn well. I am trying to implement kmongo in the adapters/repositories and so far i have trouble with the User data class entity and tests since in one of them the database should be responsible for generating the ID. So far i have tried transforming the User data class into an open class and i have extended it in the adapter to create a data class UserMongo which overrides the id property to support @bson annotation and ObjectId ...It did work but i felt like this was too much of a hassle so i changed the original Entity interface 's id to _id : String. Despite all of this i am still forced to set the ID in code before creating a user in the collection and obviously the test fails since the ID in the database is the same as the one in the User instance...thanks again i am just thrilled to have read your answer. Ill find a way to keep everything clean and not modify my domain. Thanks. |
Beta Was this translation helpful? Give feedback.
-
@zjjt Very relevant question! I have been thinking about that as well the last week's/month. For now I think a concession has to be made. I don't know if it would help, but alternatively you could lift the repository interfaces out of the domain layer into the usecase layer, so you could accept e.g. the CreateUserModel. I think I would prefer the kmongo-id solution. Oh, and for the automatic generation of the Graphql endpoints, please don't get confused by the complexity, that's specially created so we can forget about that part! |
Beta Was this translation helpful? Give feedback.
-
@ESchouten glad to read you again. The library would indeed be a great addition to an already well structured project. I thought about it hard While away from my computer and as you said for now ill have to rely on having a dependency on kmongo-id in my domain layer. Thank you very much for the answers.From them, i am able to grasp bits of precious knowledge . Ill try looking for ways to add descriptions to the types queries and mutations and the a0 a1 |
Beta Was this translation helpful? Give feedback.
-
@zjjt We're looking to have dynamic variable names as well, instead of the a0, a1 + the description. One developer replaced KGraphql with Graphql-Kotlin, and is able to support these named arguments. See the graphql-kotlin branch. You can read a discussion about it in #12 and #23 |
Beta Was this translation helpful? Give feedback.
-
@ESchouten ill take a look into those...being able to swap dependencies at Will without having to refactor everywhere is God sent...thanks ill check how he went about it |
Beta Was this translation helpful? Give feedback.
-
@ESchouten I hope you have a very good day. I would like to understand the two ways of authenticating proposed in the infrastructure module.
In my case i'll have different clients (web, mobile, tv, watch) consuming the graphql content PS: Thanks 🙏 |
Beta Was this translation helpful? Give feedback.
-
@zjjt I love having tech conversations! Please don't hesitate starting a discussion, would perhaps be helpful for other devs as well, or someone could enrich us with their insights! I've created the REST endpoint mainly because KGraphql manages the request in the Graphql endpoint itself, so we can't add the JWT cookie ourselves. For web, you should probably prefer cookies, especially if you want to store the token so you stay logged in in a new browser session/web page reload. Localstorage is not safe for this usecase. If you don't want to save the token, storing it in a JS variable is fine as well. |
Beta Was this translation helpful? Give feedback.
-
@ESchouten Superb. I will start a discussion then and if other devs wish to onboard it will be easy. I understand better now...Indeed for the web i can use the REST endpoint with the cookie to be on the safe side and since this backend support both..i can use even a mix of them both (REST,GRAPHQL) or use one over the other depending on the frontend platform. I thought of something like this for example on web: 1- hit the /login endpoint and get the cookie back either storing it in a JS variable or within http I went ahead and generated the logic for a refresh token in the form of a JWT. I added an expiry time on the initial access token of 15 min (tests) and for the refresh token 7 days. For the web, is it a good idea to also store the refresh token in a cookie as shown on the following shot ? Dont mind the mistakes in the code... :) Thanks for the insights. I really like the way you explain stuff and it makes sense. |
Beta Was this translation helpful? Give feedback.
-
@zjjt I'd say, the Refresh token is fine. This one you indeed want to store in a cookie. The access token is most safely stored in a JS variable. This way malicious packages can't access it in e.g. localstorage, and CSRF attacks can't happen because the token is not stored in a cookie. So put the access token in the response body. Added bonus is that this way, you can decode the token with a NPM package like jwt-decode, and read from it when the token expires. So you don't have to 'try' to do a request to an authenticated route in order to find out if your token is valid. P.S. Soon, besides the Graphql API, all endpoints will be approachable from REST as well, including OpenAPI documentation from which the client can generate code like with Graphql. See #18 |
Beta Was this translation helpful? Give feedback.
-
Hi,
I was browsing the kgraphql.io documentation and i was redirected to your repository. I am in the process of building a saas app using ktor and graphql. Browsing the web for tips and help i came across this old tutorial https://michaelstromer.nyc/books/kotlin-multiplatform-mobile/ktor-and-kgraphql which i followed and made it somehow work with ktor 2 since kgraphql doesnt for now.
I was looking for a better way to handle authentication (with access and refresh tokens) and stumbled upon your repo. If you have a course or tutorial about it please forward it to me so i can improve my current architecture which is mostly organized as shown in the link above. If no videos are available then ill try my best to understand and update where it makes sense.
Thank you for the great repo
Beta Was this translation helpful? Give feedback.
All reactions