Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

All persons interested by openIMIS will try the reference application before planning any customization. Today, today modular infrastructure has at least 5 components quite different from each other (database:

  • Database: T-SQL

...

  • Gateway: Perl

...

  • WebApp:

...

...

  • Backend: Python

...

  • Frontend: Javascript

...

By working on the support ticket tickets, it was clear that it this is way too complex. In addition, today’s architecture use uses a hack for the session management (luaLua/perl Perl script in the gateway) which leads to a timeout synchronization issue.

All those technologies runs run under windows Windows but not under Linux (webapp is blockingblocked by WebApp).

Once the webapp WebApp will be completely migrated, a rework will be required to remove the webapp it from the stack and to manage differently the session.

Proposal

Reduce the number of component components to simplify the setup.

1

...

. Remove frontend

As it was already done for Nepal, the front end frontend code can be hosted in ISS, because IIS. Because there is no “From” folder in the webapp WebApp, it can be deployed along with the webapp, WebApp and it can be updated later without impact on impacting the rest of the webappWebApp.

Because there is no drawback, I propose the proposal is to include the reference build frontend within the webapp WebApp release package in GitHub.

2

...

. Solve the session

...

timeout and remove the gateway

The complexity of removing the gateway comes from the lua Lua script used for the ibackend authetification authentication that need needs to be deployed on ISS, even IIS. Even if there is a package call called ISSLUA, it is not given that it will work with the reverse proxy setup.

A solution could be to make a an “Authentication” service in C# (same as the restAPIREST API) that will act as a reverse proxy for the python ibackend (graphqlGraphQL). The advantage of the solution is to reuse the RESTAPI authentification REST API’s authentication code and add some standard reverse proxy code. The potential drawback is the additional load on the webapp WebApp, but this solution simplify simplifies the scalling scaling because it will support a perfectly sticky session on the frontend.

Example: https://stackoverflow.com/questions/35903237/a-simple-reverse-proxy-using-asp-net-c-sharp-with-authentication

3

...

. Link the backend

The backend doesn’t use the webapp WebApp authentication but a file-based authentication therefore . Therefore it should be easy to configure a reverse proxy (ARR and rewrite IIS module) and to disable anonymous access, windows . Windows authentication could be used iinsteadinstead.

4

...

. Remove the ibackend and backend

this This step is maybe not required/wanted, but we could configure the backend as CGI in ISS IIS and the ibackend as CGI called by a .net code (to use the same authentication as webappWebApp)

Example: https://medium.com/better-programming/running-python-script-from-c-and-working-with-the-results-843e68d230e5

...