How do you address the continuity risk when building critical systems with NoCodeBase?

English Forum Questions
1

We are using NoCoBase to build our ISMS/GRC tooling, and the feedback from accountants and auditors has been very positive. No wonder NoCoBase is a great tool and, in our experience, much more powerful and useful than many other NoCode platforms.

However, there is one potential weakness that could become a serious concern for organisations using NoCoBase for critical business systems: continuity .

Although NoCoBase is very intuitive, designing and maintaining a system with a NoCode platform is still often seen as a form of programming. This can create a continuity risk.

For example, I have designed most of our application myself using NoCoBase. But what happens if I leave the company or move to another job? Who will be able to take over the system and continue developing and maintaining it?

There is also a second question related to the continuity of NoCoBase itself. NoCoBase is a relatively small company. What happens if, for whatever reason, the company decides to change direction, discontinue the product, or move to another technology? Who would be able to continue the development of an application that is heavily dependent on NoCoBase?

Of course, the fact that NoCoBase is open source and can be self-hosted is a major advantage. This provides much more control and reduces some of the vendor-lock-in risk. However, for a critical ISMS/GRC system, this may not be enough by itself. An organisation also needs confidence that the system can be maintained and developed over the long term.

So I am interested in how other organisations are dealing with this issue.

What continuity scenarios or strategies are possible when using NoCoBase for critical business applications?

For example:

  • How can the knowledge of the application be transferred to another developer or administrator?
  • Are there recommended ways to document a NoCoBase application so that someone else can take over?
  • Is it realistic for an external developer or service provider to take over a NoCoBase implementation?
  • Does the open-source nature of NoCoBase provide sufficient protection against the company itself discontinuing the product?
  • Are there any recommended approaches for reducing the long-term dependency on a single person or on NoCoBase itself?

I would be very interested to hear how other users — especially organisations using NoCoBase for business-critical systems — look at this continuity risk and what measures they have taken to address it.

2

I am actually trying to address this issue myself by documenting the design decisions in our NocoBase application using Claude, connected to our NocoBase instance through the CLI.

Claude (or another AI agent) can read the entire application, including the database model, collections, relations, workflows, etc., and can generate documentation from it. This has the advantage that the documentation can be kept up to date and makes it much easier to transfer knowledge about the application to someone else.

However, there is one limitation: NocoBase currently does not seem to contain enough metadata to allow an AI agent to generate really meaningful documentation.

For example, it would be very useful if collections, fields, relations, workflows, etc. could contain additional metadata describing their purpose, the business logic behind them, how they are intended to be used, and perhaps why certain design decisions were made.

This would allow an AI agent, using the CLI, to extract not only the technical structure of the application but also the functional meaning and design decisions behind it .

That could make knowledge transfer much easier and significantly reduce the continuity risk when the original developer or designer is no longer available.

Would it be possible to add some kind of documentation/metadata fields to NocoBase, for example at the collection, field, relation and workflow level?

I think this could be a very powerful feature, especially when combined with AI agents that can automatically generate and maintain technical and functional documentation.

3

Another aspect of continuity is data portability .

In the worst-case scenario, if NocoBase would no longer be available in the future, I think the data itself should be relatively easy to recover. The underlying database structure is quite clear, and the data is stored in a standard database.

The main challenge would probably not be getting the data out, but understanding the relationships and the meaning of the different collections and fields, and then mapping them to another system.

This is another reason why I think good metadata could be very valuable. If the purpose of a collection, field, relation or workflow could be described as part of the NocoBase configuration, an AI agent could potentially extract not only the data, but also a meaningful description of the application’s data model.

In that situation, migrating to another platform would mainly become a mapping exercise rather than trying to reverse-engineer the original application.

So perhaps another useful continuity feature would be a way to export the complete application in a well-documented, platform-independent format (e.g: the ISO 11179 format) — including the data model, relationships and metadata.

That would give users a kind of “escape route” if they ever needed to move away from NocoBase.

Has anyone else thought about continuity from this perspective?

4

Well I think the data metadata is already achieved with the collections and fields table. You can add description for each collection and for each field

5

@bsvveen, kudos to you for thinking about the long-term future needs of your company. Don’t expect your company leadership to have the same mindset when it comes to you or your colleagues, however! Meta’s Embrace of A.I. Is Making Its Employees Miserable - The New York Times

Make yourself indispensable and at the very least, don’t make it easier for them to replace you! When you take that next job, they can hire you as a consultant to help with the transition.

6

This is a very interesting topic!
It would be interesting to share what approach other people have for the whole lifecycle support of Nocobase in production. Not only continuity and knowledge transfer, but also general availability and redundancy of solutions built internally on Nocobase. Particularly:

  1. Backup/restore of the interface elements and data.
    We currently do VM snapshots for the whole server, and separately PostgreSQL backups. But it is still not easy to restore a single page or section without rolling back the whole instance. Do you guys have a smarter approach here maybe?

  2. Safe updating to newer Nocobase versions.
    This is a larger problem. Unfortunately, new releases of Nocobase not only fix old bugs but often introduce new bugs in unpredictable parts of the system. So the questions is how to test the release to ensure it’s safe to update.
    We currently have a test instance which is cloned from the production using a custom script which copies storage data, installs the same version of Nocobase in Docker container, and applies the database dump. It also changes some data to point the test version to the test data sources, change the site name and authentication settings, and disables some workflows which would intervene with production if run on the test instance. As result it’s easy to get a separate accessible test instance of the current production Nocobase server, and then upgrade it first to the latest release. But it is still a challenge to perform all necessary testing to ensure that the release is stable and nothing is corrupted.

  3. Monitoring
    While it is easy to monitor the server, Docker container, PostgreSQL, and Nocobase availability using some popular solutions like Zabbix, monitoring of some parts of Nocobase operation requires custom approach - for example, failures of workflows. As I understand, Nocobase has no any built-in possibility to report a failed workflow rather that showing it as failed in the log, so the only solution to monitor them which comes to my head is to monitor logs directly in PostgreSQL.

7

Thank you for your suggestion. I tried the desrciption field but it is not designed to contain enough information to support this goal.

8

Hi @bsvveen!

Knowledge transfer and obsolescence are eternal challenges for any company. In my experience, the solution to knowledge transfer is to have at least one other team member available that can learn by doing, so that they can take over in case of absence.

A practical solution would be for NocoBase to have an “API-first” architecture. Meaning all changes are made through APIs which could then be version controlled, rolled back and replayed, etc. There are lots of tools such as Postman that can be used to manage suites of API calls and these could also be decorated with information about design decisions.
More on this topic here:

As regards outsourcing, the question is if you consider NocoBase part of your core business or not. If your NocoBase application is mission critical or generating revenue, then the answer is no. If it is just a support tool with infrequent change requests, then it could be a candidate for outsourcing.

Cheers,
Kevin

9

well if the field isn’t big enough, I think you can do a workaround by manually create a new database field with larger char type or json if you are comfortable with sql that is🥲

10

I don’t have solution for 1 and 2, but for number 3, you can use my plugin @bunnarin/plugin-hooks where you can write server-side plugin code in the storage/hooks directory without needing to publish a plugin and can be version controlled. in there, you can setup db listern like this.db.on(‘workflows:update’) and then if it’s failed, call an api or alert someone…