Laminas-api-tools/api-tools-admin-ui should be written in Angular 8

See https://github.com/laminas-api-tools/api-tools-admin-ui/issues/16

Maintaining an application written in AngularJS is a technical debt I’m not keen to contribute to. I suggest a new admin module written in Angular 8.

Further reading: this is a popular set of documentation I created recently on the subject of Angular project structure: https://angular-folder-structure.readthedocs.io/en/latest/ #contributors

1 Like

As far as I know, this project (Laminas API Tools) will be deprecated at some point, so there is no need to invest time in maintaining it. Moreover I would argue that React is a more suitable solution for the task, as it is more lightweight and it is a library, not a full-blown framework and its usage world-wide is wider.

About the deprecation, is there a plan to replace the project with something else?
It is a lot of work. If it will be deprecated, I agree there is no need to upgrade it, but I do not see a proper replacement for the functionalities we have here. Where can we find more information about?

Regarding Angular/React, this is a big decision: we start and we can’t go back. I can work with both. But if we choose React we must decide about things like using or not Typescript. @TomHAnderson what do you think about React?

React is for script guys. These are grown up script kiddies.

I think you must look at React vs Angular in the context of this framework. The homolog to Laminas MVC in JS is Angular because it too is a full featured framework.

I made the choice some time ago to work in Angular. I was stepping up to this like I’ll do it so I’d like to know, thexpand, is that what you are proposing, that with your suggestion you’re willing to take the wheel?

@TomHAnderson I believe you are being too simplistic, but I got your point. :slight_smile:

My today’s opinion is that we should choose the technology we have people to work on, otherwise we will lose precious time. I do not know who has the power to decide on such topics in this project, so if you want more on my opinion about it:

  • if we chose Angular, we have everything ready in the framework + TypeScript. Yes, it is heavier and the compilation in development is (slightly) slower. We have trade-offs. And I do not believe that this will be a problem for us.

  • if we get React, we must care about additional libraries (Redux, RxJs, Prop-types…) and setups (should we use TypeScript?). It is lightweight and allow us to create a few different setups depending on the set of extensions used.

Of course there are more points, but both projects are well maintained and the Admin UI is not so big: we just need a nice UI to the project. In this specific project, I believe the only thing that matters is if we have or not developers interested in working in the project with a specific choice. If we had more active developers and a larger community, I might think differently.

Is the migration a good thing? Yes! I myself was waiting to propose something after the transition to Laminas, but the comment from @thexpand about deprecate the project made me take a step back: if we will deprecate everything it is better to maintain what we have now. I want to hear more about it.

I’d advocate for Angular + Material. It’s heavier than React, but comes with everything needed including the test frameworks (Karma for Unit and Protractor for e2e tests).
With React you’ll have to build a lot on your own.

JavaScript without TypeScript is savage. This should be avioded by any means, imho.

IIRC there were plans for basing the API Tools on Mezzio, not sure if this is still up.

Thanks for the info, tux-rampage. If that is true, my first impression is that we should start there, otherwise we will have a big refactoring to do later. TomHAnderson, what do you think?

Who is the person to confirm the information? @matthew? @webimpress, could you point someone to comment on the topic?

The reason I’ve advocated for React is for a few reasons:

  • Large community of users (which means we’ll more than likely have folks within our own community familiar with it)
  • Longevity of the project (it’s been around a long while, and, because Facebook literally depends on it for their own apps, it’s not going anywhere. Google, on the other hand, has a long record of abandoning projects)
  • Most recent versions support typescript (which I also agree is a must-have here)

Now, all that said: my current idea is to use OpenAPI for describing the API you want to build, and then passing the spec you generate to a CLI tool to generate code. There are already a variety of GUIs for developing OpenAPI specs, and many of them are extensible (i.e., allow you to provide things like macros for common “sets” of endpoints, etc.). I’d argue we’d have better luck maintaining something like this than our own GUI.

Wouldn’t it be a better option to do it on mezzio(backend) and angular (frontend) ?

laminas-api-tools specifically targets the Laminas MVC; this question is about the future of that particular effort, which is still in the air. I’ve outlined what I think we should do for that project should we continue to evolve it.

Regarding Mezzio, we’ve been discussing the idea of having a middleware-based offering for APIs for some time, and most of the components necessary are now in Mezzio. The next logical step to that is tooling for generation of endpoints, and this would likely target usage with OpenAPI. The question is going to be whether or not the steering committee wants to support both offerings.

My two cents go for Angular and Material to have as many things as possible out of the box.

Also I don’t see Google abandoning Angular anytime soon because:

Angular is used in public-facing applications and sites such as Google Cloud Platform and AdWords, as well as many internal tools.

According to https://opensource.google/projects/angular

I’m more wondering if maintaining a GUI is worth it.

While it’s very sexy for newcomers, and definitely played a huge part in my decision to use it, it has some limitations that forces you to manually edit the config for less common cases. After a while I noticed I use the GUI only for the first generation of a new service, and then end up refining the config manually. So for me a CLI generator might be enough.

And since I’m making a wishlist, I’d love not to work with one gigantic config file, but instead split them by services or by component.

I defend the React.
The main reason is that by choosing a library that focuses on MVC’s “V” only, we can intuitively pass the most processing backend and handle the Laminas themselves, strengthening the framework.

React is already mature enough to work without an absurd amount of additional third party libraries, it is possible to go React + Material basically with the React 16.12+ native API

Maybe what a PHP programmer wants is just a powerful template engine for their APIs / Graphqls, not a new framework for handling logic that may come clean for use.

Or thinking deeper, even an Next.js, the React Framework, if the key is standardization.

Opting for React, in my opinion could gain more popularity.

It would be the perfect marriage. It would encourage more users to contribute admin with the same language as programming their frontend to their clients.

Actually it does not matter if Angular or React. Both are good frameworks (with different focus), well maintained, broadly used and have their strengths and weaknesses. It’s just a matter of taste.

Personally I think Matthew’s idea is the better approach than re-inventing the wheel and maintaining a full code-gen (or worse code-edit) frontend:

This may also make it more clear, that the API Tools are better for starting a skeleton and dealing with the message handling boilerplate of your API than actively editing it. All Apigility based projects that I had to deal with were complete failures and unmaintainable monsters because the original implementers of these projects thought it would be enough to compose click the api and some plugins, put all the complex business logic directly into the controller and omit QA entirely. That’s how you prototype and throw away, but not how you build a reliable product. Especially for junior devs (when not properly mentored) RAD is an awful pattern. Giving them an ui to edit the code on the fly makes the problem even worse, imho.