#Contribution threads
1 messages · Page 1 of 1 (latest)
- Bundling buildkit. We want cloak to be a standalone binary
- “Dagger classic”. Cue SDK with europa compat. We have a design. Prototyping can start.
- New use cases. Do something real with cloak. Real world projects are best.
- Bash SDK. 🙏
- Adding core API buildkit bindings
- multi-platform.
- Go DX. Needs a lot of polish
👌
@woeful chasm ping
@junior swift ping
I'm going to take a swing at this. Will it be for the workflow or extension use case? /cc @mental oriole @violet lion
I would say we can start with workflow
@halcyon zephyr idk what a prototype would look like yet. Without giving it much though, probably what I would try is to port dagger on top of cloak:
- add a core.#Query or whatever task that uses cloak
- re-map all of core.#Ops on top of core.#Query
- Universe & all will automatically work on top of cloak
That's basically a "forward compat dagger" implementation, built on top of cloak, no buildkit required
And I guess if we add codegen support for CUE, you could "auto-gen" the "bindings" for cloak native extensions (e.g. it would generate a netlify.#Deploy built on top of core.#Query, calling the native netlify extension)
This sounds good. I like the core.#Query idea. I'll look into that!
Exactly what @mental oriole said. It's not even a SDK really. More like a custom tool on the side (dagger-classic) built with the cloak Go SDK
Yeah, it's like a "cue tool" but with cloak
Taking the opportunity to add the notes that @junior swift shared with me:
- Dogfooding work [Most important]
- Go / Typescript SDK DX
- Any getting started PR (onboarding docs as we ramp-up)
Are they complementary to the ones you specified, Solomon ? What would be the global priority / and complexity over all of contribution streams ? [yours + these ones, if still relevant]
Also, just to be sure, isn't 1. already halfway ? https://github.com/dagger/cloak/pull/110
Totally this. 🙂
@halcyon zephyr Have an issue for this here: https://github.com/dagger/cloak/issues/122
It's currently called CUE SDK, but feel free to rename it however makes sense based on the approach discussed above
(Also going through the rest of the issues, will link to ones mentioned here or create new ones)
Gonna list some more issues and add some more context to Solomon's suggestions:
-
For the Go DX, there's a lot of improvements to be made, but this issue is probably the route that will get us the most bang-for-our-buck: https://github.com/dagger/cloak/issues/142
It's not incredibly straightforward or quick as it potentially involves us switching to our own codegen tool, but will address the worst parts of the Go DX today, so it's extremely important. -
Bundling Buildkit is extremely important, but part of the overall change we need to make to switch to a client/server model. I added a high-level sketch of what we're imagining in this comment, but please reach out if you pick this up as it requires more design: https://github.com/dagger/cloak/issues/47#issuecomment-1208324918
-
Multi-platform is also important get right early on (so we don't end up where we did with it in Europa). We have not discussed it very much yet, so pretty much as ambiguous as it gets right now. I have some initial thoughts on it here, but don't take any of it as anything more than vague suggestions: https://github.com/dagger/cloak/issues/45#issuecomment-1232191467
-
One gap right now is that TS doesn't really have any fully automatic codegen. You can run
cloak generatebut all it does is output schema+operation files to thegen/dir. Any codegen after that consists of manual steps. It's less of a priority than Go because TS isn't super boilerplatey, but still important for extensions as it can become tedious to replicate your schema's types betweenschema.graphqland your actual code. See this comment for some details: https://github.com/dagger/cloak/issues/27#issuecomment-1232219092 -
Another pretty important one, related to the core graphql engine and thus needs coordination so we don't get tons of conflicts, but could be plausibly investigated in parallel: https://github.com/dagger/cloak/issues/36
-
Cache config: https://github.com/dagger/cloak/issues/46#issue-1330608115/
Also, while those are all big+important+ambiguous issues, here's a few smaller+simpler issues to get started with:
- https://github.com/dagger/cloak/issues/129
- https://github.com/dagger/cloak/issues/138
- https://github.com/dagger/cloak/issues/111
I'll make more of these as I think of them and add a label for them if we don't have one already
Also, made a discussion for use case ideas: https://github.com/dagger/cloak/discussions/143
Gonna go dump a bunch that have been building up in my head for a while. Feel free to add more there or take ideas if they interest you.
Concerning codegen for Go. Isn't it something we could fix with generics in a way?
Not that I don't like codegen completely, but it becomes out of date, you need to keep in sync in your git repo, etc. If we can have a nice generics API, maybe we could skip it completely?
Talked about this live, but to recap for others interested, yeah I think the first priority will always be the end DX for users, but a second priority is our own maintenance burden of the codegen tools. If generics get us a good DX and also reduce the amount of custom codegen we need to do, that would be great.
I think another path worth considering is switching to code-first schemas, which flips the problem from code-generation to schema-generation. Could turn out to be better for users and easier for us, but not sure until we try
I rather like the idea of code-first schemas, if it can work nicely. Here's hoping it does. 🙂
Also note that there are 2 parts to the DX:
- writing scripts
- writing extensions
Both are important, but the DX for writing scripts is more urgent if you find yourself having to prioritize
(because writing scripts is the first thing you do when adopting cloak)
@abstract crystal @woeful chasm