Project

General

Profile

Feature #9519

rewrite the admin console using native HTML/CSS/Javascript and the RESTful admin API

Added by Greg Shah over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to Runtime Infrastructure - Feature #6486: complete the admin console New
Blocked by Runtime Infrastructure - Feature #7080: expose all admin APIs via REST Test

History

#1 Updated by Greg Shah over 1 year ago

#2 Updated by Greg Shah over 1 year ago

#3 Updated by Greg Shah over 1 year ago

The idea here is to eliminate GWT usage. This reduces dependencies on 3rd party code and potentially simplifies our long term development and support of the admin console. GWT was used because our first iteration of the admin console used Swing. That made GWT an easier path for migration to a pure web approach (no applets). My sense is that using GWT is a bit heavyweight and does restrict us.

Once our admin API is fully available on a RESTful basis, putting a lighter weight web UI in place might make sense. We can discuss pros and cons here.

#4 Updated by Galya B over 1 year ago

To me the important points are:
  • tech stack in the context of reduces dependencies on 3rd party code;
  • authentication and authorization;
  • typization and structure of the front-end code (for readability and maintainability);
  • interfaces in the context of my proposal to use Swagger;
  • decision on browser versions support and screen support (responsive design).

#5 Updated by Galya B over 1 year ago

A `native` HTML/CSS/Javascript approach is recommended to have the bare minimum of a package manager (npm), typization (TypeScript), coherent style (a linter), clear approach to organizing css and client SDK generated by Swagger Codegen, and IDE support (build, import, smart suggestions).

#6 Updated by Galya B over 1 year ago

Also a very important question: Is it going to be a single page application that needs only one entry point on the server and downloads all the sources in one go (not sure how to support routing / history / templates without additional libraries), or is it going to be a classic web site with many routes managed by the container server? Is it going to be always deployed on the same server as the API (as it is now), thus not requiring cross-domain requests and no server-side code?

#7 Updated by Greg Shah over 1 year ago

Is it going to be always deployed on the same server as the API (as it is now), thus not requiring cross-domain requests and no server-side code?

Yes.

The other items we can decide later.

Also available in: Atom PDF