Consider avoiding apnotic/net-http2 dependency

[trevorturk]

Hello!

Exciting to see this gem, I was looking for something built into Rails a few months ago and I'm so happy to see this!

I just wanted to drop a suggestion to consider what apnotic is buying you, because FWIW I found it was (in combination with the net-http2 dependency) increasing my app's memory use (in a memory constrained environment on Heroku).

Here's what I ended up with using Async::HTTP in case it's useful to you or others (please excuse the application-specific code!)

require "async/http/internet/instance"

class ApnsToken < ActiveRecord::Base
  TOPIC = "ios-app-name-goes-here"

  validates :env, :token, :topic, presence: true
  validates :token, uniqueness: { scope: [:env, :topic] }
  validates :topic, inclusion: { in: [TOPIC] }

  def test
    push(:alert, { alert: "Hello!", sound: "default" })
  end

  def ping
    push(:background, { "content-available": 1 })
  end

  private

  def push(type, payload)
    host = case env
      when "development" then "https://api.sandbox.push.apple.com"
      when "production"  then "https://api.push.apple.com"
    end

    url = "#{host}/3/device/#{token}"

    headers = {
      "authorization" => "bearer #{jwt}",
      "apns-topic" => topic,
      "apns-push-type" => type,
      "content-type" => "application/json"
    }

    body = JSON.generate({ aps: payload })

    Sync do |task|
      response = nil
      result = nil

      task.with_timeout(2.seconds) do
        response = Async::HTTP::Internet.instance.post(url, headers, body)

        result = case response.status
          when 200
            true
          when 400
            destroy if JSON.parse(response.read).dig("reason") == "BadDeviceToken"
            false
          when 410
            destroy
            false
        else
          false
        end
      end

      result
    ensure
      response&.finish
    end
  end

  def jwt
    @_jwt ||= begin
      payload = {
        iss: Rails.application.credentials.services.apns.team_id,
        iat: Time.now.to_i
      }

      JWT.encode(
        payload,
        OpenSSL::PKey::EC.new(Rails.application.credentials.services.apns.private_key),
        "ES256",
        kid: Rails.application.credentials.services.apns.key_id
      )
    end
  end
end

In any case please feel free to close as not planned etc, but I figured it was worth sending a note.

Thanks!

[rosa]

Hey @trevorturk! Thanks a lot for this. Dropping apnotic is very much in our plans! We used it to get to something that worked quickly, but we definitely want to get rid of it. This is super useful! 🤩 Huge thanks!

[intrip]

I’m starting the work to remove the apnotic dependency. The plan is to replace it and use httpx as HTTP/2 client.

I’m picking httpx because:

• It relies on the same underlying HTTP/2 library of apnotic, which is the battle-tested Ruby implementation of the HTTP/2 protocol adopted by multiple clients.
• Although it’s a relatively large library, it’s still smaller than pulling in the entire async ecosystem via async-http.
• async-http brings its Fiber scheduler, which is great for handling many concurrent connections, but right now we process each notification in a separate job, so we wouldn’t benefit.
  • With httpx, we can still opt in to the Fiber scheduler. That means if we implement multiplexing later, switching should be straightforward.
• It supports keep-alive connections for HTTP/1, which we can use in the FCM service.
• It has a comprehensive wiki.

@trevorturk do you remember any details about the app memory issue you ran into with apnotic? I want to make sure the library will also be usable by relatively low-memory clients.

[trevorturk]

Howdy, @intrip, thanks for thinking of me! 😉

I'm sorry, but I didn't look into the memory issues much, tbh, it was very clearly because of adding the apnotic gem, and I noticed the HTTP/2 lib was included, but I shouldn't point fingers without having investigated. I moved into triage mode and realized it wouldn't be much work to swap out for async-http since I was already using it throughout my app, already bought into the async ecosystem, etc etc.

I think httpx looks like a good choice, as it seems to have wonderful support and is becoming more broadly adopted. I've been following along as an old coworker has been working through some issues (see HoneyryderChuck/httpx#100) and it's been great to (you can tell the author of the gem cares deeply and is obvious very skilled). I would say it's a bit of a concern that there have been these difficult to track down bugs, but I'm confident things will get solved and it seems like httpx has a bright future.

FWIW I'd be more than happy to test even a rough implementation and report back about memory usage etc if helpful? It's very easy for me to swap things in and out, and I don't mind if things are rough for the particular feature I'm using APNS for.

Apologies again for not having more details in any case!

[excid3]

@intrip Think we should use httpx in Action Push Web as well? It's currently using net-http-persistent but seems like we could make them consistent.

[intrip]

I think httpx looks like a good choice, as it seems to have wonderful support and is becoming more broadly adopted. I've been following along as an old coworker has been working through some issues (see HoneyryderChuck/httpx#100) and it's been great to (you can tell the author of the gem cares deeply and is obvious very skilled). I would say it's a bit of a concern that there have been these difficult to track down bugs, but I'm confident things will get solved and it seems like httpx has a bright future.

Right! We'll see how it turns out: We are still in the experimenting phase, time will tell.

FWIW I'd be more than happy to test even a rough implementation and report back about memory usage etc if helpful? It's very easy for me to swap things in and out, and I don't mind if things are rough for the particular feature I'm using APNS for.

That would be great! I'll keep you posted.

[intrip]

@intrip Think we should use httpx in Action Push Web as well? It's currently using net-http-persistent but seems like we could make them consistent.

I’m still experimenting with httpx, so it’s a bit early to decide, but I’d like the consistency too.