v0.3.0

[lastmjs]

• Do a basic fill-out of The Sudograph Book
• Paging, filtering, ordering, at all levels including in selection sets
  • Change all documentation to search instead of input on read
  • Top level paging
    • Just have a top level limit and offset thing
  • Top level ordering
    • Just add an order input object, which will have the scalars of the object
    • For now, throw an error if there is more than one field defined
  • All level filtering
  • All level paging
  • All level ordering
• Fix random value generation, just store the random value once when the canister is created
• Client TypeScript type generation?
• Start writing tests and fixing bugs
• v0.3.0 should be the battle-hardened version
• Show how to generate automatic types from the schema for the front-end, and perhaps get the query generator thing up on npm, or integrated into the GraphQL community somehow
• Do not require an empty input
• Integrate the ic_cdk_optimizer, because large builds will not work
• Document the optimization flow, if the Rust binary gets too large it gets a little messy, best way so far seems to be to just use npm scripts
• We need to allow the user to turn off the generated query and mutation canister methods, right now there is no way to not expose them (important for authorization)
• We need to allow the playground to set the query and mutation methods, just like the sudograph client itself
  • testing this now
• Start using &str for all string function arguments, only use String when necessary
• Use a hashmap to store relation primary keys instead of a vector...deeply consider which will be more performant
• Allow for custom scalars
  • Is this really necessary? For now perhaps I should just allow you to create the name of a custom scalar, but it will be stored as a string
  • A JSON custom scalar would be nice to have, if it actually returns as JSON...
  • a BYTES scalar that is actually stored as bytes in sudodb would be nice as well
• Allow for custom resolvers
  • Really this just needs to be documented
• Allow for resolvers in other canisters
  • This should already be possible, but we want to allow it through the schema only if possible
• What if the user wants to compose with our custom init and post_upgrade functions? Ooh...maybe we could call there's somehow?
• Figure out how to interop with Motoko
• Go through all errors and make sure they are nice
• Get aliases to work: [BUG] Alias paths above cwd not honored FredKSchott/snowpack#3127
• Make all documentation amazing
• Start making videos
• Should the basic and intermediate and other examples update automatically???
• Potentially build out the intermediate example as well
• I'm thinking each example might want to point out different capabilities
• The basic example can just be what is generated with npx sudograph...the intermediate example perhaps shows Motoko interop, custom resolvers, custom scalars, etc...or maybe the intermediate example can be the Ethereum archival node...and the advanced example could have as many custom options as possible...or each example could just be focused on one new feature in particular
• Custom scalars
• Should we add a JSON scalar? Look into how that should operate
• Allow for enums, inputs, all of those custom things...if the user defines them, I think I'll just map them one-to-one into async_graphql structs
• I found something that is broken...if you have a relation referring to yourself, the relation won't be found properly...in fact, I think we might need to allow having multiple @relation(name) tags with the same name, it just means that they all need to be updated. This would make the family tree example work perfectly I believe. Consider the family tree example
  • Allowing multiple @relation(name) things per field would help to solve the family tree issue
• Change all readinput names to readsearchinput or something like that
• Create input should also be optional I think
• I think we should have a top-level Sudograph store that houses the main object store, the raw rand store, and anything else that might need to be stored. This will help people perform migrations and such
• Watch out for serde json default behavior issues, I changed up the default stuff on the object type and I am not sure that it's working
• Walk through all panics, make sure everything is a result up to the top level...really ensure that transactions will work properly
• We are probably going to need some reserved keywords for field names, like the search operations eq, lt, startsWith, etc...I think this will be necessary because of the searching from within selection sets on relations...actually, if we use the object_type_names to determine whether or not a field is a relation we should be good
• Update the ethereum archival canister, add authorization, then get it running live with the last 10,000 or 100,000 blocks or something...this will be really cool
• Document how to go fully custom with async_graphql if the user really wants to
• We should allow creating custom input types, otherwise the custom resolvers can only use scalar inputs...which I think is okay for now, but people will probably want them later
• make sure all examples have their package.json and Cargo.toml sudograph versions updated when publishing
• Change the order of the example canisters so that the canister ids are always consistent: graphql canister first, then playground, then the other canisters
• It would be nice to solve the candid/ic_cdk crate import issue...I am trying to get it to work from a forked GitHub repo first, then I need to look into macro attributes I believe to come up with something like #[candid(crate="self")]
  • I think I have to figure out the macro attributes, otherwise CandidType is breaking in other contexts
• The bytes custom scalar might should be something like https://sdk.dfinity.org/docs/candid-guide/candid-types.html#type-blob
• The generator and examples need to be updated appropriately, and canister-id needs to be fixed in the generator for the new version of the client
• npx sudograph is grabbing the latest beta release, which is bad
• add canister-id-local and canister-id-ic to the playground
• Make sure all examples update when publishing a new version
• Do not allow the npx sudograph command to use beta versions!!!
• This issue seems closest to my npx problems: [BUG] npx does not attempt to get newer versions npm/cli#2329
• seems like deletion needs some cleaning up...should deletion cascade by default?
• delete all old branches
• documentation
  • blob scalar
  • json scalar
  • all query capabilities, limit, offset, search, order
  • custom resolvers in rust and motoko
  • sudograph settings
  • Document how to go fully custom with async_graphql if the user really wants to
  • Document migrations, or at least how to persist your state
    • Try this out with files, see if you can get the state to stay
  • Start making videos
  • document the init functions
  • test out custom resolvers in another rust crate
  • Create rust and motoko client canisters, along with a rust custom resolver canister...fill in the documentation
  • I really need to show in the authorization section how to do Motoko authorization and how to do Rust authorization from the same canister and from another canister. Fill out the motoko-client and rust-client examples to figure this out. This should be the last piece to the puzzle, unfortunately I don't think many queries and mutations will be happening from the frontend directly, but from Motoko and Rust canisters directly will probably be the most common way people will perform them
  • document authorization
  • document enums