search

micaww / rage-rpc

A universal, asynchronous RPC implementation for RAGE Multiplayer
33 stars 20 forks source link

Library or RAGE Resource? #1

Closed micaww closed 5 years ago

micaww commented 5 years ago

I've been thinking about whether rage-rpc should be a JavaScript library (like it is currently) or a RAGE resource since I started working on it. I would love to open this discussion up to get some of your thoughts or alternate suggestions regarding the most convenient way to use this tool.

Library

With it being a library, it makes the code a little bit more clear to the coder by forcing them to import it into any context that needs to use it. I think this is good practice and it allows most IDEs or text editors to use auto-complete/IntelliSense features to help the developer. However, importing the same file into every context can be annoying.

The NPM module is only useful on the client/browser-side if you're using some kind of bundler like Webpack. I would think bigger projects are already using a bundler, but I know that most aren't. Of course you could just take out the dist/rage-rpc.min.js to avoid using a bundler.

I also like how the library is universal, as in the same file is used in browser/client/server.

Resource

Being a resource would mean a super simple drag & drop installation into the packages and client_packages folder. It would expose an rpc property on the global mp variable on all browser, client-side, and server-side contexts.

It would eliminate the need to manually include it in every browser instance by automatically injecting the necessary browser-side code on the client every time a browser is initialized. This does make it hard for IDEs to use auto-complete features because you'd be using a global variable that the editor thinks is undefined. We could probably get around this by having an external TypeScript definition users could use. The mp object is already global the IDE probably complains about all of that stuff enough unless you already have TypeScript definitions for it. This might not be an issue.

It would also eliminate the need for an NPM module, and as an effect, a client-side bundler as well.

It may even be possible to add C# support this way by exposing some JS events and having a C# api that just calls those events on the JS.

Jengas commented 5 years ago

Maybe you should make it on both, ragemp resource and js lib?

micaww commented 5 years ago

@Jengas that's an interesting idea. It would definitely be possible to rewrite it separating client/server then have 2 different build setups to have a RAGE resource and UMD library.

That would give developers the option to choose, however I do think that might unnecessarily over-complicate things. In non-RAGE environments such as the web browser or Node, npm modules are favored but I'm not sure that's the case with RAGE.

Out of curiosity, are you using the single file version or the NPM module on your resources?

Jengas commented 5 years ago

@micaww I use as NPM module, because it's easier to install and update

micaww commented 5 years ago

Awesome! That's a really good point. Ease of updating is important especially for something like this that might update often for performance/security. I didn't think about that part.

I'm also not really sure how many people are actually using this thing so it might not be worth rewriting as a RAGE resource if current users are happy with the library setup. I have a few updates I want to put out before even worrying about this topic though, so I'll leave the discussion open until it's time for a major version.

micaww commented 5 years ago

rage-rpc will be staying as a library now that compatibility bugs have been ironed out. Maybe we can revisit this in the future.