Nrwl uses Cypress's built-in Typescript compiler, but has issues when we try to import library code. Since it needs to parse other code such as ESM modules.
We tried to use Cypress preprocessor, but it gets stuck compiling when using our own Webpack configuration.
In the end, we decided it's easier to just import relative path without project references.
UPDATE 10.02.22
Issue was that Cypress doesn't process any files, so we can only import ts code. We ended up using an ESLint rule to process imports for type checking.
GraphQL Recursion
GraphQL has a limitation where we can’t have recursive relationships. Instead we would have to flatten the data structure. Say we have a tree structure of node’s that we have fetched from our graph database, and we want to transfer that to our frontend via GraphQL; We will have to parse it into a graph representation of nodes & links.
A graph root model will contain a list of nodes, and a list of links denoting the connecting between nodes. This flat data structure is more congruent with how GraphQL works, so we can transfer the information to the frontend. At the frontend, we may re-hydrate the data back into a tree structure to be used by React.
Service Level Guards
Nest.js guards act on the level of route handlers, so GraphQL resolvers. When we call specific services, we want to make sure our data is validated, so we can’t use guards. Instead, we have our own system of data validation within each service.
The guards are needed because of Dgraph’s inherent shortfall in guarding against unauthorized access. DQL query itself has no built in authorization. The Dgraph GraphQL endpoint does have @auth, but has some edge cases that can’t be handled.
Renderer
We currently have to render bottom up, because the inner most children needs to be built first before passing it into the parent component.
But by doing this, we lose the ability to use Context Providers.
We shouldn’t use <></> syntax for the renderer as it adds an extra fragment, and could break some components such as menu.
Context Mapping
DQL query results are not type-checked, so when transforming to GraphQL models, we’ll need some sort of validation layer.
Interface Types
We’ve tried sharing frontend and backend types, but it doesn’t work that well. For backend, we’re trying out newly generated interfaces from GraphQL types. Frontend we end up creating our own interfaces, since they require __typename (so we can’t use backend types, could use util but nested merge is difficult, could also add __typename to GraphQL models but is hacky)