Hello @Ravi_Kapoor
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.
Yes this is starting to get messy. If functionality is compromised, I might as well use a regular db. Grist is useful to me because of all the user and attribute functionality built in.
How does Grist’s own frontend work with multiple users? Grist is open source, can I just not use same logic and build my own FE?
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.
Yes, I believe there must be an API or some mechanism Grist’s own UI is using to authenticate users without forcing each user to create a key. I will look into that further.
As for making project public, I can, I just do not have a project yet. I am still trying to figure out if and how it can work.
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.
Hypothetically, you can host the Grist system database on PostgreSQL or mount the path to the Sqlite system database folder in the application and access to Grist system database from the application.
So the only option left is to customize Grist’s own frontend so it looks like my app. @paul-grist can you help understand how would I go about doing that?
For a SQLite backend with proper SDK for Frontend programming you might care to look into https://pocketbase.io/ , it comes with a pretty neat UI builder for the data schema.
Just remember these are tools meeting different needs.
ATM….
Grist is focused on being its own independent app, with user control only to access its own UI, while the API is more of a nicety but not something meant to be open to the internet.
OTOH Pocketbase is focused on being its own independent backend, it has user auth choices for public-facing applications, but it does not have control over user privileges for its admin UI, the UI is only meant for the admins, without RBAC authorization.
Both are very cool and I also wish for a single app that does everything, but we gotta pick different apps for different purposes.
This means that Grist is not meant as an app backend nor as a database. You may automate Grist into a workflow but only slightly as part of a larger system. Grist mostly works as a shared spreadsheet with database semantics. Think of it like a more powerful collaborative google sheets. You might load data into the spreadsheet from external sources to analyze it. You might export data as well. But (ideally) you would not use the spreadsheet as the engine to your public web application.
It is an awesome “internal tool“ to aggregate user-input data. It is not as pretty and structured as commercial CRMs, but it allows you to build your own workflow. Beats spare spreadsheet files that need to be carefully moved around by people. You would not give Grist to a user of your product, but you would give it to a collaborator that wants to understand your workflow. Think of it as “low code“ internal tooling.