rob05c commented on a change in pull request #2513: Add TO Go plugin system
URL: https://github.com/apache/trafficcontrol/pull/2513#discussion_r201757739
 
 

 ##########
 File path: traffic_ops/traffic_ops_golang/plugin/hello_world.go
 ##########
 @@ -0,0 +1,34 @@
+package plugin
+
+/*
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+*/
+
+import (
+       "strings"
+)
+
+func init() {
+       AddPlugin(10000, Funcs{onRequest: hello})
+}
+
+const HelloPath = "/_hello"
+
+func hello(d OnRequestData) IsRequestHandled {
+       if !strings.HasPrefix(d.R.URL.Path, HelloPath) {
 
 Review comment:
   >I also don't understand how this plugin (compiled in) approach would be 
more powerful than a traditional MS approach?
   
   Because it's capable of both.
   
   ```
   func init() { AddPlugin(10000, Funcs{onRequest: helloMicroService}) }
   const HelloServicePath = "/api/1.2/cdns/routing"
   const MicroserviceURI = "https://example.net";
   func helloMicroService(d OnRequestData) IsRequestHandled {
        if !strings.HasPrefix(d.R.URL.Path, HelloServicePath) {
                return RequestUnhandled
        }
        resp, _ := http.Get(MicroserviceURI)
        w.WriteHeader(resp.StatusCode)
        io.Copy(w, resp.Body)
        return RequestHandled
   }
   ```
   
   So you see, this plugin system can be used for microservices. And since it 
can also be used for direct code, it's more powerful than a microservice-only 
extension system.
   
   >now we have to build a more sophisticated build system
   
   Our build system already creates an RPM from an internal merge with our 
extensions. We won't need to change it at all. And as @jhg03a said, it'll have 
a unique internal git hash we can use to identify which plugins were put in.
   
   >how could I look at the rpm and determine it had "my custom plugins" in it 
easily?
   
   That's a really good idea, actually: we should make the traffic_ops 
`build.sh` add the list of plugins to the Yum Info in the RPM. I can add that, 
either to this PR, or a following one.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to