yanghua commented on issue #32: URL: https://github.com/apache/incubator-kyuubi/issues/32#issuecomment-897410607
Hi @iodone Thank you for sharing and analyzing the pros and cons of different solutions, and for your in-depth thinking. @pan3793 has already given answers to some points(We can continue to discuss this). I give some personal views on these two designs from a macro perspective. On the whole, I personally prefer the **solution 1** you proposed. The existing [design documents](https://github.com/apache/incubator-kyuubi/discussions/917) are also based on this architecture. Because it reuses and complies with Kyuubi's overall design and abstraction. Regarding the REST service, I think Kyuubi Server did not just act as a proxy forwarding layer similar to Solution 2 before Spark Engine. It should shield end users from direct dependence on the engine layer(relying on the interfaces exposed by the unique features of a single-engine is also regarded as a direct dependency in a sense.), and at the same time prepare to support multiple engines for the bottom layer in terms of architecture design. And if we implement it based on Solution 2, although it has a proxy layer hosted in the Kyuubi server, it seems that it is strongly related to the engine in terms of interface, if we want to provide sufficient flexibility (correct me, if I am wrong). So, if we support another at the Engine layer, this approach seems to be a chimney rather than decoupling layer by layer. Of course, abstraction means more basic and more universal capabilities. This is obviously contrary to the rich and diverse flexibility of a single engine. It seems that this is something that must be given up? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
