Hi, we have some feedback after using the API for a while:
Positive:
the responsiveness/answer times are great
the documentation of the bare REST-API is very good
Constructives:
The Clients (JS / Python / PHP) are well made but not well documented. Also they lack some features.
The small Rate-Limits are a bummer and rendering the API senseless for a lot of use cases.
Not beeing able to access the uploaded files, have having to download them before, even though you get URLs over the API is strange and not the best product & developer experience.
The Long Text column doesn’t return formatted values and even clears line breaks (I started an own thread for this).
An official Typescript client or type generator would be great.
I agree with the small rate-limits being an issue. It would be great the have a higher limit offer so seatable is usable for simple internal mobile applications etc.
This is what is currently great about nocodb, but their interface and level of ux is not near seatable level.
@christophdb Will you consider to increase the limit of SQL calls? I think it will be okay to raise from 5000/day to 20000/day.
SeaTable cloud service is not designed for hosting files for direct access via your own applications. Because this will cause traffic overload and it is also hard to charge based on the traffic.
The question is: do you want to support the follwing use case.
Since the API of ST is so good, resilient and fast, it’s an easy choice to use it as a backend for apps and websites. In fact, this is what we do. (https://merf-mrr.vercel.app/ (WIP)).
But the rate-limit is sooooo low, that it’s not thinkable at all to use ST for this. The 100 requests per minute are easily reached when you have a highly nested database.
Thats why the question
doesn’t really play a role. No matter if 5K, 20K or 100K. When your audience grows, when your data and your database grows, you’ll run into the rate limits sooner or later.
Which terminates ST as a SaaS-Backend (unlike nocodb, directus etc.).
IMHO this is a pity, because it would fit perfectly into this niche.
What could be considered is an extra plan for this. Maybe better payed. I think we would pay a lot for this.
PS:
What we do is heavily caching. We copy all the data from seatable into redis once it’s needed and supply the website users from the cache instead of ST directly. This was the only way to avoid the rate limits.
You use case is interesting. I think it can be satisfied by using a standalone SeaTable instance, either self-hosted one or managed one.
Think it like you are using a database. The SeaTable cloud is a shared database that many customer will use together. Most of them is using it for table editing and collaboration. It has a low resource usage for the server side. If everyone call API 100K/day, especially someone has large tables, the server will certainly crash.
In your case, you are using it as a real database, like MySQL or other database for your application. To remove the resource limit for the shared cloud service, you should use a standalone SeaTable, just like people use a standalone MySQL for their application instead of a shared one.
In a standalone instance, you are only limited by the CPU and memory. Of course, cache is still needed to improve the performance. Just as people use cache for MySQL.
