Traffic Ops code re-structure

["Fieck, Brennan" <Br...@comcast.com>]

A couple of days ago I opened a pull request to add an API response to Traffic Ops's `/api/?$` endpoint, for the OPTIONS and GET HTTP methods. The form and function of those changes are still works-in-progress, and comments on them are welcome, but what I'm asking about today is more about the challenges I faced in creating the endpoint given the way the Go code-base for Traffic Ops is structured.

Between Rob Butts and I, we've agreed that there are parts of the 'main' package that ought to be made into their own package: particularly routes.go, routing.go, routing_test.go, wrappers.go, wrappers_test.go should ideally be in their own package(s) - possible all of it would fall under the 'routing' package, or perhaps the wrapper code warrants its own package. This will allow the list of endpoints and their structure to be available to other parts of TO, as well as any client that could potentially want that.

With such a large structural change, I don't feel comfortable writing any code without asking: does that sound good to everyone?


There are a LOT more questions that need answering before that endpoint I made could be included, but I feel this is a good place to start.

Re: Traffic Ops code re-structure

[Dan Kirkwood <da...@gmail.com>]

I've always advocated keeping the main package lean from the start.

+1 on making this change.

-dan

On Wed, Nov 14, 2018 at 10:06 AM Robert Butts <ro...@apache.org> wrote:

> Well, when I originally wrote `traffic_ops_golang`, I just put everything
> in the `main` package, with the assumption that we'd move components as
> they got big enough. It seems self-evident to me that these should be
> packages, very little should go in `main` in any nontrivial Go app. I don't
> really see this as a "large structural change," these are 3 single files.
>
> I don't think we really need to vote and approve every little Go package
> change. But I'm certainly not trying to circumvent the voting process, if
> anyone else does feel like the need to?
>
>
> On Wed, Nov 14, 2018 at 9:36 AM Fieck, Brennan <Br...@comcast.com>
> wrote:
>
> > A couple of days ago I opened a pull request to add an API response to
> > Traffic Ops's `/api/?$` endpoint, for the OPTIONS and GET HTTP methods.
> The
> > form and function of those changes are still works-in-progress, and
> > comments on them are welcome, but what I'm asking about today is more
> about
> > the challenges I faced in creating the endpoint given the way the Go
> > code-base for Traffic Ops is structured.
> >
> > Between Rob Butts and I, we've agreed that there are parts of the 'main'
> > package that ought to be made into their own package: particularly
> > routes.go, routing.go, routing_test.go, wrappers.go, wrappers_test.go
> > should ideally be in their own package(s) - possible all of it would fall
> > under the 'routing' package, or perhaps the wrapper code warrants its own
> > package. This will allow the list of endpoints and their structure to be
> > available to other parts of TO, as well as any client that could
> > potentially want that.
> >
> > With such a large structural change, I don't feel comfortable writing any
> > code without asking: does that sound good to everyone?
> >
> >
> > There are a LOT more questions that need answering before that endpoint I
> > made could be included, but I feel this is a good place to start.
> >
>

Re: Traffic Ops code re-structure

[Robert Butts <ro...@apache.org>]

Well, when I originally wrote `traffic_ops_golang`, I just put everything
in the `main` package, with the assumption that we'd move components as
they got big enough. It seems self-evident to me that these should be
packages, very little should go in `main` in any nontrivial Go app. I don't
really see this as a "large structural change," these are 3 single files.

I don't think we really need to vote and approve every little Go package
change. But I'm certainly not trying to circumvent the voting process, if
anyone else does feel like the need to?


On Wed, Nov 14, 2018 at 9:36 AM Fieck, Brennan <Br...@comcast.com>
wrote:

> A couple of days ago I opened a pull request to add an API response to
> Traffic Ops's `/api/?$` endpoint, for the OPTIONS and GET HTTP methods. The
> form and function of those changes are still works-in-progress, and
> comments on them are welcome, but what I'm asking about today is more about
> the challenges I faced in creating the endpoint given the way the Go
> code-base for Traffic Ops is structured.
>
> Between Rob Butts and I, we've agreed that there are parts of the 'main'
> package that ought to be made into their own package: particularly
> routes.go, routing.go, routing_test.go, wrappers.go, wrappers_test.go
> should ideally be in their own package(s) - possible all of it would fall
> under the 'routing' package, or perhaps the wrapper code warrants its own
> package. This will allow the list of endpoints and their structure to be
> available to other parts of TO, as well as any client that could
> potentially want that.
>
> With such a large structural change, I don't feel comfortable writing any
> code without asking: does that sound good to everyone?
>
>
> There are a LOT more questions that need answering before that endpoint I
> made could be included, but I feel this is a good place to start.
>