Roadmap for 1.0

[milessabin]

• [x] Rename master to main (#130)
• [x] Get rid of NoType (#129)
• [x] ~~Switch from NullableType to NonNullType~~ (#33)
• [x] Unify fields and attributes
• [x] Move to CE3 (#131)
• [x] Cross build for Scala 3 (#104)
• [x] Rework SQL compiler (#120)
• [x] Initial subscriptions implementation (#133)
• [x] Factor out doobie/skunk tests (#198)
• [x] Set up Scala Steward (#195)
• [x] Investigate alternative to List as result type of Cursor#asList (#204)
• [x] ~~Investigate eliminating circe from core~~ (#203)
• [x] Rename doobie module to reflect that it's Postgres-specific (#197)
• [x] Remove GroupList from the query algebra (#237)
• [x] Ensure no internal errors leak out through the GraphQL error channel (#199)
• [x] Review use of sys.error and assert in the sql module (#200)
• [x] Source file naming and definition partitioning (#192)
• [x] Cross-build for Scala.js and Scala Native (#202)
• [x] Update doc site and demo (#194)
• [x] Move to Typelevel (#193)
• [x] Change license to Apache 2 (#196)
• [x] Move to sbt-typelevel-site (#419)

[tpolecat]

I think we probably need to get the doc site back in shape as well.

[tpolecat]

Also need to implement subscriptions (in progress).

[milessabin]

~~I'm about to land a second rewrite of the SQL compiler~~. Now landed.

[armanbilge]

Low-priority, but it would be cool to cross-build for Scala.js as well. It should be easy since all your dependencies are already on Scala.js with identical APIs, except for doobie. However, the tests would be hampered by the testcontainers dependency.

Tangential, but IMHO a library cannot really 1.0.0 in the bincompat sense while it has dependencies that themselves have not 1.0.0-ed (in this case, circe, skunk, etc.). The reason is a breaking version bump in one of those dependencies would force a breaking version bump in your library, so you can only be as binary-stable as your least-stable dependency.

[milessabin]

Cross-building for Scala.js makes sense ... I'll add it to the list.

Point taken about unstable dependencies. The core module doesn't have any unstable dependencies, so maybe we declare 1.0.0 for core, and have the circe/doobie/skunk module versions track the corresponding upstream versions?

[armanbilge]

Huh, core also seems to depend on circe, as well as cats-parse.

https://github.com/gemini-hlsw/gsp-graphql/blob/79f2b1cc9e2f541b203d2902014f173bfaa5447a/build.sbt#L84-L100

[milessabin]

Hmm ... that could probably be eliminated. It's only used internally, mainly to generate result Json, and it's probably not the most efficient way of doing that, so a faster, stable, alternative might be a better option.

[milessabin]

@armanbilge added a couple of issues to reflect your comments: #202, #203.

[milessabin]

@armanbilge I think we have to stick with cats-parse. I think on balance I'd be happy to bump Grackle's major version number if we need to update cats-parse before it reaches 1.0.0.

[jf-botto]

Hi, I'm always looking for open source things to work on and I'd like to help out. Would anyone mind if I worked on #197 or #199? I'm more than happy to look at any other small/self contained issues that might be more useful/appropriate.

[milessabin]

@jbotto94 sorry, I missed your message earlier. Both #197 and #199 are real chores and a bit fiddly ... I wouldn't want to inflict them on you. How about #237? It involves digging around in the query algebra and the various places it's used ... I think it'll be a lot more interesting and give more insight into how Grackle hangs together.

[jf-botto]

@jbotto94 sorry, I missed your message earlier. Both #197 and #199 are real chores and a bit fiddly ... I wouldn't want to inflict them on you. How about #237? It involves digging around in the query algebra and the various places it's used ... I think it'll be a lot more interesting and give more insight into how Grackle hangs together.

Sure :). Wasn't sure if you had started working on it or not.

[armanbilge]

@milessabin here's another one to add to the list: you should probably replace the log4cats-slf4j dependency with just log4cats-core and ask for a LoggerFactory constraint. Users can then import an implicit Slf4jLoggerFactory to satisfy it.

https://github.com/gemini-hlsw/gsp-graphql/blob/6d4223acc817de01c13e32e75091d6f6712835f3/build.sbt#L125

A few motivating reasons:

1. slf4j recently released a 2.0 and the implications are not yet clear. Dodging the dependency altogether is a good strategy.
2. There maybe be other log4cats backends in the near future, such as otel4s.
3. slf4j is not available for Scala.js or Scala Native. Depending on it will force that code to be split when we cross-compile.

[milessabin]

@armanbilge I think log4cats-slf4j should only be a test dependency.

[milessabin]

@armanbilge apropos SLF4J, see #404.

[milessabin]

We're pretty much done! :tada:

I do want to get #258 in as well though.