5 ms·

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 separat

by mvila 7y ago

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.

daxfohl 7y ago
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.
- mvila 7y ago
  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. About interoperability with non-JS environments, I wrote an article about that: https://liaison.dev/blog/articles/How-about-interoperability-oy3ugk https://liaison.dev/blog/articles/How-about-interoperability...
  - daxfohl 7y ago
    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)

by mvila 7y ago

daxfohl 7y ago

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.

mvila 7y ago
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. About interoperability with non-JS environments, I wrote an article about that: https://liaison.dev/blog/articles/How-about-interoperability-oy3ugk https://liaison.dev/blog/articles/How-about-interoperability...
- daxfohl 7y ago
  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)