Replies: 3 comments 3 replies
-
I would be interested in the feasibility of our backend (i.e. core) exposing a graphql endpoint directly. The above could then function as a intermediate stage. I'm assuming that would be a massive undertaking, but a standardized query language seems preferable to me over our current more idiosyncratic approach. We've put massive amounts of time into smoothing over api inconsistencies (d2, app-runtime), but it remains a game of whac-a-mole as long as the backend isn't involved in the standardization. The end goal to me would be a graphql endpoint in dhis2-core. |
Beta Was this translation helpful? Give feedback.
-
Agreed. Fundamentally exposing GraphQL from DHIS2 in addition to REST end-points is a large undertaking and it would need to be tackled in line with the long-term roadmap process. There are a few long (3+ years) running projects that are strategic, and needs focus before moving to the next thing. To get an idea of the relative scope of the high-level goals, I've listed a few items that are covered by the scope.
We can start lobbying for a GraphQL server in Core, but in the meantime we still need to get our work done. |
Beta Was this translation helpful? Give feedback.
-
|
The ideal is that App Runtime would be agnostic to REST / GraphQL so the If we talk to the server using REST today and GraphQL tomorrow, that should be an implementation detail that is absorbed into the App Platform. Developers that invest in the App Platform today, shouldn't have to worry about having to learn GraphQL to be able to be productive with it.
The mission is to build the technology that all DHIS2 developers can rely on; "for them, by us". That is how we scale from 50 apps to 500 apps for DHIS2, we cannot (and should not) do that ourselves, but we are in a position to empower others to do so. We should absolutely leverage technology developed "for us, not by us", but it should always be presented to DHIS2 developers in a way that makes it easier for them to work with DHIS2. If we use Apollo to serve that end, that is an internal consideration, not something that we promote in external APIs. The It doesn't matter to them if its GraphQL, REST, or whatever else in the future, we can make sure they get the data they have declared for them in an efficient way. In this regard, the babel-plugin (dhis2/app-platform#538) that converts GraphQL to GQL is not an abstraction on top of the
|
Beta Was this translation helpful? Give feedback.
-
|
I find this discussion interesting. I would like to convert the DHIS2 Core to Node.js that run with GraphQL. |
Beta Was this translation helpful? Give feedback.
-
Unfortunately this is impossible. The core is way to big and has a lot of customization for many different purposes, e.g. caching and performance optimizations, so that this would require a complete re-write. |
Beta Was this translation helpful? Give feedback.
-
|
I understand the bottleneck in this but I will attempt this as a project. Node.js + GraphQL will be a great solution to fetching data. |
Beta Was this translation helpful? Give feedback.
-
During our last team platform meeting (19. Oct 2021) we talked about generating a graphql schema from our own schema.
We were discussing the why and how and came to the conclusion that we should think about this as a team.
The reason why everyone was interested, at least to some extent, is:
Maybe we're faster getting to feature complete state if we combine our strengths and work on this together instead of implementing every piece ourselves in our own service. It'd reduce the complexity of our code base as well as the time we have to maintain our own products.
Participants of the discussion were: @ismay @Birkbjo @KaiVandivier @mediremi
Included in this discussion should be: @varl @amcgee @HendrikThePendric
Might be interesting to: @larshelge
Ideal case
If we were able to generate a gql schema from our schema, we could set up an intermediate gql server. The server itself implements dynamic resolvers which forward the incoming requests to the respective REST api endpoint.
This would have the following benefits:
@neo4j/graphqldoes.Current state
So far this has been a tiny pet project by me, I just wanted to know how far I could get.
I didn't get really far.. I started writing a script to create a graphql schema, which I then wanted to use to create an apollo server.
Quite quickly I figured out that our schema is incomplete, and some types are missing in the schema itself. You can read about my findings in TECH-778.
Before I started this little pet project, I already worked on a babel plugin that would allow us to use graphql instead of our standard query definition. Under the hood, it translates the graphql query to a standard app-runtime query. Although there's no final decision, I think this idea has been dropped. But the Jira issue and the PR still contain some relevant questions & answers as well as some remarks that could be relevant for the idea proposed above.
Possible solutions
External Node.js server
This would be the easiest way for both the frontend and backend team to add graphql functionality.
When I talked to @varl about this, he mentioned, that it's be quite an issue to force implementers to set up another service on their servers, next to the dhis2 core instance.
Internal graphql implementation re-using internal code
This is probably where all of us would like to get to.
It's probably also the solution that'd require the most amount of work.
Internal graphql implementation sending requests to itself
This might be a solution that works quite well. Instead of re-using internal code, the graphql-resolvers forward requests to the spring server. This way, no code needs to be refactored and no extra service needs to be set up. The apollo client (as well as other gql client libraries) are server agnostic, so this wouldn't stop us from using state of the art client libraries.
Let's talk about the endpoints
It seems that some endpoints, especially metadata endpoints, do not follow proper MVC standards and retrieving & processing data is mixed up with the server code that manages requests and responses. We would like to push the idea of refactoring endpoint by endpoint over a larger time span (similar to what we've planned with the maintenance app), moving towards a more service oriented architecture with less logic in the controllers.
By tackling one endpoint at a time, we will end up with proper code separation after some time (e.g. at version 2.42). Of course this iterative approach has its downsides as well, but we (some of the team platform's frontend devs) would like to propose the following workflow:
Our stance is that our current approach is mostly a short term strategy. We do not have the resources or time to tackle working on the endpoints. While this works for the time being, we're painting ourselves more and more into a corner.
We should be able to provide good arguments for why we need to spend some time one the endpoints and therefore defer adding features to that part of the code.
By following the iterative approach, the frontend team has managed to be able to be more consistent. This has allowed us to add a lot more features that we would've been able to if we didn't tackle this properly. The process hasn't been completed yet and we're already doing the iterative approach for almost two years, but from our perspective this has been more of a success story than a nuisance. On top of that, the app-platform has really helped us streamline our workflow, which is a huge advantage that we'd like to highlight as another reason why we think that working on this part of the code has far reaching benefits in the mid and long term.
We strongly advocate for adding some process that addresses the inconsistencies as well as the outdated and non-standard endpoint implementations as this would eventually benefit both the backend and the frontend team in the long run ans contribute to a more maintainable and stable dhis2-core as well. On top of that, it would pave the way for lowering the barrier 3rd parties to add their own extensions and micro services if there was a standard way of adding these and/or extending/hooking into existing endpoints.
Beta Was this translation helpful? Give feedback.
All reactions