Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Api definition guidelines #71

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

gabe-l-hart
Copy link

Description

This PR introduces a framework for managing OpenAPI definitions for InstructLab APIs and Platform APIs.

@gabe-l-hart gabe-l-hart force-pushed the ApiDefinitionGuidelines branch 2 times, most recently from fc7d51d to 27121d7 Compare May 31, 2024 21:42
@russellb russellb self-requested a review May 31, 2024 21:59
@russellb
Copy link
Member

This looks pretty good to me, thanks!

My main request is that we merge #69 first (should be able to next week) and then we treat this as one of the first artifacts coming out of that working group.

The only change I'd suggest then is to move the doc/api-definition-guidelines.md file under docs/backend/, but that requires #69 to be in first.

There is a bit of additional context I'd like to capture, but I'm OK not blocking this PR on it. For example, this is written with an architecture in mind about an InstrutLab API and supporting platform APIs. I'd like to write a high level backend direction doc that would introduce these concepts. I have existing content for this. If feedback on that doc changes anything substantially, we can always adjust these docs too. It's all a moving target.

@russellb russellb added backend InstructLab Backend Services hold labels May 31, 2024
@russellb
Copy link
Member

The hold label is just for waiting on #69.

@gabe-l-hart
Copy link
Author

That sounds good. I have an internal platform ADR about the decision to make REST APIs as the common service layer that we can adapt for the general backend architecture perspective.

@russellb
Copy link
Member

russellb commented Jun 4, 2024

#69 merged, so I'll drop the hold

@russellb russellb removed the hold label Jun 4, 2024
Copy link
Member

@russellb russellb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, though I'd like to get some other reviews on it before we merge it.

One point that may be worth adding is something like:

We make no guarantees about any type of API stability at this time as we are still working on the initial implementations of these APIs. As implementation progresses, we may decide to make significant breaking changes to what you find here.

russellb
russellb previously approved these changes Jun 6, 2024
Copy link
Member

@russellb russellb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with this.

I'm still a bit surprised that nobody else has reviewed it though. Maybe we aren't making it visible in enough of the right places?

README.md Outdated Show resolved Hide resolved
Copy link
Contributor

@leseb leseb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for getting started on the API definition!

docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
Copy link
Member

@hickeyma hickeyma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good, thanks for pushing this @gabe-l-hart. Some small nits inline and questions around where specifications should reside.

README.md Outdated Show resolved Hide resolved
@@ -0,0 +1,23 @@
# API Definitions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "API Specification" a better fit?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above comment about API Definition vs API Specification from Open API docs

api-definitions/README.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
@russellb russellb dismissed their stale review June 7, 2024 18:42

dismissing approval for the moment, as I want to make sure my approval reflects that i see consensus on the PR and there's some ongoing discussion. Thanks for engaging, everyone!

@relyt0925
Copy link

This looks good to me!

Copy link
Contributor

@leseb leseb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your diligence in revisiting all the comments. We're making great progress, and I appreciate your efforts!

README.md Outdated Show resolved Hide resolved

## Where will service API definitions live?

Service API definitions will live a new repository github.com/instructlab/service-api-definitions. This repo will have two primary responsibilities:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Service API definitions will live a new repository github.com/instructlab/service-api-definitions. This repo will have two primary responsibilities:
Service API definitions will live a new repository `instructlab/service-api-definitions`. This repo will have two primary responsibilities:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer specification over definitions

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hickeyma, can you elaborate on that preference in light of the definition vs specification article? My thought is that this new repo would explicitly house definitions (for machine consumption). Are you thinking that it would also house specifications (for human consumption)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to weigh in, the Kubernetes community often uses "spec" to define the API specification. I've seen "model" being used elsewhere. I'm ok with both TBH.

Copy link
Author

@gabe-l-hart gabe-l-hart Jun 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good point. I think you're right that the kubernetes community uses spec in this context a lot. I do think it's also a little muddy with CustomResourceDefinition which is the thing that defines the schema for a "thing" and then spec being the canonical name for the field within that schema where a user would create an instance of that "thing." I that vein, it still feels like Definition is the consistent word where the schema is defined.

