5 ms·

I'm surprised this wasn't about WASM. Either way, I'm receptive to the "LiveView" model, but until such a time a server can deliver both HTML and server driven

• rkangel 5y ago
  > until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach. I really think this is such a key point and is the main blocker to this sort of architecture for cases where you need to support all the platforms. That said there are a lot of web applications that just need some form of UI and don't need full multi-platform support and LiveView type systems involve many fewer pieces to get going with. I'm thinking more here about company internal tooling for whatever purpose, rather than web services provided to customers which are more likely to need mobile apps. Also, let's say you've already created your backend in Elixir (e.g. using Phoenix for GraphQL or JSON), and have built your mobile app against it. To implement your web frontend, is it easier and better to roll a whole JS app from scratch or just interface with the APIs that already exist locally to produce a LiveView app? Obviously there are some app characteristics that dictate this, but for a lot of things LiveView is still going to be easier. But then, maybe I'm biased because I dislike frontend programming!
  • lostcolony 5y ago
    I'll also say, one of the key lifts for LiveView is specifically (unsurprisingly) live updates. That is, server pushes. Websockets don't really make sense to use as a broad bidirectional communication tool; they're overly complicated for situations you can just open a plain TCP socket to communicate over, and making them a requirement for clients that have no need of them is a poor ask. So as soon as you're supporting a client other than a browser, while still supporting a browser, you already are going to likely want to support two APIs. Good design will allow you to share your model for bidirectional communication regardless of the connection type, and you can then bake in any updating JS into the Websocket connection via LiveView or similar, while exposing a more normalized socket endpoint for other servers, mobile clients, etc. Even if you end up having to support multiple connection assumptions at a later point (i.e., a Websocket connection for your web client that contains JS, a Websocket connection for a web client being developed by a different team that should just return data, and a plain socket connection for non-browser based connections), the lift should be pretty small.
• funcDropShadow 5y ago
  As always, this depends on the use case. For in-house applications it is often far simpler to keep a lightweight frontend and mobile app is often of no concern. For these kinds of web application a server-heavy architecture was always a good choice.
  • lucasyvas 5y ago
    Of course, this is true. But I prefer architectural patterns that are flexible for future use cases, especially when there's no logical reason why it shouldn't be supported. You can start this way, but if you have a new requirement, you might reach a technological crossroad and ask yourself "why do I have to add a new paradigm? If the thing I'm already using could just do X, I'd save a shit load of time and/or money." You can always add, yes. But why do I have to? The world has treated web and native as separate for far too long. We're really just squabbling over UI toolkits, so why can't we come up with something that just says "Fuck it, we're supporting both native and web as first class in every server framework because that's how it should be. And we're also going to let you use any language in the browser because that's how it should be"
    • funcDropShadow 5y ago
      Yes, but as engineers we should strive for the simplest possible approach that solves the problem in a maintainable way. Always choosing the most flexible / the most scalable / the most modern approach is often a waste of resources. > why do I have to add a new paradigm? The answer to that question also depends on which paradigm you are using currently, not only on which you are choosing for the future.
    • girvo 5y ago
      I hope one day we can. Though the incredibly tightly coupled server-side-logic nature of LiveView is, I think, a bad fit for the intermittent network architecture of mobile devices. But in theory I see no reason why you couldn’t deliver LiveView to some mobile runtime that controls its native UI via some abstraction layer. Hell, some of the React Native stuff I’ve seen gets close already.
• deleted 5y ago
  [deleted]
• nopcode 5y ago
  This is what Strada (COMING SOON) is aiming to solve.
• Zababa 5y ago
  It's surprising to me that you want to user native UIs for mobile but are fine with web UIs for desktops/laptops. What's your reasoning behind this?
  • lucasyvas 5y ago
    I think this is just poor phrasing on my part since mobile was top of mind. I'd like to see this work with any native UI that supports an online feature set. I'd like to see the technology work with HTML or server driven native UI, and let developers decide which UI toolkit is best for their app market. Since it would theoretically support both, you could incrementally transition as well.
    • Zababa 5y ago
      That makes a lot of sense, thanks for the explanation.
• ensignavenger 5y ago
  I am currently developing sites with Django and DRF, where the client requests what format it wants and the server sends it in the format of the clients choice- a browser would request HTML, in which case the server sends HTML- using htmx. A mobile app might request JSON, or XML or CSV or any other supported format. No need to develop a separate API for web and mobile- its all the same API. DRF makes it very easy. Now, I haven't dug into Apple iOS dev yet, I know they have some artificial limitations on what an app can receive, but thats an Apple limitation, not a technical one. I'm pretty sure Apple allows an iOS app to receive data over the Internet and render that data within the app? I just need to figure out what format it can be sent it for the app to render it.
  • jagged-chisel 5y ago
    Your app can certainly request whatever data in whatever format from whatever server it wants. Making substantial changes to the app's functionality using this channel is disallowed.
• udbhavs 5y ago
  Didn't AirBNB try something like this?
