v0.4.0

[lastmjs]

This might be the version that has an initial test suite

• Create the initial test suite, then immediately fix the known bugs

  • Deletion needs to delete the other side of the relation
  • Self-referencing relations need to be fixed, look at the family tree example, I think we need to allow for adding multiple relations to one field

• Test suite

• Integrate the ic_cdk_optimizer, because large builds will not work

• 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

• Client TypeScript type generation?

• Start writing tests and fixing bugs

• 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

• Go through all errors and make sure they are nice

• Get aliases to work: [BUG] Alias paths above cwd not honored FredKSchott/snowpack#3127

• Walk through all panics, make sure everything is a result up to the top level...really ensure that transactions will work properly

• Custom scalars?

• Allow renaming the generated functions

• Add type checking to sudo settings, do not allow the user to input values that are spelled incorrectly

• Figure out how to not force the consumer of Sudograph to depend directly on ic_cdk. This issue will need to be resolved unless I can figure something else out: As a library developer, I want to have candid_path rethought so that consumers of my library do not need to depend on ic_cdk directly dfinity/candid#248

• Study hygiene, really look into Sudograph imports and ensure they will be very modular

• We should probably change the names of the generated functions, they are very common and are what consumers of sudograph would want to use. We should be able to use the cdk-rs name attribute to fix this

• Remember to move off of my custom fork of ic-cdk and candid, once this issue is resolved: As a library developer, I want to have candid_path rethought so that consumers of my library do not need to depend on ic_cdk directly dfinity/candid#248, and here is the pull request: add candid_type helper attribute dfinity/candid#249

• custom inputs

• When deleting, we need to go delete the other side of relations as well...otherwise the data will be corrupted

• Change all readinput names to readsearchinput or something like that

• 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

• 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

• Allow for custom resolver fields, right now you can only add top-level custom resolvers, but fields must only resolve from the database...this would be nice for easily allowing storing audio, video, images, and bytes in something like BigMap, but still have them resolvable from a Sudograph field very easily

• Add logging to SudographSettings type...that is going to be amazing

• Figure out how to use environment variables or something for the schema...we need to store separate settings for separate environments, like canister ids

• Look into passing slices instead of Vectors

• Consider removing the JSON custom scalar

• Consider supporting scalar lists and operations on those lists, such as offset and limit

• Figure out some sort of environment variable thing for Rust, I only want authentication in production not in development

• Bulk delete by multiple ids would be nice

• 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

• seems like deletion needs some cleaning up...should deletion cascade by default?...if you delete one side of the relation, the other side needs to be deleted as well

• Change the order of the example canisters so that the canister ids are always consistent: graphql canister first, then playground, then the other canisters

• add an option to write the generated schema to disc on compilation...this will be useful for integrating with static analysis tools and such

• use traits and stuff to greatly simplify fieldvaluestore, fieldscalar, all of that stuff...all of the serialization and such

• consider automatically keeping the state...if the user can just use dfx install graphql then that could be the easy way of allowing them to start from a clean slate

• Start making videos

• Consider what is required to become Relay-compatible

  • interfaces in schema
  • input object types in schema
  • field-level custom resolvers in schema
  • ignoring entire object types and individual fields
  • None of the above I imagine would be too difficult, and I believe it could all be done in Rust without Sudograph's help if required

• Note that if you are using the Rust CDK to develop Rust canisters, it is encouraged to use the Candid crate from ic_cdk::export::candid to avoid version mismatch.

  • I might want to start doing this, I think i have run into the version mismatch problem
  • Custom resolvers across canisters won't be possible again until we reenable CandidType...see here: https://forum.dfinity.org/t/derive-candidtype-with-serde-json/5800/2
    • I've decided to simply remove the candid stuff for now, considering that custom resolvers won't really be useful if authorization is required anyway. You should build custom functions in Rust or Motoko that call into the Sudograph canister. That will allow you to put authorization in at the function level. You will receive a JSON string back, and you will need to figure out how to deserialize it appropriately

• We should redo a lot of the GraphQL utilities with traits, so we can just call methods on fields and stuff. The biggest problem is pasing around the graphql_ast, it would be nice to somehow be able to store it somewhere globally accessible or something

• The Sudograph Client should have main point to a non-es-module build...because Webpack is still in the past

• explain in the documentation the intricacies of ands and ors. Each or is anded with its own level. The only thing or'd is the fields at the next level. Within those levels the fields are anded