Can I use grist only as Backend?

I want to build an application for a specific use case for which data is like spreadsheet with custom visibility, so grist will be perfect.

But for very good user experience, frontend has to be custom created for my use case. So I cannot use grist frontend.

How should I tackle this scenario?

  1. Does Grist’s UI works off of its APIs? In other words, are grist apis are fully capable of doing what I see on grist frontend?
  2. Is there a low code frontend that works well with grist (or just off of any APIs)?
1 Like

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.

  1. Make the project public and access it via API from the application.
  2. 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:

  1. I add one user, for example webapp_bot
  2. I generate an API key for it, which I use only for the serverside of this application.
  3. I filter user data at the application level.

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.

Is can be an option

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?

Yes, it is no different from a database.

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.

Something can, this is a system database for user data storage, the first thing I found on this topic

I’m confused, just make the project public, why not?

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.

Good ideas, I will try them out. Thank you.

I was not able to make that work.

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?