Improved developer experience for building an API for a JS framework frontend

Yii 3.0 Design discussions
1

For a new project, I took the leap from traditional application development in PHP (with Yii2 of course), to API-driven development with the API built in PHP with Yii2 and the front-end build in JavaScript with NuxtJS (Vue.JS framework). In light of Yii3 developments and discussions with @machour , I wanted to share my experiences and thoughts given that this is increasingly a mainstream design pattern and Yii should aspire to be the leading framework for developing that API/back-end.

So here are my main gripes / opportunities for improvement when it comes to Yii2, that I believe should be addressed now and/or in Yii3:

  1. GII has a CRUD generator for web pages, but doesn’t have a generator for an API front-end. Can only use it to generate the models and web controllers, not REST ActiveControllers.

  2. GII model generator should have an “add linkable” option to automatically include HATEOS code.

  3. A GII generated code for ActiveController should contain the CRUD actions, but commented out, to give users a jump-start overruling/extending default actions.

  4. GII generation of [Model]Search.php is part of CRUD in stead of the model generator, which does not make sense because you want it for search queries on actionIndex(), which is kind of a frequent requirement.

  5. A GII generator for ActiveController and Model should contain the code to support Search by default. A solution for formName that works both with REST and web would also be preferable (see this solution).

  6. As a developer I find the authentication-behavior-must-be-added-after-CORS-behavior issue ridiculously annoying. How hard is it to do an in_array() check in the Yii core code and fix this “under the hood” when loading the behaviors?

  7. Core support for GraphQL just like REST is necessary for development of a good API-driven back-end for a pure JavaScript front-end. Many queries are far more efficient with GraphQL than with REST, so it makes sense for a developer to use both. Hence, Yii3 should support both. I know there is an extension for yii2 but I would prefer this moved to core for yii3.

  8. Being able to kick-start Angular/React/Vue applications using Yii’s built-in generator would be a huge Unique Selling Point that would probably attract a lot of attention and developers. Perhaps GII extensions are feasible to auto-generate Gatsby/Next/Nuxt/etc. CRUD JavaScript/TypeScript code in addition to the Yii REST code?

10 Likes
2

Bewildering, isn’t it, but Gii could be adapted to make it more extensible. There are always going to be new frontend APIs and other libraries arriving as time goes by. The existing method of adding new generators works well but why not take it a step further. Why not make Gii a bit more versatile from a configuration standpoint. What would happen if Gii owned its own database. Maybe something simple and lightweight based on SQLlite. This opens the door to controlling which generators appear on the Gii opening screen, possibly piping a series of generators in a process-like sequence, and all sorts of Gii configuration options not possible today. One could enable or disable the generators you want to use to control what appeared on the opening Gii screen.

Consider behaviors and traits for example. Would it not be a nice and time saving feature to automatically include a set of developer-defined behaviors and traits during the CRUD generation cycle. There could be multiple sets of these defined for different types of MVC triads. A way of registering behaviors and traits in the database would be required but this could be done using a migration-like registration cycle and a framework-owned gii-db connection.

It’s possible, but no too developers usually think alike unless they have been working together for a long time. Why not take a step back and look at Gii from the standpoint of making it more adaptable to developer or development team needs and wants. Much of what you want becomes possible at that point. For example, controlling the loading sequence of behaviors based on known conflicts, loading the generator for a specific frontend API, and the special requirements of any number of development teams.

4 Likes