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

71–80 of 107 posts

Re: Do we need a web API?

#71

Post by mvila »

ptx wrote: post #54

The readme says: "The current state of an instance (i.e., counter's attributes) is automatically transported back and forth." How does this work? Do you need some cross-network locking mechanism when you need to make sure the shared object's state doesn't get out of sync between client and server? What about passing object instances between client and server? Does it do what (I think) DCOM does to handle garbage-coll…

A Liaison backend is stateless, so there is no shared state or garbage-collection to worry about.

Re: Do we need a web API?

#73

Post by mvila »

vbezhenar wrote: post #55

Having clear API allows to have a clear boundary between trusted and untrusted environment in backend. If you don't check your arguments in REST endpoint, it's obvious bug and easy to spot. If it's just another method, well, you're not treating input in every function as a hostile.

Please see my answer here: https://news.ycombinator.com/item?id=21660785

Re: Do we need a web API?

#76

Post by mvila »

SahAssar wrote: post #58

As someone deploying frontend apps for a large site you should not underestimate how long people have their tabs open. I can get sentry error reports for versions that have not been deployed for months. Does this handle "API" versioning in any real way?

For now, with Liaison, API versioning is no different than usual: preserved endpoint for backward-compatible changes and new endpoints for breaking changes.

Re: Do we need a web API?

#77

Post by peteforde »

As has been noted in other comments, there is a growing list of technologies that implement some variation of RPC such that events on the client trigger server events. Those events persist any data changed and then regenerate the current state of the UI and ship the diff back to the client, ideally via calls to the morphdom library.

What frustrates me is that it's not the API that is the source of complexity. ~80% of the pain of building most apps comes from managing the syncronization of state between the client and server. SPAs are the over-prescribed opiates here making the problem worse. Imagine what could be possible if you walked away from maintaining client state altogether.

We did, and it's wonderful. StimulusReflex let me build a reactive tabular UI with sorting, filtering and pagination with 115 LOC, none of which is custom JS: http://expo.stimulusreflex.com/demos/tabular

I honestly believe that the existence of things like StimulusReflex and LiveView demand we question the ongoing utility of libraries like React. Popularity is not a good reason to use something, especially when you realize you could be radically more productive if you don't use it.

Re: Do we need a web API?

#78

Post by adjkant »

z3t4 wrote: post #64
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…

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 get untyped, weird silent errors, under or completely un-utilized async features that end up causing more problems than they solve, and then all the quirks of JS to boot. I regularly hear the argument of the benefits of keeping the language the same on both ends, but besides slightly easier JSON between them (something handled by clean packages in almost every language these days with minimal effort/LOC/boilerplate) the languages don't end up actually sharing a ton given how you hook into a web framework like Express, database API's, etc. You don't get code reusability and I don't think the JS tradeoffs are worth the slight savings on context switching. If you have a serious project of any scale/long term use and have front end programmers that want to use JS on the backend, either bite the bullet and have them learn now or hire some backend devs in a language better suited to your project.

Re: Do we need a web API?

#79

Post by mvila »

zemnmez wrote: post #26

this is just JSON RPC? The "constantly serialize and deserialize it" statement is totally untrue too... The frontend makes 6 XHR calls just to render a single page and they're all just JSON. The idea of the frontend 'just calling' the backend with no API boundary is nothing short of atrocious for security. The only feasible logical end to this is ASP, which was an interesting idea when it was launched 19 years ago

This has nothing to do with JSON RPC. Liaison uses Deepr (https://liaison.dev) as a communication protocol.

Regarding the number of XHR calls, to be accurate, it is not 6 but 4. Once Liaison is complete and optimized, the number of calls should drop to 2.

Also, please keep in mind that Liaison is made for building single-page applications. So, using it for a simple blog might not be the right choice.

And about your security concern, please head over here: https://news.ycombinator.com/item?id=21660785

Re: Do we need a web API?

#80

Post by t0astbread »

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…

Play with? Sure. But for actually doing "the real thing" reusing tech you already have expertise in seems more efficient than trying to gain an equal amount of expertise in another technology. Add to that, if you're in a hurry you don't even have the time to learn anything new.
Post reply on HN