• tie_ 5y ago
  I'm happily using Phoenix+LiveView for a website that works as a PWA. This also includes offline mode with sync-when-internet-is-available functionality (thanks PouchDB!). This covers online/offline/mobile usecases, with no explicit RPC, and no requirements for the end device that the app would run on, other than a _capable_ browser. (Admittedly, browsers on iOS are gimped, but that's part of the Apple tax).
  • jjtheblunt 5y ago
    what is gimped about iOS browsers?
    • tie_ 5y ago
      WebPush is the feature that I'm missing. See https://developer.apple.com/forums/thread/114503 https://developer.apple.com/forums/thread/114503
  • ngrilly 5y ago
    I don’t understand. How is the app working in offline mode when the Phoenix server is not reachable, since the interactions are managed server-side with LiveView?
    • tie_ 5y ago
      Sorry, my statement indeed got confusing. I'm using LiveView for online interactions. I'm using PouchDB + JS for data synchronization and enabling offline work. You are right that LiveView itself does need to be online, since it's whole point is to move (back) the UI logic to the server side.
      • ngrilly 5y ago
        Thanks for clarifying!
• oscargrouch 5y ago
  > I feel like this would enable a more sensible choice: I have a working solution for something like this that is based on Chrome https://github.com/mumba-org/mumba https://github.com/mumba-org/mumba The applications developers publish native, Swift applications, where Swift have the full access to the Webkit/Blink api the same way Javascript does and even more with the patterns from the Chromium renderer (for instance, access to lifetime events, OnDocumentLoaded, OnVisible, OnFirstPaint, etc..). The offline first comes from the fact that every application runs first as a daemon which provide a gRPC api to the world of the services it offers, where the web-UI application process might also consume this same api from its daemon -process manager or from other applications. Note that the daemon process who is always running give access to "push messages", so even if no UI app are running things can still work, like syncing into the DB, or even launching a new UI application given some event.. This service process also is pinged back by the web-UI process for every event, so the daemon process can also act when theres a need (when everything is loaded on the UI, do this..) Also about the article, note that with this solution you will code in pure Swift (not WASM) just like the article is pointing out the web applications that can be built without any javascript. Other languages like Rust, C++, Python can be added giving the Swift applications are talking to the runtime through a C api. (And i could use some help from other developers who also want this in other languages) If you want to ship your applications with this, you will get a much better environment than Electron, using much less resources, as things are being shared to every application, and the cool part is the applications can consume one another services (for instance a Mailer application) forming a network, and depending one-another (the magic here is that they are all centrally managed by a core process that is always running)
• yumraj 5y ago
  > 1. Both an API for mobile and LiveView for web. Is that really that hard a problem? In the other/current model you're building total 3 components: web frontend, mobile frontend and the API and in the liveview model you're again building total 3 components: LiveView for Web front/backend, and mobile frontend and API for mobile backend. If done properly, the LiveView backend can share a lot of code with the API backend. Moreover, an added advantage is that the Web codebase and Mobile codebase can be different depending on the requirements of the two platforms, except where, as noted above, it makes sense to abstract it out and share. So, IMvHO better software engineering in general.
  • lucasyvas 5y ago
    It's not a hard problem, but I consider it to be a dumb problem. Let's say I have absolutely zero business purpose for an API - like zero. Neither general purpose or single purpose. I now have to make one to serve a native/mobile app. I have to pick language, I have to design API surface, pick an RPC framework, REST or GraphQL, I have to adopt a different testing strategy for it, etc. When all I really wanted to say was: "Hey server... can you serve a slightly different template connected to all the logic I've already written that a mobile app can understand as long as the app contains a component library?" As for the opposite model where you are API first, at least you have the language, API contract / technology, testing strategy in place. And it will work regardless of what your clients are! The clients then implement their own UI, ideally on top of some shared, headless client (maybe a native module?) and you have maximized code re-use. Only the UI tech is different (and that's a maybe, since you could use flutter or RN), and is tailored to each device nicely. So I do think the second is VERY desirable because it's single paradigm and you can go pretty far to reduce duplication of effort, almost entirely. There is no such possibility in the server-driven paradigm, and I'd like to see it because it would give me all the re-usability benefits of the second approach, with a huge advantage of making the clients leaner. It's a personal thing, but I personally don't want to smash my web-app backend into the same service as a general purpose API. It requires a lot of discipline to keep the concepts separate, and it fails more often than I've seen it work. I do appreciate your comment here of "better engineering" because I so very much wish for that. I wish that the average Django/Rails/Phoenix/whatever framework would not turn into a swampy piece of junk when you keep both responsibilities in the same codebase, but they often do. The options we have are pretty decent - I just think something like LiveView could be better. Its only promise is a (admittedly slicker) take on SSR for the web. That doesn't move the needle far enough to be revolutionary to me, and doesn't solve a problem that most people have. The problem we have is that the server paradigm is way, way behind where it should be when it comes to serving different types of clients.