The roadmap about this library consider exactly this point.
Soon I need to integrate another ast parser for typescript to handle e mirror the parameters and the return type to be strongly typed on server and client 💪🏻
I dont want to spoil you the surprise, but here is a catch, with hidden RPC calls/proxies.
You'll soon enough want some kind of shared state between client and server (session authentication, ...). This is often carried by headers of your http requests. But by abstracting away the http calls, you have removed the possibility to your users to tweak those headers. If you dont want your users to be foreced to pass an extra argument to all their methods, you surely could devise some kind of static method get/setState() that allows to carry the information you need accross calls, but this does not play well with async/await, nor with unit testing, and it hides things to your user, tending to bloat your code.
Speaking of hiding, another problem you will face is that the lines between server & client will be a bit more blurred, meaning that it (arguably) leads some less experienced developpers to adopt confusing development habits. Sharing methods is fine, but you've put your finger in a mechanism that will probably will make you want to add support for shared object instances. And that's a rabbit hole you dont want to go down into.
It also leads to problems with API versioning, N+1 problems, and much more.
Being a seducing pattern, RPC is being reinvented every now and then. Like you, and like many of us, I've been there a couple of years ago, and everyone seems to be convinced at one point that it is a silver bullet... Trust me, I've dealt with too many RPC frameworks, and faced too many failures with this pattern (I'm watching at you, Dotnet Remoting) not to emphasis that RPC is neat, but has its drawbacks.
Now, I dont want to sound paternalistic by telling some kind of absolute truth: There is none to be told. That's just my harshly acquired opinion, which is worth what it is worth: Nothing more than the one of any of us😊 I strongly encourage you to push this experiment, and even make a production ready library out of it... it might be useful to plenty of people not thinking like me ! ...worst case scenario: you'll learn from it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The roadmap about this library consider exactly this point.
Soon I need to integrate another ast parser for typescript to handle e mirror the parameters and the return type to be strongly typed on server and client 💪🏻
I dont want to spoil you the surprise, but here is a catch, with hidden RPC calls/proxies.
You'll soon enough want some kind of shared state between client and server (session authentication, ...). This is often carried by headers of your http requests. But by abstracting away the http calls, you have removed the possibility to your users to tweak those headers. If you dont want your users to be foreced to pass an extra argument to all their methods, you surely could devise some kind of static method
get/setState()that allows to carry the information you need accross calls, but this does not play well with async/await, nor with unit testing, and it hides things to your user, tending to bloat your code.Speaking of hiding, another problem you will face is that the lines between server & client will be a bit more blurred, meaning that it (arguably) leads some less experienced developpers to adopt confusing development habits. Sharing methods is fine, but you've put your finger in a mechanism that will probably will make you want to add support for shared object instances. And that's a rabbit hole you dont want to go down into.
It also leads to problems with API versioning, N+1 problems, and much more.
Being a seducing pattern, RPC is being reinvented every now and then. Like you, and like many of us, I've been there a couple of years ago, and everyone seems to be convinced at one point that it is a silver bullet... Trust me, I've dealt with too many RPC frameworks, and faced too many failures with this pattern (I'm watching at you, Dotnet Remoting) not to emphasis that RPC is neat, but has its drawbacks.
Now, I dont want to sound paternalistic by telling some kind of absolute truth: There is none to be told. That's just my harshly acquired opinion, which is worth what it is worth: Nothing more than the one of any of us😊 I strongly encourage you to push this experiment, and even make a production ready library out of it... it might be useful to plenty of people not thinking like me ! ...worst case scenario: you'll learn from it.