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

Considering how configuration scales for larger projects (?) #951

Closed
bobspryn opened this issue Feb 3, 2017 · 7 comments
Closed

Considering how configuration scales for larger projects (?) #951

bobspryn opened this issue Feb 3, 2017 · 7 comments
Labels

Comments

@bobspryn
Copy link

bobspryn commented Feb 3, 2017

This is point of question or discussion, not a bug. If this isn't the correct spot for it, please close.

I'm interested in Moya, but my initial reaction is that the enum based configuration could quickly get out of hand for larger applications, at which point all the different aspects of a request being handled in very different spots of the file seems potentially awkward.

I have seen https://github.com/devxoul/MoyaSugar which tries to help with this some, but still has the configuration spread out over several different enum methods. Also now we're adding another layer on top of Moya.

Does anyone have experience on using this in larger applications? Is it as awkward as it seems?

@pedrovereza
Copy link
Member

I think Artsy's Eidolon should give you an idea of how it looks like in a real product. Here is where their API is defined using Moya.

@bobspryn
Copy link
Author

bobspryn commented Feb 3, 2017

I should have thought to look there. 🤦‍♂️ Thanks @pedrovereza. I'll close this in a bit if I don't have follow-up thoughts.

@bobspryn
Copy link
Author

bobspryn commented Feb 3, 2017

Interesting. So I guess worst case scenario you make a handful of APIs and redefine the base path, etc, in each. Which really could be a shared function somewhere. Not too bad.

@scottrhoyt
Copy link
Contributor

That's the approach I use as well. In order to keep the boiler plate down in the many TargetTypes that I create, I also introduce some defaults for TargetType as seen in #861.

@bobspryn
Copy link
Author

bobspryn commented Feb 3, 2017

Yeah I like the idea @scottrhoyt. Looks like it didn't make the cut though. I'm considering if I can use protocol extensions for now.

@scottrhoyt
Copy link
Contributor

Yep. Just drop something like this in.

@bobspryn
Copy link
Author

bobspryn commented Feb 4, 2017

Solid. Exactly what I was thinking.

@bobspryn bobspryn closed this as completed Feb 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants