Yeah, we could write a framework like that. But this framework is strictly
more powerful than that. Would you want both? Seems simpler to just have
one plugin framework that can do both.
In fact, if you wanted, you could add a generic "microservice plugin" as a
plugin, which looks at the config file for mappings like that, e.g.
`"microservice_plugin":{ ["/api/1.3/myawesomeextensiton", "
http://myushost.com/mypath";] }`, and remaps anything.
On Mon, Oct 1, 2018 at 10:54 AM Jan van Doorn <j...@knutsel.com> wrote:
> Yea, I don’t mean edit the routes.go to add your service and compile it
> in, but make it so that you can have a dynamic list of
>
> Path -> absolute URL
>
> So for example
>
> /api/1.3/myawesomeextensiton http://myushost.com/mypath <
> http://myushost.com/mypath>
>
> Would result in that path calling that absolute URL.
>
> Would that not work?
>
> Cheers,
> JvD
>
> > On Oct 1, 2018, at 09:50, Robert Butts <r...@apache.org> wrote:
> >
> > @jan this is for extensions, for code an organization isn't able to open
> > source.
> >
> > Sure, you could just add a line to `routes.go` if you want. You can do
> that
> > right now. But you'd have to deal with regular merge conflicts.
> >
> > With this dedicated plugin system, the plugins are self-contained, you
> > don't modify any other file to create your plugin. Which means (in
> theory)
> > you should never have merge conflicts when Traffic Control changes.
> >
> >
> > On Mon, Oct 1, 2018 at 10:44 AM Jan van Doorn <j...@knutsel.com> wrote:
> >
> >> Why wouldn’t we just have the routes.go be able to point to an “outside
> >> url” that is the micro service?
> >>
> >> Rgds,
> >> JvD
> >>
> >>
> >>> On Oct 1, 2018, at 09:39, Robert Butts <r...@apache.org> wrote:
> >>>
> >>> So, as we move Traffic Ops from Perl to Go, we need a way to write
> >>> extensions in Go, like we have in Perl.
> >>>
> >>> I wrote a plugin system for Go, modeled after the plugin frameworks in
> >>> Grove and Traffic Monitor, PR is here:
> >>>
> >>> https://github.com/apache/trafficcontrol/pull/2513
> >>>
> >>> It's by no means complete, just like with Grove, we'll have to add
> >>> additional hooks and data as we find the need. But it works, it has
> basic
> >>> hooks, and includes some sample plugins.
> >>>
> >>> There was a question about microservices, if someone wants to write
> >>> extensions to their Traffic Ops as separate services, instead of built
> >> into
> >>> the same app. This framework allows that, it's easy to make a plugin
> that
> >>> calls out to another service when an endpoint is requested.
> >>>
> >>> Does anyone object to this PR? Could I get some +1's/-1's so we can
> get a
> >>> feel for whether people are OK with this PR being merged, and using
> this
> >>> plugin system for Traffic Ops going forward?
> >>>
> >>> Thanks,
> >>
> >>
>
>
