online

I chose React as the framework of the frontend. Despite I have been developing using React, this is the first React project of mine that starts from scratch. MUI seems pretty handy.

So it went online now.

There are still a lot of bugs to fix and features to add, but I'll take a breath before carrying on. Atm, finding costomers with requirement prevails my service to provide.

structured data in database

Consider the following data structure to implement in a database:

class ComponentBase:
	name: str
	...
	def serialize(self):
		assert False

class ComponentA(ComponentBase):
	def serialize(self):
		...

class ComponentB(ComponentBase):
	def serialize(self):
		...

...

class ComponentList(ComponentBase):
	children: list[ComponentWrapper | ComponentList | ComponentSet | ComponentA | ComponentB ...]
	def serialize(self):
		...

class ComponentSet(ComponentBase):
	children: set[ComponentWrapper | ComponentList | ComponentSet | ComponentA | ComponentB ...]
	def serialize(self):
		...

class ComponentWrapper(ComponentBase):
	target: ComponentList | ComponentSet | ComponentA | ComponentB
	def serialize(self):
		...

The purpose of a database implementation is to query like 'which componentWrapper recursively includes a given componentA?', 'get all the related componentB of a gievn componentWrapper', and such.

And the trouble arises not only because there is a list to maintain (performance concern), but also, there are unions of types (how? all in one table?), and loops in definition (safety concern, unknown depth problem).

The current approach uses json field to store the data above, which solves all the problem at the expense of additional backend workload (it basically reads everything into memory) which I intend to avoid.

Well it all depends on actual requirements. Reading the database recursively is actually acceptable compared to loading the entire table into memory. Saving list as a json value is acceptable when the lists only have length of like 10.

Best solution would be the recursive approach with cache field to avoid deep loop when querying. However, this would make configuration harder as pure json appoach is much more human readable than nested sql table entries. Moreover, it means the updating certain value of database will now have to go through the backend to ensure the cache is valid. Even then, the cache updating is more complicated than normal one-way cache. It has to be in both direction, allowing it to propagate through any cache that it relys on, and that relys on it. Consider all of these troubles the price of performance. Such huge modification would mean some fundamental change of the program... Maybe when I have time.

If I do it, this would be the 4th major version of this program, by major I mean none of these versions is back compatible. The cause of such iteration is that the need of requirement and need of performance is quite divided, and I am kinda stuck in between. It's difficult to vision all the requirement in advance, and optimization usually limits future functions.