Function-based requests

[mattmassicotte]

Hello!

First, I just wanted to say thanks for working on library. It's cool!

I work on an OAuth library called OAuthenticator. I needed to exercise it for testing, and got interested in Bluesky, so thought I'd try it out. This turned out to be far more complex than I was expecting, but it was a really fun project and definitely did achieve the goal.

This got me thinking more about your library here. Have you given any thought to abstracting the underlying network request mechanism? I do this with a simple function:

public typealias URLResponseProvider = @Sendable (URLRequest) async throws -> (Data, URLResponse)

It's "job" is to carry out the request in a way that satisfies the authentication requirements of whatever system you are working with. It may be possible to incorporate a similar idea into your library, so you can focus on the actual protocol-level work, and just rely on a function to perform the real requests. Handy for testing too!

With this kind of arrangement, it wouldn't be too hard to maintain an existing implementation that does this via the app-specific password stuff. And, if you wanted to internalize the OAuth stuff too, eventually, that could be possible as well.

All just food for thought! I know there's a real benefit to having one library that does it all, but I thought it could be neat to at least consider the possibility of a more composable arrangement.

[MasterJ93]

I'm open to the idea. And to be clear, I don't want a library that does it all: ATProtoKit should mainly handle the lexicons, the requests and responses for the lexicons, authentication, and have a dedicated Bluesky API wrapper. Anything outside of this will be made into separate repos. I want to do this instead of making it all into one library (or having several libraries within one Swift package) because I'm not exactly comfortable with ATProtoKit being put into that position. I also don't want to bloat the package: it just needs to do a few things and do those things well. Hopefully that makes sense. Small libraries within the package are fine by me (for example, the ATMacros library), but anything bigger than that crosses into uncomfortable territory.

In a short term, I plan on using Apple's OpenAPI generator and possibly a lexicon-to-OpenAPI generator (Bluesky does have their own OpenAPI types file, but just in case it doesn't work as well as I hope, I'll have to make my own). I don't know if your suggestion will work when implementing the OpenAPI generator, but I'll look into it. But thanks again for the suggestion and it's in my list of things to think about when figuring out how to get this to work.

[mattmassicotte]

ok sounds great!