With in-depth analysis, we found that there are still many improvements needed to do in the existing web api implementation: some operations are simple query processing that does not require too much detailed information; some need to merge several apis into one api, which requires further further focus on functions.
0.8.0 version will continue to improve the ease of use of the web api Thanks Goson zhang <[email protected]> 于2020年12月1日周二 下午12:48写道： > Users who use TubeMQ for the first time will give feedback: it’s a bit > strange, why there are only a few CLI and very few HTTP interfaces?Why > should the metrics be output to a file? Why not like kafka, Broker can be > mounted to the system directly when it is started, and http direct access > can obtain a large amount of indicator information, why is it not in TubeMQ? > > I think there are two reasons, one is the TubeMQ's design idea and the > other is the system stripping problem. > > TubeMQ's design idea: TubeMQ is constructed in accordance with the SAAS > model, the designer considers that the cluster must be managed and the data > must be prevented from being translated to the counterfeited node; at the > same time, the magnitude of data processing is too large, frequent HTTP API > calls can directly affect system stability. > > System stripping problem: we use third-party systems to avoid occupying > the resources of the Broker. such as CPU rate and disk capacity,we use > auxiliary systems for query data processing; the data metrics is output to > the file, and then through third-party statistics and then sent out for > processing, because the magnitude is beyond the ability of ordinary systems. > > But ease of use is indeed a problem, so in any case, it is necessary to > provide as many ease of use tools as possible. So, in the near future, we > will improve this area, including how to produce and consume, and Broker, > Master expose more indicator data. > > Wait, let's look at this effect after a period. >
