Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
62 lines (49 sloc) 2.73 KB
Remove play.api.Play.current
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.