Official web-based GUI client for evitaDB e-commerce database. It is built to help developers who use evitaDB with exploring and debugging their domain structure and data. Besides standard query executing, it also supports multiple no-code tools to quickly navigate through domain structure, docs and data without needing to write any queries.
Within #94, base ground for this support was set in form of internal evitaLab data layout and the Value wrapper. Currently, we will have a single driver built on top of gRPC-web of the latest evitaDB and we need to think about how will support future versions.
Two possible version come to mind:
create separate implementation of driver with converter for each evitaDB version that breaks an API
this will create lot of duplicate code, where possible driver bugs will be duplicated
over time, the browser will probably need to download lot of data from server (idk if tree shaking will help here if we will need the driver dynamically at runtime)
create single driver implementation where the logic of supporting multiple APIs will be directly in the driver and converters (possibly using ifs and switches)
will not bloat in size as much as the first option
there will be much less duplicated code
it will be harder to maintain multiple versions using ifs and switches without breaking support of older drivers
There is also problem with the actual generated gRPC code, which would be kind of duplicated as well and would bloat the code base as well.
I personally don't like any of these solutions.
Second part will be to display useful information to users of evitaLab about supported features for a current evitaDB server #152.
Maybe we should get rid of the Value wrapper around properties and define default for unsupported properties directly in the converter in driver. The UI layer would be still handled as mentioned in #152 .
Within #94, base ground for this support was set in form of internal evitaLab data layout and the Value wrapper. Currently, we will have a single driver built on top of gRPC-web of the latest evitaDB and we need to think about how will support future versions. Two possible version come to mind:
There is also problem with the actual generated gRPC code, which would be kind of duplicated as well and would bloat the code base as well.
I personally don't like any of these solutions.
Second part will be to display useful information to users of evitaLab about supported features for a current evitaDB server #152.