On Mon, Jun 11, 2018 at 3:59 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com > wrote:
> Hi Team, > > On Sat, May 5, 2018 at 3:31 AM, Joao De Almeida Pereira < > jdealmeidapere...@pivotal.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=n...@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. >> > > >
