Yes, Grist have API and it works quite well, and will be even better with the addition of Webhooks.
To create a frontend-only web application using Grist as a backend, you have 2 options.
Make the project public and access it via API from the application.
Synchronize data from the Grist server, for example via csv with your web application.
If you can’t use Grist publicly, then you can’t do without the server side of your application. Because you will be forced to use the user’s secret API key, and using it only in the frontend is not entirely reasonable, because anyone can get data for the project on Grist.
I am currently using Wappler for web development. And while all my ideas work for both the client and server parts.
That is very insightful, thank you for your response.
CSV will not be an option as data needs to flow real time.
If I understood correctly, you are saying authentication is the real issue. To use Grist, I will need a key, and keys are user specific, so FE cannot be used by all users without compromising functionality like filter data based on user.
So in this case, can the FE connect to same SSO as backend to generate a key?
In other words, user will authenticate, get a key, then use that key to call backend. In this case, I can still use user based filtering logic in grist and show user specific data in FE.
Yes and No.
Yes, because each user will have to go to Grist and generate their own API key. In this case, you will indeed be able to identify the user on the application side.
But at the same time, in any case, you need to configure access rights, examples are here Intro to access rules - Grist Help Center
I made a decision for myself:
I add one user, for example webapp_bot
I generate an API key for it, which I use only for the serverside of this application.
By the way, for developers, it would be nice to add the ability to create API keys for fake users (only for bot’s on API access, without UI access but possibility configure access rights). This would make it possible to abandon Authentik at least a little.
It uses an external data provider. For self-hosted - Authentik for example.
Everything I said in this thread only applies to Self-hosted Grist instance. I didn’t dig into the Grist code, I’m just experimenting with it and trying to expand the scope of this great product in my life.
This does not mean that it is not possible, perhaps I just did not find a solution for this.
In any case, the use of third-party authentication limits the ease of integration, this is my personal opinion.
I meant somehow grist’s own UI is able to distinguish between multiple users without each one having to generate their own key.
So I am wondering if I can simply use the same mechanism to build my application.
Maybe all I need to do is take the UI and build custom view on top. That way I do not need to re-invent most of the UI.
I checked that the system database contains information about users and their credentials, but if the user himself did not generate an API key, information about key will not be in the database.
And the official documentation says nothing about using the API to request user data.