I have a need for a Node version of this library...

[mphuff]

How open would the community here be to something like the following:

• otf-api library - base library, remains source of truth
• otf-api-model library - shared library based on openapi, allows for cross-compiling of different library implementations against same model
• otf-api-ts library - typescript version of this implementation of otf-api but compatible with my node backend

Using Claude, I've cross-created this codebase and am validating it in my underlying implementation but curious if others have appetite for this or whether I just keep this internal to my codebase.

My thought (and Claude agreed with me FWIW :) ) is that perhaps as CR's are pushed into this otf-api library, I could monitor for the changes and agentic-ly ingest them to the ts library (and model where necessary). I would run tests and if they pass auto-ingest and commit; otherwise it would require a manual review.

Longer-term we could have otf-api-model be the shared source of truth but I'm just looking to make my app stack a bit cleaner to manage and having typescript front-and-center is a big part of that.

[NodeJSmith]

I'm totally down to do something like this, just trying to think through the best design. Since we're using pydantic we can easily export the models to a json schema / openapi. Talking to chatgpt, I think it'd be easy enough to layer on some metadata to my api classes/methods and then introspect that and generate openapi specs for the endpoints.

With both of those it'd be easy enough to export a spec for the whole thing, but I'm not sure what that gives you on the typescript side. Can you use swagger to generate a typescript client and models?

I'm not sure about having a separate library for the models - I'm not opposed but I'm not sure how useful it'd be on its own, since the endpoints are just as/more important than the models.

Thinking through this more, there is a translation layer than I'm not sure how we'd handle. Things like creating the Workout model are kind of gross and couldn't be put into a spec. Thoughts on that part?

[mphuff]

This is my first crack at it but all of the api tests I integrate with thus far seem to work with the code. I'm not going to take it fully at face value quite yet but have a look and let me know your initial thoughts:

• https://github.com/mphuff-personal-org/otf-api-models
• https://github.com/mphuff-personal-org/otf-api-ts

The libraries were 100% auto-generated and I haven't gone through with a fine tooth comb yet to validate but critical functionality does work and seems to drop-in replace for python functionality thus far.

To your point about separate model package, perhaps if we treat the python package as the source, it still maintains a full model definition that is more machine-readable and then other interpretations of the models / endpoints based on code need could leverage that for consistency. Not sure we'll have lots of other implementations but I'm flexible on considerations here. I'm just trying to fully build on Supabase where I can and the anomaly in my entire infrastructure I had was the actual calls out to OTF so I figure if I could port at least part of (my initial goal) the otf-api to TypeScript, it'd be a win but Claude did a remarkable job at porting the whole thing.

[NodeJSmith]

I haven't gone over it in detail yet either but damn that code does look quite good for just being AI generated. Maybe I should be giving Claude a shot.

Yeah if we want to just try to keep in sync using machine readable specs and human communication we can give that a shot and see how it goes.

If you're not anticipating doing any reverse engineering yourself when new official package version are released (which is totally fine, no concerns from me) then we can treat my python code as the source of truth and keep yours in sync. If you do plan on contributing directly from their updates we'd want to do things a bit different probably.

Couple of thoughts - getting tests should become a higher priority, although I'm pretty swamped with my jobs and a new personal project that it taking my focus right now, so I'm not sure when I'll get to that. Biggest blocker is having the time to get raw data from the api responses and removing personal data so I feel comfortable checking it in so I can mock responses. If you have the time and inclination to add some anonymized data please feel free, and I can start on tests sooner. I do eventually want to code in a way to anonymized data, especially for bug reports from users, but that's even further down the wishlist.

We should make sure any potential contributor knows which package is the source of truth, although I'm not sure how we'd want to handle it if someone with only TS knowledge wants to contribute. I'm okay back porting to python as long as I know to do so.

We'll likely want to coordinate releases?

We could potentially put both packages in one repo and/or one project, to make all of this a bit easier, but I'm not sure how necessary that is vs the overhead of setting that up.

Let me know your thoughts on all of that rambling, but yeah, this is pretty cool and I think we could totally make this work

[mphuff]

I like where you're thinking; I just haven't had much time to work towards this this week. I'll try to spend some time this weekend on fleshing this out a bit further but I think we're on the same page.

[mphuff]

I've opened #107 for us to collaborate and discuss on. I'm going to run a few more passes through the generated TypeScript library but this incorporates it all into the single library which is probably simplest for maintenance long-term. Take a look and let me know your initial thoughts.