How to keep SeaTable in production when API / version changes

Developer Talk
,
1

Hi everyone,
As some of you might have seen, the last API changes gave me some modification work on my scripts and (n8n) workflows.

I migrated as much bases as possible on my Self-Hosted enterprise version (which is still v4.3) to avoid the side effects for now, but this is not really a workaround as I will have to update this instance as well, whereas some of my bases are already used in production (meaning, I can’t really shut the processes down), which leads me to this question:

Can any of you help me imagine a solution to deal with this API changes in a production context ?

The first idea that came to me was the one I used previously while developing softwares: having two coexisting branches: a prod(uction) and a dev(elopment) one. However, I can’t really see how to apply this to SeaTable…
I saw this recent post about installing several SeaTable instances on the same server, which seems feasible but not particularly simple, but still, even with two instances eventually running different versions, testing the scripts and workflows (n8n for me) needs a lot of work: exporting every base from the prod (older version) instance and importing them in the dev (newer version) instance, modifying each script with the new server URLs / bases UUIDs, etc.

Considering this option of two SeaTable instances, here are my thoughts about scripts and workflows:

Scripts

  • Most of my scripts are already hosted on github or codeberg, and all the SeaTable parameters (base UUIDs, server URL, API token) are stored locally, so locally updating the scripts in the dev instance and then transmit the modifications in the prod instance when updating it is (or at least should be :joy: ) no big deal.
  • As I have a significant amount of (Python) scripts, so I thought of writing a kind of wrapper for the seatable_api library, always returning the results (rows’ lists most of the time) in the same format. Doing so, modifications will only apply to the wrapper when API changes instead of modifying each script individually.

n8n workflows

For the workflows, I can’t figure out if the best practice would be to duplicate every workflow inside the same n8n instance to cover both dev and prod, or if it’ better to consider running two distinct n8n instances. It’s kind of a nesting doll problem, as n8n itself as to be updated sometimes so the same problem occurs…

Sorry, this post is definitely too long. If you have any ideas to help me make sense of it, I’d love to hear from you !

Bests,
Benjamin

1 Like
2

Dear Ben,

from my point of view, this problem should not be your concern but ours. In general: big changes like with version 5.0 should not happen often and we try our best to avoid them.

But in fact it is not that easy to keep everything consistent because SeaTable has not only one API but multiple implementations of the API.

In fact there is/are:

  • the official API documentation at api.seatable.io
  • the scripting possibilities with python and JavaScript in SeaTable
  • the python pipeline (which utilizes python-sdk)

We are aware of this problem and we started to implement automatic tests, that compare the output of different SeaTable version against each other.

The source code of these tests are defined here: openapi/tests at v5.0 · seatable/openapi · GitHub.

We will try to improve this even further to make sure, that we can clearly tell you what changes you might expect with a new version.