That said, I'm a big fan of putting a Cares About number (1-10) on this kind of opinion and then just taking the highest one.

CA: 2

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we went with instructlab/openai. I'm fine with that.

docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Show resolved Hide resolved
Copy link
Member

@hickeyma hickeyma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates @gabe-l-hart. Some more comments provided.

docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved

## Where will service API definitions live?

Service API definitions will live a new repository github.com/instructlab/service-api-definitions. This repo will have two primary responsibilities:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer specification over definitions


## Where will service API definitions live?

Service API definitions will live a new repository github.com/instructlab/service-api-definitions. This repo will have two primary responsibilities:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Service API definitions will live a new repository github.com/instructlab/service-api-definitions. This repo will have two primary responsibilities:
Service API specifications will live a new repository `instructlab/service-api-specification`. This repo will have two primary responsibilities:

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question as above. Why the preference for specification vs definition if the explicit goal of the repo is to own machine-consumable definitions. Are you thinking that the yaml format is the human-readable specification vs the generated language-specific packages are the machine-readable definitions?

docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Show resolved Hide resolved
Copy link
Contributor

@leseb leseb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are getting close, thanks for keeping up Gabe!


## Where will service API definitions live?

Service API definitions will live a new repository github.com/instructlab/service-api-definitions. This repo will have two primary responsibilities:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to weigh in, the Kubernetes community often uses "spec" to define the API specification. I've seen "model" being used elsewhere. I'm ok with both TBH.

docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Show resolved Hide resolved
@booxter
Copy link

booxter commented Jun 12, 2024

Directionally, this looks fine. The initial guidelines are quite abstract and perhaps will be clarified / filled with essence once actual APIs are proposed and actual bindings are generated. The main point is - the guidelines clarified that bindings will be auto-generated and hosted elsewhere; and there will be a separate repo for schema itself. This should be enough to merge it IMO.

Copy link
Contributor

@leseb leseb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with the current content. The "how we sync generated APIs" many not yet be fully formed or may change a little as we begin to deep dive more into the implementation. However, I think we all agreed on:

  • Having a new repo for the source of truth (the API)
  • Generate client/SDK/server code using that API def onto new repository:
    • it could be a pull from a client repo
    • it can be a build/push from the API def repo

Thanks for all your efforts Gabe!

Copy link
Member

@nathan-weinberg nathan-weinberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one nit but otherwise LGTM

docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Show resolved Hide resolved
gabe-l-hart and others added 2 commits June 24, 2024 09:47
Phrasing change for `openai` repo

Co-authored-by: Nathan Weinberg <[email protected]>
Signed-off-by: Gabe Goodhart <[email protected]>
@hickeyma hickeyma self-requested a review July 2, 2024 15:42
Copy link
Member

@hickeyma hickeyma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates @gabe-l-hart. Nearly there, just some small nits.

docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
docs/backend/api-definitions-guidelines.md Outdated Show resolved Hide resolved
gabe-l-hart and others added 2 commits July 2, 2024 11:07
Co-authored-by: Martin Hickey <[email protected]>
Signed-off-by: Gabe Goodhart <[email protected]>
Co-authored-by: Martin Hickey <[email protected]>
Signed-off-by: Gabe Goodhart <[email protected]>
@hickeyma hickeyma self-requested a review July 3, 2024 08:35
Copy link
Member

@hickeyma hickeyma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine as it gives guidelines and direction with API definitions. I think the "how" will be worked out as we generate and sync specific APIs. We are taking the right approach using OpenAPI specifications and adding the specifications to a new repo for source of truth.

Thanks @gabe-l-hart for working on this.

@hickeyma
Copy link
Member

hickeyma commented Jul 3, 2024

@markstur @russellb The guideline looks good to go. Do you have any further comments or obejctions to merging and moving forward?

Copy link
Member

@markstur markstur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend InstructLab Backend Services
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants