Hi, Zexuan, Thanks for your detailed reply.
On Thu, Mar 25, 2021 at 10:11 AM Zexuan Luo <[email protected]> wrote: > My previous letters are too aggressive. > Never mind. It's OK. 😄 > But I have contributed to https://github.com/leafo/pgmoon, and spend > months of time developing two ORM for OpenResty. > > First of all, the job to develop a layer in front of DB is not simple. > It can't be done just with enthusiasm. This is why I failed to > implement my first ORM. > > Does your company support you to do it at work? Secondly, the ecosystem of OpenResty's DB driver is not good enough. > The pgmoon has trouble maintaining connection, sometimes there will be > a connection leak: https://github.com/leafo/pgmoon/pull/72. And it > doesn't support Prepare statement. Finally, I ended up writing our pg > driver and threw pgmoon away. > Totally agreed. One of my major concerns is the maturity of the db drivers in the OpenResty ecosystem as they are the most fundamental aspects. Otherwise just the drivers development work can definitely drive us crazy. > > Thirdly, there are many design decisions when you develop a DB > wrapper, for example: > 1. How do you sync the configuration of DB to the wrapper? The DB > operators and APISIX operators are usually in different teams. > 2. What's your API for transactions? > 3. What's your model for JOIN? > 4. How do you ensure the statements are safe? > 5. How do you debug generating SQL, especially in the production > environment? > 6. What's the API to distinguish "select for update" and plain select? > 7. How you map the advanced PgSQL feature like window functions and CTE? > I guess the specific design depends on the actual requirements. In our scenarios, users are merely willing to do very basic data manipulations via APIs, no transactions, no JOIN. I guess no one or no application could make the APIs the same functionality as direct SQL. > So far I can only recall those questions which I had to handle during > the ORM development. > Very much appreciated for your valuable feedback. Since I am not familiar with the ecosystem of OpenResty, I had thought we could come to an agreement on how to implement it then I could get this feature done. While for now, I realized that my previous idea is so impracticable. So I would prefer to reconsider this to see if we can have any improvements. Zexuan, thanks again for your help. 😄 Regards, Joey > > Zexuan Luo <[email protected]> 于2021年3月25日周四 上午9:21写道： > > > > I don't think "convenient" is an advantage. > > If APISIX can't outperform PostgREST or other similar projects, people > > still need to use them, instead of the "convenient" but "useless" > > solution. > > > > Zexuan Luo <[email protected]> 于2021年3月25日周四 上午9:15写道： > > > > > > It is interesting. But there are many products in the market that > > > provide the REST wrapper. > > > > > > Why not use the wrapper directly as the upstream of APISIX? > > > > > > What are the advantages? > > > And what are the disadvantages? > > > > > > Joey Ma <[email protected]> 于2021年3月24日周三 下午6:40写道： > > > > > > > > On Wed, Mar 24, 2021 at 5:50 PM Ming Wen <[email protected]> wrote: > > > > > > > > > I also think it very interesting. > > > > > Is it more appropriate to implement this feature on the dashboard? > > > > > > > > > > > > > Hi, > > > > > > > > Thanks for the reply. > > > > > > > > May I ask that you mean we can implement this only on dashboard, > without > > > > hacking APISIX? Sorry for not knowing how to achieve that. :-) > > > > > > > > Previously, I thought we needed to develop new plugins in APISIX and > also > > > > provided related configurations in dashboard. For example, in > dashboard we > > > > define a new route with the URI prefix of RESTful APIs, (e.g. > > > > `/api/users`). Then we enable the database plugin which has some > config > > > > items like `endpoints`, `credentials` and `table name`. Once we > finish the > > > > route creation, APISIX can automatically generates relevant routes > `GET > > > > /api/users`, `GET api/users/$id`, `POST /api/users` and etc. Of > course, we > > > > could also manually define the URIs of the routes via > > > > plugin configurations for fine-grained control. > > > > > > > > Looking forward to your insights. Thanks. > > > > > > > > > > > > > > > > > > Thanks, > > > > > Ming Wen, Apache APISIX PMC Chair > > > > > Twitter: _WenMing > > > > > > > > > > > > > > > Sheng Wu <[email protected]> 于2021年3月24日周三 下午5:17写道： > > > > > > > > > > > This seems very interesting. Are you planning to start from > PostgreSQL as > > > > > > well? > > > > > > > > > > > > Sheng Wu 吴晟 > > > > > > Twitter, wusheng1108 > > > > > > > > > > > > > > > > > > Joey Ma <[email protected]> 于2021年3月24日周三 下午5:03写道： > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I'm writing here to hope to discuss with you guys about a new > feature. > > > > > > It's > > > > > > > about to support exposing databases as web services. > > > > > > > > > > > > > > Please allow me to introduce my case. I'm now constructing a > sort of > > > > > data > > > > > > > middle platform and use APISIX as the API gateway to handle > the NS > > > > > > traffic. > > > > > > > One of the scenarios is to expose data stored in the database > as web > > > > > > > services, mainly list/create/update/delete operations, for > outer > > > > > clients. > > > > > > > As for now, we need to deploy an application for database > access and > > > > > then > > > > > > > set it as the upstream of a route. For example, we use > > > > > > PostgREST/postgrest > > > > > > > [1] to serve RESTful APIs for Postgresql and make APSIX as the > proxy. > > > > > > > > > > > > > > I believe that If APISIX can have this feature built-in, it > will bring > > > > > > much > > > > > > > convenience, so I was wondering if APISIX is able to add > support for > > > > > > > auto-exposing the database as uniform RESTful web services. If > that, > > > > > the > > > > > > > only thing that users need to do is to fulfill the endpoint and > > > > > > > credentials of the database and then we are happy to see the > routes are > > > > > > > generated and ready for access. > > > > > > > > > > > > > > Looking forward to hearing from you. Much appreciated. > > > > > > > > > > > > > > > > > > > > > [1]: https://github.com/PostgREST/postgrest > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > Joey > > > > > > > > > > > > > > > > > > >
