TODO

Bindables with multiple services

  When one service (service A) extends models from another (service
  B), it is fair to say that service A routes might require
  PathBindables for the models in service B. The logical approach is
  to include the Bindables from both services (routesImport +=
  "serviceA.v0.Bindables._", routesImport +=
  "serviceB.v0.Bindables._"). An issue arises around conflicting
  implicits (namely implicit PathBindables for DateTime and
  LocalDate). From my observations the compiler cannot decide which
  should be in context, and excludes both yielding no implicit
  PathBindable for those types.

  A solution could be for the service that extends another service to
  include the respective binders for those models. Following from the
  example above, service A's generated Bindables would then include
  the Bindables from service B (but not the shared binders). Then the
  developer would only add the routesImport for service A.

When syncing generators - do not assume the generators list will
paginate. If the second fetch is same as first - just stop rather than
inserting duplicate records.

API changes - generate history of field reordering

[warn] /web/apidoc/api/app/db/generators/ServicesDao.scala:118: method apply in trait WithResult is deprecated: Use [[fold]], [[foldWhile]] or [[withResult]] instead, which manages resources and memory
[warn]       SQL(sql).on(bind: _*)().toList.map { fromRow(_) }.toSeq

Consider supporting (from swagger):
  - parameter locations: header, cookie
  - add headers to response object

Think about:
  - replace base_url with urls which would be an array of [ url, description ]
  - add authentication object support from swagger spec

UX:
  - On adding watch, check subscription and offer the user to enable
    the relevant subscriptions if not subscribed
  - On service visibility - if service is public and org is NOT, add
    note that the service will not be visible until the org is made
    public.

Consider adding an organization level setting to enable semver
versioning (default on)
  - This would then add validation messages that all incoming version
    numbers were in fact semver

Implement backwards compatibility layer - when a user creates a new
version of a service, if the new version has backwards incompatible
changes AND the major version number was not incremented, prompt the
user to confirm the change. Considerations:
  - should this be an org level setting?
  - should this only apply with semver versions?
  - If using semver, we should probably ignore -xxx versions (e.g. -dev)

Automate end to tests of generated clients. Currently client libraries
are tested offline and manually. Need to think through how testing
will work across mulitple platforms.