Liaison has nothing to do with a backend-as-a-service. You can host your backend anywhere you want.
About authorization, Liaison doesn't expose anything by default. Only the specified attributes and methods are exposed, and there is an authorization mechanism so you can customize what you want depending on the user.
For now, Liaison is JS-focused. So both the frontend and the backend have to be implemented in JS.
But the communication protocol (https://deepr.io) in between is language agnostic. So it is possible to imagine Liaison being ported to different languages in the future.
I've been thinking about language agnostic RPC as well. That would be so neat!
gRPC can already do that but gRPC's design is unnecessary bloated. The nice thing about RPC is its potential of zero-config setup. gRPC totally fails on that and it's painful to setup gRPC.
The RoR/python server could be used to automatically serve the RPC API. For a zero-config setup.
Your point is valid, but Liaison allows you to build different layers if you wish.
If you worry about cluttering the business logic and want to clearly separate the exposed API, you can expose subclasses of your domain models instead.
I'd still say the established routine of publishing a public API and any shared code can go into NPM or whatever is the better approach.
Liaison and tools like it essentially create a monolith exactly where something is screaming to be two separate services. You want to be able to deploy versions of server side and client side code independently. You want to be able to ensure you don't break clients that have web pages open when you deploy the new server version. You want clients to be able to run where JS isn't available.
About API versioning, the problem is the same as any web API. It's possible to add backward-compatible changes, otherwise, you need to fork the backend into a new endpoint.
I don't mean to knock it. It's a cool project and obvious you've done some good work on it. But, I wouldn't expect it to lead anywhere beyond a couple sample POC apps. It's been tried before and never quite seems to work out (I did something similar with VB6 forms way back when. It didn't work out. Meteor.js is one that probably came the closest to real-world success. It didn't work out.). There was a bit more interest in this approach back when SPAs were just coming onto the scene, but in the time since, the programming community seems to have converged around the idea of well-defined boundaries and interfaces, allowing use of the best tool for the job in each individual service, and abstracting out the distributed communication layer with a metaprogramming tunneling approach has somewhat fallen out of favor.
If your goal is just a brain workout then by all means keep going with it. But if you're looking to do something that gets some larger adoption, then I'd probably wrap this up and move on to the next thing.
(Not that you asked my advice, or that I'm in any way qualified to give it)
For now, with Liaison, API versioning is no different than usual: preserved endpoint for backward-compatible changes and new endpoints for breaking changes.
For now, yes. Liaison is implemented in JavaScript, but the communication protocol (https://deepr.io) is language agnostic. So it is possible to imagine Liaison being ported to any languages in the future.
About authorization, Liaison doesn't expose anything by default. Only the specified attributes and methods are exposed, and there is an authorization mechanism so you can customize what you want depending on the user.