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

On Mon, Jun 11, 2018 at 3:59 PM, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com
> wrote:

> 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 *live* 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.
>>
>
>
>