JSON-HAL & GraphQL

[tasselchof]

Hello,

I have a question regarding JSON-HAL in the dot kernel. Have you attempted to implement the ability to select specific fields for the response? In Laminas / Mezzio, the default behavior allows setting the depth of rendering for _embedded entities, but there doesn't seem to be an option to provide an exact list of fields to be selected. We previously had a custom solution for the Laminas framework to handle this task, but I'm curious if you have considered implementing something similar?

Thanks.

[alexmerlin]

Hey @tasselchof,

Yes, we did consider implementing the ability to specify in the request a list of fields to be returned, it just never ranked high enough on our priority list so we kept pushing it further away on the roadmap.
If you need this feature, we can prioritize it for a near future relesae.

[tasselchof]

Hey @alexmerlin,

Thank you for your response. I've been considering how to achieve greater flexibility, and I believe that relying solely on JSON-HAL may not be sufficient for our needs. Instead, I'm exploring alternative tools like GraphQL, which can serve as a middleware solution. To implement this, I've integrated two libraries into our system: webonyx/graphql-php and ecodev/graphql-doctrine. Now, I'm in the process of combining them within the application to establish a GraphQL API. While these libraries simplify the process, they don't offer a complete solution.

I've noticed that DotKernel currently lacks a specific library for building GraphQL. Do you think it might be beneficial to develop one for such cases? Let me know your thoughts.

[arhimede]

We assembled only 4 different type of Applications(projects), based on Laminas and Mezzio libraries.
There is Frontend, Admin , API and an un-released Queue Management using Swoole and Redis
https://github.com/dotkernel/pingu

By design, Dotkernel API is only a REST API, we do not want to implement different responsabilities here. Definitely we do not intend to over complicate or add more complexity to the codebase.

If there will be a need for a GraphQL application, we will start building one. If you think you can contribute, we can fork in a new repo this REST API codebase, and start building the GraphQL version.

In production, we are using all this applications in a kind of Microkernel Architecture, in which for the same platform, we have a Frontend, Admin and an API , all sharing the same Core set of libraries.
Common entities and functionalities are extracted in separate repository , using git submodules.

More about that will have in few weeks, after we launch a separate website at https://www.dotkernel.org , directly related to Dotkernel API and Microkernel Architecture.

Dotkernel API is not a competitor of api-platform :-)

[arhimede]

Addition information here about what we want to achieve in the near future
https://github.com/laminas/technical-steering-committee/blob/main/meetings/minutes/2023-04-03-TSC-Minutes.md

[tasselchof]

We definitely can contribute (and right now it's the best moment to decide that you need those contribution). Our product is a warehouse management system and we decided to move to mezzio for newest version of our customer portal (we were using mainly Laminas and all our APIs are REST). This is how I found dotKernel - you have a lot of nice components that are making life easier on the start.

Our platform is divided on the backend and frontend which is not "classics" frontend but admin panel. Also we have fully separated frontend for customers which is build on vue.js and quasar. And this is the point where problem is coming from. In the newest version we want to drop "classic" admin panel and only to have vue.js app. But sometimes to make a requests from such an application to the backend is very complex (for example we need 2 requests to create sender and his address). Fetching data is also very complex (sometimes). This is why we are came to the conclusion that we need something more then rest API. There are 2 poplar options (JSON:API which is kind-a close to HAL and GraphQL).

I am providing some context to understand what we can do and what contributions we can do =)

[arhimede]

ok, we will digg in the next days into this idea, what's the easiest path to add GraphQL.