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

 ##########
 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:
   You are correct that the last version numbers could be different across TC 
if you're supplying custom plugins.  That's a good thing though in my mind.  
Traditionally you always assemble your repository state then build the result.  
TC has currently embraced one repo and one application version to rule all 
components; a fairly normal practice among many with its pros and cons. The 
githash is the source of truth for what's included since it's the state the 
repo was at build time.  If someone had been patching perl after deployment, 
it's nolonger that version that was built anyway and nolonger has a single 
commit to reference the code state that was built.  The big bonus for this kind 
of plugin system is that when/if you're knitting repositories together you're 
less likely to have conflicts which results in lower maintenance costs and 
providing a template for writing more modular and therefore testable code.
   
   Comparing a plugin system like this to a microservice architecture in the 
end achieve similar goals.  Microservices give you scalpel-like ability to 
adjust what small functions are doing.  In practice you pay a significant price 
for those gains when having to triage why things aren't working perfectly and 
in maintaining compatibility matrices between all the components.  The latter 
case is mitigated if you upgrade everything everytime, but then you're not 
using the gain you designed for.  A plugin system like this is much simpler to 
diagnose problems with because you're working with single binaries with any 
variances locked at build time.

----------------------------------------------------------------
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