Snowdrop Framework

Hi!

Today I've released first version of Snowdrop. It's a type-safe, protocol based framework inspired by Retrofit that comes with Automatic Authentication Refresh, SSL/Certificate pinning, WebSocket and the path variable default value support.

I'd like to highly encourage you to check it out and share your thoughts :slight_smile:

4 Likes

Congrats on the release it looks quite fun! Though the name is incredibly confusing tbh :sweat_smile:

Netty is THE networking library on the JVM and “netty for swift” is exactly SwiftNIO, co founded by Netty authors etc. So googling around and finding this Netty could cause quite some confusion and misunderstandings :thought_balloon: It’s your choice in the end, but with my Swift Server Wofkroup hat on, I think we’d like to avoid causing such confusion to people coming into Swift. Do you think you could consider picking w different name? Given that the nature of this library is different than the well known Netty library hm.

Sorry for such request but I’m thinking here about the ecosystem impact of confusing people coming from JvM land to Swift.

The library looks cool and it’d be nice to promote it etc!

8 Likes

Thank you. Yes, it might be a good idea. I’ll think of a different name then :slight_smile:

5 Likes

I chose Snowdrop :) It better fits the time when it got created. Once again thanks for pointing out the name was heavily suggesting it's JVM's Netty but for Swift

6 Likes

Oh that’s a fun name, congrats! :snowflake: :droplet:

Now let’s get back to discussing the actual project and code! :smile: I’ll have a deeper looks myself as well…

2 Likes

IMHO, the URL must not be part of the service, but should be an injected parameter.
You must be able to create multiple instance pointing on different URL (staging URL, prod URL, …)

More generally, I think dropping the Retrofit.Builder() design pattern from your API design may paint you into a corner by limiting the way to customize the service (replacing the network stack, changing the serviced URL, etc.)

All of this should be defined at service creation time, and should not be editable afterward (like the auth handle, etc…).

Interesting idea. I’ll look into it :slight_smile: