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

feat: add service codegen framework #497

Merged
merged 25 commits into from
Mar 1, 2024
Merged

feat: add service codegen framework #497

merged 25 commits into from
Mar 1, 2024

Conversation

lucix-aws
Copy link
Contributor

@lucix-aws lucix-aws commented Feb 6, 2024

Adds the infrastructure for service code generation.

Service codegen exists as a separate plugin which is powered by the newer recommended DirectedCodegen.

This PR adds partial support for the awsJson1.0 protocol. The document type and event stream operations are not yet implemented.

I had to change some internals to work w/ DirectedCodegen that technically would be experienced by the downstream v2 SDK (e.g. refactoring GoWriter to extend SymbolWriter instead of AbstractCodeWriter. I checked and confirmed that the output of v2's codegen is completely unchanged against this.

Special thanks to @syall and @isaiahvita without whom this would not have been possible!

@lucix-aws lucix-aws requested review from a team as code owners February 6, 2024 20:44
@syall syall self-requested a review February 6, 2024 21:20
Copy link
Contributor

@syall syall left a comment

Choose a reason for hiding this comment

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

General comments:

  • Rather than "Service", I think "Server" is a better name. This avoids any naming confusion for Service shapes, and is the recommended way to name Smithy plugins: https://smithy.io/2.0/guides/building-codegen/configuring-the-generator.html#how-to-name-codegen-plugins
  • The Server plugin using DirectedCodegen is awesome. I think unifying the Go Integration interfaces would be better in the long term, especially if we want to write integrations that are applicable to both client / server codegen. Keeping ArtifactType for nullable index check modes makes sense though.
  • nit: For all of the classes with changes in visibility, I am wondering if we should move them to an internal package also, just to be sure no one uses it. Either way, we should be liberal with using the @SmithyInternalApi annotation.

Comment on lines 137 to 142
if (directive.shape().getId().getNamespace().equals(CodegenUtils.getSyntheticTypeNamespace())) {
return;
}
if (isUnit(directive.shape().getId())) {
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason why we are skipping generating the synthetic I/O shapes and unit types? The I/O shapes should be generated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unclear, this was taken from the client version.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Marked as FUTURE to reconcile

@lucix-aws lucix-aws requested a review from syall February 26, 2024 16:14
Comment on lines +52 to +56
@SmithyInternalApi
public enum ArtifactType {
CLIENT,
SERVER;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think ArtifactType is doing anything meaningful right now, it can be removed.

@lucix-aws lucix-aws merged commit 5893827 into main Mar 1, 2024
11 checks passed
@lucix-aws lucix-aws deleted the feat-svcgen branch March 1, 2024 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants