Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do we need a web API?

liaison.dev

Post reply on HN
Print view View original

81–90 of 107 posts

Re: Do we need a web API?

#81

Post by mvila »

purple_ducks wrote: post #42
stopads wrote: post #4

>Sorry, this site requires JavaScript to be enabled. For a flat blog post? Like, seriously?

the OP message falls flat when it can't even be bothered to server render. also, most offensive is the use of 3rd party js hosting. given the tiny size of the 3rd party libraries (relative to 1st party code), add them in to the code from your own site (which you're already bundling up. SMH) [from jsdelivr.net] polyfill.min.js (31.8kb/96.8kb) (wire/resource) url-polyfill.min.js (1.9kb/6.1kb) react.production.min.js (4…

I don't understand why it is wrong to use CDNs to distribute common libraries.

About the fact that I have used Liaison to build its own website, I agree that it might not be the best choice. :)

For now, Liaison doesn't support server-side rendering, but it is something that could come eventually.

Re: Do we need a web API?

#82

Post by mvila »

daxfohl wrote: post #47

Things like this have been tried many times before. (I made one myself back in the day). It always seems like a great idea up front, but never ends up quite working out. One of the big things is that the benefit declines over time. The amount of code reuse you get is sub-linear with respect to the size of the project. As the project matures, GUI code and back end code diverges. That leaves you stuck in a framework th…

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.

Re: Do we need a web API?

#83

Post by mvila »

briandilley wrote: post #48

RPC - this isn't anything new. When I started doing web development in the late 90s for about ~5 years I was the designer, front-end, and backend developer all in one. Then over time things changed to allow for specializations and we now have many different functions, and that's a good thing. RPC has a place, and it's not for web apps, at least most of the time. I've noticed over the years that JavaScript developers…

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.

Re: Do we need a web API?

#84

Post by z3t4 »

adjkant wrote: post #78
z3t4 wrote: post #64

Earlier quoted context omitted.

Wouldn't you prefer to talk in your mother language instead of using a new language for every country you visit?

At first, but not if it made it harder to communicate in each country I visited if I was visiting those countries regularly. I think the parent is likely onto something in that the spread of JS into backend services is not beneficial to those who spend most of their time on the backend, but it beneficial to those who don't. That's IMO creating an inherent tension. Personally I have never understood backend JS as you…

As someone coming from web dev to back-end JS I take with me the love for instant feedback, which allows for extensive manual testing during development. And I also use automatic regression tests before pushing to prod. Node.js is infamously known to use small modules, it however gives you battle tested code run by thousand in production.

I usually take a front-end first aproach, but there are also lots of people taking a backend first aproache where they rely more on static analysis, compilation, unit tests and packaging - rather then manually testing every LOC.

Re: Do we need a web API?

#85

Post by theamk »

z3t4 wrote: post #84
adjkant wrote: post #78

Earlier quoted context omitted.

At first, but not if it made it harder to communicate in each country I visited if I was visiting those countries regularly. I think the parent is likely onto something in that the spread of JS into backend services is not beneficial to those who spend most of their time on the backend, but it beneficial to those who don't. That's IMO creating an inherent tension. Personally I have never understood backend JS as you…

As someone coming from web dev to back-end JS I take with me the love for instant feedback, which allows for extensive manual testing during development. And I also use automatic regression tests before pushing to prod. Node.js is infamously known to use small modules, it however gives you battle tested code run by thousand in production. I usually take a front-end first aproach, but there are also lots of people tak…

Instant feedback is pretty common on backend thought? I know that at least Flask and Django in Python have it.

And automated regression tests before pushing are in ever other language as well.

Re: Do we need a web API?

#86

Post by mvila »

fyp wrote: post #15

Pouchdb/firebase/backend-as-a-services were supposed to be the answer to getting rid of CRUD apis. The problem is authorization and validation becomes really difficult if you don't have a backend that you can trust.

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.

Re: Do we need a web API?

#88

Post by daxfohl »

mvila wrote: post #82
daxfohl wrote: post #47

Things like this have been tried many times before. (I made one myself back in the day). It always seems like a great idea up front, but never ends up quite working out. One of the big things is that the benefit declines over time. The amount of code reuse you get is sub-linear with respect to the size of the project. As the project matures, GUI code and back end code diverges. That leaves you stuck in a framework th…

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.

Re: Do we need a web API?

#90

Post by mvila »

daxfohl wrote: post #88
mvila wrote: post #82

Earlier quoted context omitted.

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 pag…

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...

Post reply on HN