search

Kong / kong-plugin-openwhisk

A kong plugin to invoke OpenWhisk action (serverless functions as service).
Apache License 2.0
9 stars 10 forks source link

style(*) review by @bungle (basically style mods only) #1

Closed bungle closed 7 years ago

bungle commented 7 years ago

Summary

I quickly went through the codebase, and made some changes (mostly just style) along the way. I didn't find anything alarming. Just small touches here and there. As always with the style things, you may freely disagree with me, but I tried to follow some style rules that I have been able to pickup, mostly thanks to @thibaultcha comments on my PRs.

NOTE: I didn't actually test my changes, sorry about that. I can do it tomorrow if you wish. It would be a good exercise to try this OpenWhisk in action as well. Good work Shashi!

bungle commented 7 years ago

Another comment from me. We have a lot of plugins, and they all seem to be pretty tightly coupled to Kong or its plugin framework. Their reusability outside or even inside the Kong is quite bad.

Let's take this OpenWhisk as an example. Right now it is pretty good as a PoC, but falls short on the loosely-coupling and reusabilityfronts (I just took an opportunity to discuss this a little bit here — the point of @shashiranjan84's work was indeed a PoC). How could this be improved:

  1. abstract as much of generic OpenWhisk into lua-resty-openwhisk as you can (can be an abstraction on top of lua-resty-http) with clean and to the point function signatures (good defaults, auto-discovery, no (black)magic, think about the interface as an user of that (e.g. try to write client code at first – ask questions about how would I like to interface this thing, be aware of leaky abstractions and allow configurability to overcome that), hide the dirty technical details (e.g. headers that we need to set).
  2. make the plugin to use that.

This has a lot of benefits:

shashiranjan84 commented 7 years ago

@bungle I agree, Kong lacks code reusability when its comes to Plugin. It can be attributed to lack of proper SDK. But I also feel abstracting everything is not the way to go always. Ideally SDK should abstract all the reusable code not the plugin. Its a known problem and developing a proper public API's is part of our roadmap.