Moya: [Suggestion] Simpler version of Moya?

[jdisho]

Hey guys 👋

I am using Moya in some projects and I love how it abstracts Alamofire and how easy it is to use. ❤️
But, personally, I see a problem with Moya when it comes to projects that does not necessarily need that much networking.

For instance, there are projects that just need a small networking provider to request JSON data from an endpoint and map it to a Decodable object. I would rather write my own provider rather that installing Moya(together with Alamofire and Result) which increases the amount of dependencies for something that supposed to be easy.

My suggestion would be to introduce a lightweight Moya version (i.e Moya-Lite as a separate library) with no other dependencies to support just some basic, common networking tasks.

• A tiny wrapper around NSURLSession
• Supporting CRUD methods (GET, POST, PUT, DELETE).
• Working only with Decodable objects.

Similar to this: https://github.com/jdisho/TinyNetworking
(My intention is not to advertise my networking library, but more as an example to better understand my suggestion.)

Hopefully I was clear otherwise I am open to answer some questions.

Let me know what do you think. 😊

[SD10]

@jdisho Thanks for writing this up 👍

To be honest, I’m not sure what a lighter weight version of Moya would look like. The Moya codebase is already extremely small and well focused. I’m not sure if a thinner layer could even be considered Moya anymore.

It sounds like in this situation someone should just be using Alamofire directly. Making the request you described above with Alamofire is less than 15 lines of code with decoding included.

_{Sent with GitHawk}

[jdisho]

You misunderstood my suggestion @SD10, probably I am not explaining it well 😄

What I am suggesting is to have a Moya-Lite version with no dependencies on Alamofire and Result, with the same project goals and covering basic networking cases like exchanging data with some endpoints using CRUD methods and working only with Codable objects.

I don't have anything against Moya's usability, it is easy, understandable, concise and as you mentioned, well focused. I am concerned about the dependencies it introduces when installing it, Alamofire and Result in some cases.

Before embedding a framework to any project, I make sure that I will use its functionalities as much as possible. For example, I have worked in many projects where only a small networking provider (a wrapper around URLSession with less than 500 lines of code) to request data from some endpoints and decode them, was enough for the whole networking part and using Alamofire just for that is not necessary.
The same thing is also when it comes to Moya.

[SD10]

@jdisho I have similar feelings when it comes to dependencies but Alamofire is a reasonable dependency IMO. It's used in ~600k apps with ~40million downloads according to CocoaPods alone. And if you examine the Alamofire codebase it's not as large of a project as you'd expect it to be.

As for Result, I feel you on this one. However, it's really lightweight too 😆 It just doesn't make sense for Moya to have its own internal Result type, because the official Result dependency offers a small set of more robust features.

So I'm not sure I really see the benefits of building another project that is free of these dependencies.

I'm also thinking this discussion could be possibly related to:
#556: Any possibility for a network abstraction engine
#495: Making Moya more ignorant

I've played around with these ideas but I could never think of any architecture that provides more value here

Let's see if any other Moya contributors can provide any input

[BasThomas]

Especially since we rely heavily on Alamofire, I don't see this making too much sense. I don't know the initial reasons to have Alamofire as a dependency though, and I do not know if it would be worth it dropping the dependency at this point.

[BasThomas]

Are there any strong opinions or instances were you really need Moya over URLSession when dependency size is important?

[jdisho]

I am not saying to get rid of Alamofire and change the core part of Moya.
I am suggesting to create another OSS as a lightweight version of Moya, just as a wrapper around URLSession supporting some common and basic networking tasks. Just requesting data with parameters or with an Encodable object and decoding the response. Similar to this.

Thoughts? @BasThomas

[BasThomas]

I get it, but I still don't see the point of it:

Are there any strong opinions or instances were you really need Moya over URLSession when dependency size is important?

[jdisho]

When it comes to projects were 40-50 endpoint have to be implemented and some of them have different Tasks to do(requesting with parameters, encodable object to body, uploading, downloading), I will use Moya because it is easier to use, offers less coupling. At this case I don’t care about the dependency size. @BasThomas

I see the dependency size as a problem when it comes to projects that does not require much networking. 😕

_{Sent with GitHawk}

[BasThomas]

But in the smaller projects you would probably not need the “overhead” of Moya, and you can use a simple URLSession. Right?

_{Sent with GitHawk}

[jdisho]

Right @BasThomas , the "overhead" of Moya in not necessary in smaller projects, that's why I am suggesting to have a light version of it, with the same interface, as a wrapper around URLSession 😄

[SD10]

I feel like if the project is that small that it doesn't warrant the use of Moya, it doesn't warrant the use of a network abstraction beyond URLSession or Alamofire in general.

