Hacker News Reader

Comment by tootie | Hacker News Reader

What exactly is the value of this though? Isn't most non-UI code going to be buried in your server APIs no matter what? Most apps end up being 90% UI code.

View on HN

> Isn't most non-UI code going to be buried in your server APIs no matter what?

As someone who has had to maintain apps across web, iOS and Android, the answer to that is most definitely no.

I don't get it. If you're sharing logic across web and mobile doesn't that demand moving as much work as possible to the server? I've built a plenty of web and mobile apps and that's how I've always done it. Maybe I'm not thinking of the kind of tasks you're talking about. Can you give an example of what kind of process would need to be run on device that's independent of UI?

Giving a good experience with poor connectivity means the clients need to be able to reason about updates to the domain model and potential conflicts. At this point they need to reason about almost as much as the server.

Search for "offline first" to see how people are exploring architectures like this.

Edit: source: I worked on a product bundling chat functionality as a plug in.

In fairness, I think this is not so relevant for apps which are consumption first, but if there's any kind of collaboration, or even just writing from the client, you want to show an optimistic (at least; some systems make the client state canonical) representation regardless of sync status.

Authentication and identity management comes to mind immediately.

But, of course, there are plenty apps that prefer to do things locally, for so many reasons - if Spotify downloads songs, it does so locally. Or a note taking app such as Evernote needs to capture and compress whatever was drawn on the screen. Not to mention games!

If you think about more than CRUD apps, you’ll see that there are plenty things to be run on the device which are independent of UI.

Some use cases I think about off the top of my head:

- Data model operations on local copy of data: For some use cases you can't just send everything to the server all the time, instead you want a local representation which is periodically synced with the server

- Logging / monitoring: Expose a single logging / monitoring API which can be shared across platforms

- Input validation / rules engine: Consider implementing a syntax highlighter, you wouldn't want to do that on the backend. Even simple form validation might sometimes be preferable to do client side, calling the multiplatform validate(data_model) and getting per-field validation back would allow for a lot of logic re-use.

- Do work that could be done on the server: Because of a lot of factors, like privacy or cost you might want to do work that could be done on the server. I.e, calling some sensitive third party API (banking?) where you have to transform requests/responses. Or maybe computation on large sets of data (video compression?) which otherwise would need to be sent to the backend.

- Interact with devices only locally accessible: IoT/bluetooth things

If you're moving most of logic to the server, why have an app at all? Just build a website. For me app means offline work.

Mobile apps often achieve better conversion rates than mobile websites - at least for e-commerce.

If it's only the reason why build app, it looks like providing WebView wrapper based app is just fine.

You end up duplicating the logic achieve to offline-first, and reduce network roundtrips. Eg your sign up page final validation is probably the server's job, but if you want to give earlier/faster failure messages, you'll want it on the frontend too.

Server authoratative validation is security; frontend validation is UX

that’s not true at all. especially for apps like netflix or youtube, but even average apps

source: have worked on apps you likely use every day

I've worked on plenty of small to mid-size apps and that's not how we ever do it. Like I said, we build views and API requests. That's just the same MVC framework for the past decade or so. And I've done the same for streaming services albeit not at the scale of Netflix. Given how apps like Netflix and YouTube are so nicely synced between mobile, web and STBs I'd still imagine all the logic and persistence is server-side. I can only speak from my experience though, I'd love to understand how you've done it and when you need to embed a lot of non-UI code in a client.

Both Netflix and Youtube (premium) can be used completely offline. I would guess that the iOS and Android apps have a pretty encompassing local data model to keep track of everything from watched status to settings changed in the preferences. Not to say that it isn't synced with the server, but the server isn't the only representation.

most MVC apps do still have a decent amount of business logic for things like caching (either http responses, or images, or a local db), authentication etc.. In theory the goal for a lot is to have a dumb client like you said but that's rarely the case.

If you can have your apps share their data models between both android and iOS you can have the apps share the HTTP request/response handling and their DB code etc and then it truly becomes just a dumb client.

YouTube/Netflix also have complex video encoding/playback code that can be written in c++ and shared between clients.

Most social media apps liek FB/Insta/Snapchat have complex camera and photo handling code as well as async messaging code. Which if you have things like retries or photo compression/encryption you'd probably want to share between clients. etc..

Let’s say you’re creating a presentation builder app and one of the requirements is that it work in airplane mode since people are likely to use the app to put together presentations while literally on an airplane. Having all the logic server-side simply doesn’t work for that use case.

Sounds more like you've never written an app.

But put logic aside being able to use the same programing language across platform eliminate a lot of the context switching.

They literally say in the article that 50% of their code is decoupled from the platform.

Reply on news.ycombinator.com