Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hub GUI #9

Closed
th0mas opened this issue Jul 9, 2020 · 7 comments
Closed

Hub GUI #9

th0mas opened this issue Jul 9, 2020 · 7 comments

Comments

@th0mas
Copy link
Contributor

th0mas commented Jul 9, 2020

Currently there's not a "good" way of interfacing with the Hub Server - I'm currently using Insomnia, a REST api development tool.

We should probably build a GUI on top of or next to this API at some point.

Our options are:

  • React SPA. This allows us to build on top of the existing API and is what I'm most comfortable writing. In addition, using Phoenix channels in React with Hooks is very ergonomic

  • Elm SPA. Currently(?) seems like Dwyl's go to framework. Haven't used elm much/at all but will be happy to look into this.

  • Phoenix SSR. Standard Phoenix web app. Benefits of this are no extra setup or config. However, we will need to duplicate some code between API and browser pipelines and write a lot of JS anyway for realtime support.

  • Flutter? Is it worth building one app for mobile and web?

@nelsonic
Copy link
Member

@th0mas thanks for opening this issue to capture the requirement, discussion and decision of what to do next. 👍
We tend to avoid React wherever possible in favour of Elm which is a lot easier to maintain.
We will eventually integrate this into our Flutter App but for now,
our preference is a Phoenix SSR just in terms of simplicity and ease of maintenance.
Having it as a SSR will mean we can easily load it in a WebView in Flutter without having to rewrite it in Dart.
The initial page load on SSR pages is considerably faster. And as noted in https://github.com/dwyl/phoenix-todo-list-tutorial the UX is comparable to a SPA for subsequent pages/routes.

Perhaps the best question in terms of advancing with this is: What want to include in the GUI?
Please see: #12

As for using Insomnia https://insomnia.rest | https://github.com/Kong/insomnia
We used Mashape (now "Kong") back in the day, but have not used insomnia; it looks good. 👍
Are you paying for the "Plus" version? Or do you get what you need from the "free" App?

image

Where did you find out/learn about it?

@th0mas
Copy link
Contributor Author

th0mas commented Jul 13, 2020

Been working on a LiveView/SSR GUI all morning and have some thoughts:

  • LiveView(s) do not integrate well with the existing MVC code, this means there will be some duplicated code.
  • Personally, I don't yet have a "mental model" of LiveView apps, slowing my development time considerably.
  • Theres a few awkward edge cases, e.g. conn assigns don't map onto our socket assigns, meaning we can't access our Auth.Plug info from within a LiveView.
  • Lack of editor support for EEx files is fustrating - especially compared to JSX.

I'm sure some of these problems (my own experience) will be solved with time, but I'm mindful of not taking too much time on this. I'm happy to press ahead with SSR if needed.

The REST API is fully documented now, is it worth just working on a Flutter application?

@th0mas
Copy link
Contributor Author

th0mas commented Jul 13, 2020

Currently using the Free Insomnia version, and pretty sure I heard about it on HN. Its useful for testing out REST APIs and developing them.

My workspace currently looks like this:

image

@nelsonic
Copy link
Member

@th0mas yeah, I get the feeling that LiveView Apps are meant to be a lightweight alternative (in terms of code/boilerplate) to MVC. Many people appear to like them for their single file/page approach. But totally get it if you prefer to have a separation of concerns between the API and UI. 👍
We could have a simple lightweight Pub/Sub (Phoenix) socket to display desired content on the Welcome Display. This doesn't have to be more than 10 of lines of JS:

import socket from "./socket"
let channel = socket.channel('room:display', {});
channel.on('update', function (payload) {
    fetch(payload.url).then(function (response) {
      return response.text(); // get HTML content of response
    }).then(function (html) {
      document.body.innerHTML = html; // replace contents of page
    })    
});
channel.join(); // join the channel.

e.g. the client would receive a notification of an update over WebSocket Channel
and then just do a full page refresh of the new content.

@th0mas
Copy link
Contributor Author

th0mas commented Jul 13, 2020

On the Welcome display I was going to use Scenic, unless you would prefer a browser based version?

I'm currently building a basic Admin interface for the hub

@nelsonic
Copy link
Member

@th0mas yep. that makes sense. the Admin interface does't need to be fancy at all. MVC is perfect.
Scenic for the Welcome Display makes sense as previously discussed. Sorry for the confusion. 👍

@th0mas
Copy link
Contributor Author

th0mas commented Jul 28, 2020

GUI Implemented for both Hub and edge nodes

@th0mas th0mas closed this as completed Jul 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants