Hacker News Reader

Comment by keepingscore | Hacker News Reader

He is operating in the mindset that the backend is just a dumb persistence layer with auth. If all the problems he is we solving fit into that world view than more power to him.

I'm a backend team lead for a travel company. To render that list of flights and hotels to the Android app it's not a database lookup. It's hundreds of soap and rest calls stitching together airline and hotel data from multiple platforms. This isn't something I can do on the front end. And even if I could I wouldn't want to replicate this logic between iOS, Android, web and our internal support portals.

View on HN

Have to agree wholeheartedly. He seems to have a problem landscape that involves CRUD on single 'documents/tables' with no business logic involved or required.

I suppose it is fine to have business logic in a client, but replicating that for every platform seems silly and a simple way to acquire huge amounts of technical debt and complex role out strategies. He says about being the only backend guy to ensure not much code gets written there. I feel like this is not a person I want to work for. Not even seeing the problem before telling me the solution.

This article could have been much better framed if it discussed using his suggested tooling to solve simple CRUD applications in a bootstrap scenario perhaps. But it has been my experience that long term, complex business systems that are created in Javascript are black holes of lost time trying to maintain and extend. Especially ones written to 'configure' the backend based on client defined configuration which he also suggests is a good thing.

Ditto. If your app is CRUD with auth, then, yes, fine (probably).

In our case we're running calculations across a large dataset on the back-end and serving up the results to the client. Due to the number of ways the data can be cut, pre-calculating everything anybody could possibly isn't cost-effectively feasible, so if we were going to stick all the business value in the client we'd have to load a bunch of the raw data into the client and then do the calculations there (in JavaScript!!).

Funnily enough that actually was the original approach, and it worked "OK" up to a point, except in Internet Explorer 11, which couldn't handle the memory consumption, and honestly it was dog slow everywhere else: both loading the data and doing the calculation. And of course this approach is a disaster on mobile.

Even if we could get calculation performance on the client that is better than the sum of time spent on the server plus latency, and maybe we could with WebAssembly or WebGL hacks, except that we'd probably have at least some incompatibilities to deal with (hey, starter for 10, IE11 again - who knew?), there's still raw data transfer to consider.

So now most of the smarts are in the back-end, and they'll stay there for the foreseeable future.

Reply on news.ycombinator.com