Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree

Hi Team,

On Sat, May 5, 2018 at 3:31 AM, Joao De Almeida Pereira <
jdealmeidapereira(at)pivotal(dot)io> wrote:

> *...*
> 3. Start the discussion on application architecture
>
> Why should we care about location of files inside a our application?
>
> Why is this way better the another?
>
> These are 2 good questions that have very lengthy answers. Trying to more
> or less summarize the answers we care about
> the location of the files, because we want our application to communicate
> intent and there are always pros and cons
> on all the decisions that we make.
>
To be honest, it depends on how do you see the application, and its
expectations.
That question leads me to another question "What do we want from pgAdmin 4?"

At this point the application structure follows our menu, this approach
> eventually make is easier to follow the code
> but at the same time if the menu changes down the line, will we change the
> structure of our folders?
>
To be honest not menu driven. (Probably a wrong choice of word 'Menu'.)
But - only under 'browser' (You can also call it object browser/tree), it
is driven by the database object relation model.
And, each module maintains the parent-child relationship.

> The proposal that we do with the last diff of this patch is to change to a
> structure that slices vertically the
> application. This way we can understand intent behind the code and more
> easily find what we are looking for.
>
In the current structure if you want to see the tables code you need to go
> to
> pgAdmin/browser/server_groups/servers/databases/schemas/tables/ this is a
> huge path to remember and to get to. What
> do we win with this?
>
I agree - it is too deep structure.
But - it gives me the idea what's the structure of the database objection
relationship.

Does it hurt, I would say no?
Because - as a database developer, I know whats the relationship of
objects, and where I can find them.
(Until I heard Dave saying it is about to touch the limit of maximum file
system path.)

So - there is a scope for improvement there, we can leave without the
object relations (but - limited to the object browser I think).

> If we open pgAdmin we know which nodes to click in order to get to tables.
> But for development
> every time that you are looking for a specific functionality you need to
> run the application, navigate the menu so that
> you know where you can find the code. This doesn’t sound very appealing.
>
What if our structure would look like this:
>
> - web
> - tables
> - controller
> - get_nodes.py
> - get_sql.py
> - __init__.py
> - frontend
> - component
> - ddl_component.js
> - services
> - table-service.js
> - schemas
> - servers
> - ....
>
> I think - there is nothing wrong with the current module structure. It is
more appealing to me than the above one.
The python package contains the backend code, and static contains all your
frontend.

I am not saying, we should not change anything.
We can definitely divide them in smaller chunks for both backend, and
frontend side.

This would saves us time because all the information that we need is what
> are we working on and everything is right there.
> Menu driven structure Intent Driven Structure
> *Pros:* *Pros:*
> Already in place Explicitly shows features
> Self contained features Self contained features
> Support for drop in features Support for drop in features
> *Cons:* *Cons:*
> Follows the menu, and it could change Need to change current code
> Hard to find features Some additional plumbing might be needed
> Drop in features need to be placed in a specific location according to the
> menu location
>
> What are your thought about this architecture?
>
I am not a fan of flat file structure in application.
There are many reasons - why we need namespace in C++, same applies here.

Let me start from the question "What do we want from pgAdmin 4?"
* A object browser
* Miscallenous operations associated with the object shown in the object
browser
+ Reversed Enginering query (if any)
+ Properties Viewer
+ Edit/Create Viewer
+ Staticis
+ List of dependencies
+ List of dependents
* Query tool
* Data Viewer (table/view)
* Function debugger
* Extendability/Pluggability

According to me - these as the intent of the application, and not objects
assiciated with them.

I do agree, there is no boundry (or, very thin) between data & presentation
at the moment.
We can start from there.

I can think of the following directory structure ( which is not too
different from the current, but - still will give the developers a lot more
comfort as per your complain :-) ).

> pgadmin/
> - database_objects/
> - server/
> - __init__.py
> - create.py
> - get.py
> - sql.py
> - update.py
> - static/
> - img/
> - server.svg
> - server_bad.svg
> - javascripts/
> - server.js
> - ui_schema.js
> - database/
> - templates
> ...
> ...
> + schema/
> ...
> - tests/
> - api/
> ...
> - gui/
> ...
> - karma/
> ...
> - browser/
> + pgagents/
> - server_groups/
> - servers/
> - databases/
> - __init__.py
> - node.py
> - schemas
> ...
> ...
> ...
> ...
> + tests/
> - tools/
> + sqleditor/
> + dataviewer/
> + debugger/
> - misc/
> + sql/
> + statistics/
> ...
>
> NOTE:
We also need to think about the facts that.
These changes may lead to a lot of night mare packagers to make changes in
the installers in upgrade mode.

Also - when I say pluggability/extendability, we should be able to create
plugins on top of pgAdmin 4.
Just take an example of this feature (Geospatial Query Viewer)
<https://www.postgresql.org/message-id/CAKyzeV1V1c_=KfLLxnzF7-fXWKLBiGgru1tz_+XRDXJWJ=nbVA@mail.gmail.com>
.

I think - it is best implemented as an plugin, as not every pgAdmin user
will benificiary.
We need ability to load the modules as pluggable module same as we used to
have before we introduced the webpack to bundle everything as modules.
We also need to start thinking about it.

-- Thanks, Ashesh

Around minute 7 of this video <https://www.youtube.com/watch?v=hALFGQNeEnU>
> Uncle Bob shows an application written
> in rails to talk about architecture. It is a long KeyNote if you are
> curious I would advise you to see the full video.
> His approach to architecture of the application is pretty interesting.
>