Light and modern web application

I am developing a modern, light and beautiful web application for openwrt

The features I considered for it:

Use lighttpd web server
Backend development with lua
API development with RESTful standard
Dedicated token system and sqlite database to store username and password information (without using shadow and passwd login information of the operating system)
Along with about 80% of the facilities currently offered by Luci

Front-end with dedicated framework and js style

Can this idea be widely used in openwrt? I will be happy to know your opinion

I welcome any suggestions and contributions
The repository where I started the project:

1 Like

Lighttpd, Lua and Sqlite dependencies are already heavier than LuCI.

2 Likes

I don't want to be a debbie-downer, but one of the biggest features of OpenWrt is the ability to add packages from the repo. Are you planning to 100% support current Luci API to ensure that luci applications can be added to your light and modern web application?

Why not contribute to/improve existing WebUI rather than write yet another management UI which would be locked down in features compared to Luci?

2 Likes

According to my calculations, the total size of the firmware for MediaTek 7628 was 7 MB.
While with luci, it is about 9 megabytes, and the operations on the side of the web application are very, very slow
And that you can even ignore sqlite and store the information in encrypted form in the file

I had this intention, but the connection between Luci and the backend is generally very slow and time-consuming. With a small operation like adding a port forward, you have to wait about 5 to 7 seconds for everything to be applied. This requires a fundamental change in the xhr section as well as the entire luci structure
Also, one of the weaknesses of luci is the use of the operating system root user, while the web application should not use the operating system user for validation.

Perhaps, with this change, developers who have previous experience working with front-end, back-end and restful on other platforms will be able to contribute.

This can be easily mitigated by lowering the apply holdoff time, it is set to 5s currently to cater to old and slow hardware where it took a while for the ubus changes to be propagated. The delay can also be eliminated entirely if the rollback feature is disabled. There is no inherent technical limitation here.

How so? Modern LuCI currently does almost all operations via HTTP tunneled ubus RPC calls, it's hard to get more efficient than that, at least when the goal is to interact with the OpenWrt system APIs (which are ubus based for the most part). I also have pending work to switch the XHR request polling to websocket connections instead, which would also allow for realtime ubus event handling.

How do you plan to trigger root actions with a non-root user? Most LuCI operations happen through the HTTP ubus interface backed by rpcd which provides fine grained access control for the operations and also allows defining user accounts not tied to any particular Unix user. There's very little server side rendering remaining.

One of the most cited reason for people being unable to contribute to LuCI was the use of Lua, followed by the use of vanilla JS / custom framework logic for the frontend. The other contributing factor is that the intersection between contemporary web developers, people who are resource-aware and proficient in embedded development and people who know enough about the inner workings of OpenWrt (and still care about a ui after that) is close to nothing.

Sure it is simple to whip a new ui that looks fancy and does the same 20 basics things one would expect from an OEM firmware, like setting a bunch of SSIDs, some port forwards a little bit of DHCP lease reservation. But the difficulty is scaling this up to hundreds of options, complex use cases, an underlying system that is a moving target with no fixed feature set and maintaining all that for a prolonged period of time. And trying to keep the size under control (hello, node_modules).

The LuCI project is about 15 years old by now, and it undergone at least three major refactoring phases during this time; from server side rendered Lua code to client side rendered views backed by server side Lua controllers followed by client side rendering backed by server side ucode controllers. This means it is possible to adjust the way the ui is working, while keep large parts of the existing addon ecosystem intact.

Of course it's not as much fun as simply starting anew, I understand that. But given the already very small pool of potential contribution capacity I am not sure it really would help OpenWrt to introduce yet another choice. Another issue is that OpenWrt is currently moving away from Lua starting with the 23.05 release, towards ucode which will also be utilized by the base system (e.g. within hostapd). This will allow the ui and the system to share a common scripting language, something Lua did not achieve in the past.

Of course I do not mean to discourage you from pursuing your goals, but since you asked if it can be used widely within OpenWrt, which implies some kind of endorsement and/or maintenance commitment from the OpenWrt project itself I thought it might be good to share my thoughts.

4 Likes

thanks a lot
Your explanation was very effective

I have several ideas for speed and creating access levels and restrictions for the http user that I want to implement and test in restful lua

But your explanation was great. In addition to this project, which started as a fancy project, I should submit ideas that can be implemented on luci as contributors to the main repository, maybe this will be more effective and helpful.

2 Likes