Remove projects page

[WULCAN]

Now that we have the pretty home page, there is no need for the old projects page except maybe as a base for a future administrator UI. An admin UI is pretty far away though and in the meantime, it is useful to reduce complexity as we expect some large changes in #25

[amerharb]

in General this a good refactoring but not in the right direction I think.

Currently the new page of projects have ServerConfig and LyraConfig as their source of information, which will make things harder if we want to isolate FE from BE

Now by removing the projects endpoint we lost this source (you mention about that when later we need an admin UI). but I think what we should do is refactor in the new page to read its information from the API rather from the classes (also all other FE should do that same)

So which architect going for:

• A: if want to isolate FE and BE, eventually make them 2 separate projects then we shouldn't do this refactor.
• B: if want to keep them in one project then this is really good also we should make all page read directly from classes which even faster.

[WULCAN]

in General this a good refactoring but not in the right direction I think.

Currently the new page of projects have ServerConfig and LyraConfig as their source of information, which will make things harder if we want to isolate FE from BE

Now by removing the projects endpoint we lost this source (you mention about that when later we need an admin UI). but I think what we should do is refactor in the new page to read its information from the API rather from the classes (also all other FE should do that same)

So which architect going for:

* A: if want to isolate FE and BE, eventually make them 2 separate projects then we shouldn't do this refactor.

* B: if want to keep them in one project then this is really good also we should make all page read directly from classes which even faster.

I'm not entirely sure I understand what we mean with isolate FE and BE, please explain so that I don't misunderstand what this discussion is about.

Since it was Henry who introduced the style of pages reading directly from classes, I asked him about his opinion and we had a long an interesting discussion about that on slack. I learned that Next recommends the style of pages reading directly from classes, but through an explicit data access layer: https://nextjs.org/blog/security-nextjs-server-components-actions.

Next also seems to favour server components for pages and they write some motivation for it here: https://nextjs.org/docs/app/building-your-application/rendering/server-components#benefits-of-server-rendering See also https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#when-to-use-server-and-client-components

[amerharb]

in General this a good refactoring but not in the right direction I think. Currently the new page of projects have ServerConfig and LyraConfig as their source of information, which will make things harder if we want to isolate FE from BE Now by removing the projects endpoint we lost this source (you mention about that when later we need an admin UI). but I think what we should do is refactor in the new page to read its information from the API rather from the classes (also all other FE should do that same) So which architect going for:

* A: if want to isolate FE and BE, eventually make them 2 separate projects then we shouldn't do this refactor.

* B: if want to keep them in one project then this is really good also we should make all page read directly from classes which even faster.

I'm not entirely sure I understand what we mean with isolate FE and BE, please explain so that I don't misunderstand what this discussion is about.

Since it was Henry who introduced the style of pages reading directly from classes, I asked him about his opinion and we had a long an interesting discussion about that on slack. I learned that Next recommends the style of pages reading directly from classes, but through an explicit data access layer: https://nextjs.org/blog/security-nextjs-server-components-actions.

Next also seems to favour server components for pages and they write some motivation for it here: https://nextjs.org/blog/security-nextjs-server-components-actions See also https://nextjs.org/blog/security-nextjs-server-components-actions

I have read quickly the NextJS link, according to them they classified project into

• HTTP APIs (recommended for existing large projects / orgs), this is option A in above
• Data Access Layer (recommended for new projects), this is option B (kind of)
• Component Level Data Access, more or less this our current situation

It seems that NextJS only recommnded option A (HTTP APIs) only if the project is already exists and big. I don't agree with that I think isolate FE and BE, (HTTP APIs) is better architect anyway, now imagine we add an App for iPhone or Android then they will need the HTTP eventually.

I think that we need to take an architect decision about this, I prefer option A I think it scale better.