Personally, I don't really care about my dependencies in small projects, it's quite the opposite actually. I don't want dependencies in a large project because the effort to replace them is massive. I could change networking layers on an app that only has a handful of requests and not be bothered in the slightest.

[jdisho]

Thanks for your opinions 😊 @BasThomas @SD10

What do other @Moya/contributors think?

[freak4pc]

I understand the intent of the original author but I disagree on it.
I prefer using a heavily-tested dependency such as Alamofire than to diverge Moya into two smaller dependencies. Especially as I don't anticipate it'll bring any performance benefit whatsoever to use URLSession without any dependencies (as Alamofire does that, and does it well)

My 2 cents.

[colinta]

Making a library that has the features of Moya but doesn't rely on Alamofire wouldn't make the library smaller, it would make it bigger, and that much more code for contributors to maintain. If a project is trying to minimize dependencies then something like Moya (which is, at its heart, an interface to a wrapper for URLSession) is just not a good match. Using URLSession directly, or Alamofire directly, would both be better options.

[jdisho]

Thanks for your opinions 😊

[Jeehut]

@jdisho I like this idea and plan to either write a small library (maybe named SimpleMoya?) or a GitHub gist with an article explaining on how to use it based on an implementation similar to this. You can find a usage example here in the same project.

In my opinion, using this SimpleMoya approach can be seen as a first step for people who don't really understand Moya immediately (and I've come across many of them) but still want a somehow structured approach in writing their APIs. The advantage of such a tiny implementation would be to learn the basics of Moya. But such a project or article should also have clear instructions on how to migrate to the "full Moya" experience once convinced of this method of implementing APIs.

Also, most of the time recently, when I wanted to write a client for a simple API within a library (like the Microsoft Translator API example linked above), I wanted to keep dependencies as small as possible. Moya seemed to be too much, but I still wanted to use the same ideas so people who know Moya could grasp the code quickly. That's another reason I think a "simpler" Moya version could be useful.

Since this thread was closed by the OP himself and because the title "lightweight" is misleading, I'm reopening this and changing the title to "simpler".

My purposes of keeping this open are:

• Discuss if the Moya community should use this "simplified" approach for teaching new Moya users the basic ideas of Moya.
• Discuss how library authors could use the Moya approach without actually integrating the entire Moya library with its Alamofire subdependency. (Most library authors try to have no dependencies at all.)
• Discuss how this could be done specifically. Should it be a separate library? A Markdown file within Moya? A wiki article? A gist with a blog post? Should it even be part of Moya at all?

I'd like to hear what you think!

[AndrewSB]

Sorry for the delay, I'm actually sympathetic to @jdisho's issues, I'm currently working on an app where we're incredibly constrained on binary size, so I wouldn't be able to take a dependency like Alamofire, I can't use Moya because of that, so I have a minimal reimplementation I've been using with graphql.

I'd love to see a variant of Moya that takes out Alamofire (more likely, offers a compile time option to use either Alamofire or NSURLSession).

[orta]

Microya!

[Jeehut]

@orta I liked your name suggestion so much that it motivated me to actually refactor the Moya-inspired simple network abstraction layer I linked above and actually bring Microya to life:

https://github.com/Flinesoft/Microya

I hope you're fine with me using the name. 💯 points for that idea! 😆

[larryonoff]

Microya is a great name, but I think that more recognizable name is MicroMoya or MoyaMicro.

[stale[bot]]

This issue has been marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale[bot]]

This issue has been auto-closed because there hasn't been any activity for at least 21 days. However, we really appreciate your contribution, so thank you for that! 🙏 Also, feel free to open a new issue if you still experience this problem 👍.

[orta]

Nice work! - I think we should link to Microya from the README in here?

[sunshinejr]

@orta yeah, there is also the Community Project section.

I guess there could be many projects that try to simplify Moya in its own way. This one is a nice alternative when you can't afford Moya itself but still want some abstraction layer on top of your JSON api. Still, it lacks many features that Moya is known for and this kinda proves the point that we, as a Moya community, shouldn't really make our own micro version of Moya.

[kgnadinger]

As the size of Moya increases, it wouldn't be a bad thing to look at breaking up the repo into logical modules. This would allow people to create an Alamofire-Moya adapter (using current code) or whatever is their session framework of choice.

[ashfurrow]

@kgnadinger one thing to be aware of is that breaking the repo into smaller pieces introduces significant amounts of overhead for the maintainers. Additions to the code, like alternate adapters, could be done in the current repo setup.

I'm not saying we can't (or shouldn't) do this, but it does have costs that need to be weighed.