Hi all, I made a proof of concept to show that my approach makes sense https://github.com/Bit-Quill/tinkerpop/tree/valentyn/server-rework-poc. Next I plan to make a modular server with support for WS and HTTP using existing handlers.
If there are no objections in the next 72 hours, I'll assume a lazy consensus and proceed with this direction. Regards, Valentyn On Mon, Sep 11, 2023 at 11:16 AM Valentyn Kahamlyk < valent...@bitquilltech.com> wrote: > Hi all, > > I would like to start a discussion about possible server improvements in the > next major version. > > Biggest problems to solve: > 1. no easy way to extend the server and add new endpoint. For example it > would be nice to add a server status endpoint, but it's not that easy to do. > 2. improve the possibility to extend server by providers. This includes the > ability to add new endpoints, protocols and handlers, to expand monitoring > and logging capabilities, import / export, etc. > 3. get rid of the need to change the pipe for some requests. It makes the > code redundant and difficult to understand, especially for new developers. > 4. code duplication in channelizers and handlers. Now we have to support the > same code in different places. > 5. low code separation, no boundaries between different subsystems. I think > this will improve the ability to test various components. > > Proposed solution: > Use microkernel architecture > > Key requirements: > 1. Same handlers can be used for both TP3 and TP4 > 2. All existing handlers may be reused with small/no changes > > Server should have: > 1. only the necessary infrastructure for adding services > 2. single channelizer > 3. one custom handler, which will choose how to process the request and call > appropriate service > 4. infrastructure to allow communication between services > 5. management for lifecycle of services (init/shutdown...) > > Each service: > 1. can be added and configured by changing config file (yaml), similar to how > we manage serializers now > 2. can decide to handle any request by request type/routes/protocols > 3. can be built as an existing handler wrapper > 4. can share data or code with other services > > Each request: > 1. can be handled by 1 or more service. Service can indicate if request > processing is finished. > 2. can be handled with a server fallback code (just 404) > > p.s. > Auth is just one more service > > Regards, > Valentyn > >
