Roadmap

[IvanGoncharov]

A lot of stuff is overdue on this project.
But as first priority I want to take steps that simplify the maintainer job and allow to develop new features faster:

• Update deps
• Improved build demo/release scripts
• Publish demo with CI
• strict: true in tsconfig.json
• ESLint + pluggings
• Remove lodash
• Use GraphQLSchema instead of custom JSON based schema https://github.com/IvanGoncharov/graphql-voyager/blob/master/src/introspection/introspection.ts
• Inline CSS in JS

[LunaticMuch]

I also propose a simplified version of the demo with a single html file that loads a schema from an internet endpoint using voyager as a library.
The current demo was fantastic for showing library feature, but also causing the repo code to be a bit messy. It would be easier to split the whole big demo into a separate repo which serves a demo website, if needed, and just maintain the library core repo as library only.

[LunaticMuch]

My PR #228 also include this demo

[IvanGoncharov]

I also propose a simplified version of the demo with a single html file that loads a schema from an internet endpoint using voyager as a library.

@LunaticMuch My main concern is how hard it would be to develop locally.
Currently, I just run npm start to do a code change and immediately see the result in a demo.
Don't see how I can easily test code changes without it.

[LunaticMuch]

True, but would not a small express server doing the same in a much easier way? Today demo is a complex package, because allows for several options, it's in the between a stable demo website (what used to be) and a local sandbox.
I think the website, whether can keep having it, it should be a completely different package.
For the sandbox, it can be an express running a simple graphql server based on a demo schema file.
This would not require a big demo folder with all the options that you give out on the website.

[IvanGoncharov]

@LunaticMuch By demo being complex do you mean "Change Schema" functionality?

We have a lot of traffic for "demo" (> 3k unique visitors/month) so I want to continue to work on it and add more features.

It would be hard to maintain a separate repo (hard to test changes, doubling release and other maintenance work, etc.)
If we use the latest voyager in the demo (without a fixed version) it would be frequently broken.
If the voyager version needs to be updated manually (after testing) it will add a lot of maintenance burden.

Thinking about it, we can move a few "demo" components under src.
And just have two components GraphQLVoyager and GraphQLVoyagerApp.
Also, we can provide two separate bundles so the bundle size will stay the same.
Or considering the current size of the viz.js blob slightly increased bundle size after the "demo" component update is not a real issue and we shouldn't bother with separate bundles.
What do you think?

[LunaticMuch]

It is a good proposal. But let me rephrase some of my sentences 😄

I am not suggesting to remove the demo and scrap the website. There's a massive value with that.
I am suggesting to split this monorepo into two repos: one repo is the library, the other is the website.

The library should be just the library, with the goal to visualize a graphql schema; this should be testable without making various tests using the demo.
The demo should be a website, as today, where you can switch schema using a modal and selecting options.

The two components you are proposing are anyway a good point of next.

[joeponzio]

I'd like to make a few suggestions and also help out:

• Switch to functional React components
• For ESlint, choose a specific rule set (AirBNB?)
• Add Jest or other test suite
• Compile with SWC
• Add Joi for prop validation and error handling

Remove lodash

I'd argue against removing lodash only because it's so lightweight and convenient when importing specific modules instead of the entire library. But that's personal preference :)

I think with some architecture changes and package.json script updates, we wouldn't need to move the demo and website out, but I also see the merits in separating them.

[LunaticMuch]

@joeponzio I see the value in changing the approach to react.

@IvanGoncharov I can probably take the ESlint as next. The ruleset is generally something ending into long (and useless IMO) debates. I would agree with AirBNB

[deathemperor]

Speeding up would be welcomed too. My schema taks Rendering Graph: 36624.31005859375 ms to load

[IvanGoncharov]

Speeding up would be welcomed too. My schema taks Rendering Graph: 36624.31005859375 ms to load

@deathemperor I switched to the WASM build of GraphViz in v1.0.0, so it should significantly improve performance.