Could you please asist our developer with the integration of Kotahi data to our decopupled frontend?
what elements does he need?
currently our URL is: Kotahi - open journals
It’s being hosted by cloud68
If accesing with the /graphql parameter he get’s a missing permissions response
(don’t know how to @ mention him)
@proal The authentication process requires creating a JWT. You can see how we’ve done it here. Then, depending on the privileges of the logged-in user, you can access the various graphql queries, mutations and subscriptions. Search the repo for modelName: to find all the available graphql queries, mutations etc.
Note, though, that most of these queries and mutations are still considered by us to be “internal”, rather than an external API that needs to remain largely consistent. Thus, we may change them arbitrarily without considering it to be a breaking change.
Kotahi is still undergoing rapid and substantial development, with large changes planned for the structure of forms, manuscripts, reviews and other objects. There will be corresponding changes to the graphql.
I also note that Kotahi’s dynamic forms are quite complex, and it would require substantial work to re-implement UIs for these. If there is a desire to make these forms available externally, it might make sense to try to split these into a separate library (this is not currently on our roadmap).
thank’s for the reply @benwh Is in your roadmap planned to add CSS, HTML and JS manipulation for the CMS?
Could you please clarify which queries won’t change?
We picked up Kotahi because of its decoupled architecture.
@proal it will change, but those changes can be calculated before you upgrade. So you can deploy, implement your decoupled front end, and then talk to Ryan and Ben before each release to anticipate if there are changes that effect you and what those changes are (if any). You can then factor that into your plans before you upgrade to the latest version.