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

Question on scaling #19

Open
jbehrens94 opened this issue Apr 16, 2024 · 3 comments
Open

Question on scaling #19

jbehrens94 opened this issue Apr 16, 2024 · 3 comments

Comments

@jbehrens94
Copy link

jbehrens94 commented Apr 16, 2024

Hi all, thanks for answering my question a while back on Fluent, @0xTim and @MahdiBM.

I have a broader question about the usage of the OpenAPI Vapor package. If I were to build a bigger OpenAPI document over time, the implementation of the Handler would grow quite fast. What would your suggestion be on managing this scaling up?

@MahdiBM
Copy link
Collaborator

MahdiBM commented Apr 17, 2024

I think this question be best asked on the swift-openapi-generator repository since the maintainers there would know the answer to your question better.

As far as I'm aware, you can break down your openapi document to multiple different documents.

If you want to break down your code into smaller pieces, you can also create multiple SwiftPM targets each with their own openapi document (it's generally a good idea to create more targets for both debug-build performance and clean-code reasons)

@jbehrens94
Copy link
Author

Interesting, @MahdiBM. Would you suggest then to create multiple instances of a Client like this?

// Create an instance of your handler type that conforms the generated protocol
// defininig your service API.
let handlerTypes: [APIProtocol] = [
    PantryHandler() // from Pantry package
    RecipeHandler() // from Recipe package
]

// Call the generated function on your implementation to add its request
// handlers to the app.
try handlerTypes.forEach { try $0.registerHandlers(on: transport) }

@0xTim
Copy link
Member

0xTim commented Apr 19, 2024

I think that makes sense to me

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

No branches or pull requests

3 participants