Serverless discussion

Question

Serverless discussion

cezarsmpio opened this issue 4 years ago · 36 comments

cezarsmpio commented 4 years ago

Hey I'm creator of https://heartrate.overlays.dev/ and I'm using your app to do so.

However, after the last update, the app is simply closing after 3-5 seconds.

Any idea?

Answer 1 · 2020-10-12T19:36:07.000Z

Communication is now done with web sockets. The crash happens because you are passing an http url into the watch app.

Answer 2 · 2020-10-12T21:36:06.000Z

You know if you can get this working with websockets I might just point people to you if they can't get my local server working. There's just too many local network issues that can happen that aren't my fault. I've thought about doing something similar myself, but I just didn't have the time. Do you think you could implement calories into your overlay?

Answer 3 · 2020-10-12T23:38:51.000Z

Actually I'm not sure the current watch app will let you use external URLs properly. I'm working another update that should fix this.

Answer 4 · 2020-10-13T07:33:32.000Z

Actually I'm not sure the current watch app will let you use external URLs properly. I'm working another update that should fix this.

It was working just fine :) I posted it on Reddit and a lot of people started using it, they might not be able to use it anymore after the update.

Changing it to websockets may not be possible because I'm using serveless functions and they don't support running websocket servers, since I'm making this overlay for free, I need to use free services, however, they might be limited. I'm currently using Vercel + Pusher.

It works pretty much like that:

Your app -> POST -> Vercel Serveless Function -> Trigger Pusher event -> Browser listens to it.

I can implement calories, no problem :) it might not be that hard, but it would be nice if you could return the support to HTTP requests.

Thanks!

Answer 5 · 2020-10-13T12:55:19.000Z

It looks like you might be able to use AWS for free if the number of requests are low enough. The reason I switched to web sockets is they should offer a faster and more stable connection.

Answer 6 · 2020-10-13T12:58:13.000Z

Also it looks like Pusher might support web sockets but I'm not sure

Answer 7 · 2020-10-13T13:44:34.000Z

I'm not very familiar with AWS, to be honest, my stack now is much simpler and reliable by using Serveless + Pusher. I started doing my own WebSocket solution but it ended up being too much work because I needed to manage losing connection conditions, for instance, and Pusher is now doing all of that for me.

Pusher is a WebSocket server itself. I can't use only Pusher because my serverless functions are triggering events with specific names, that's why I use the random ID, because it creates a channel with those IDs, so people can get their own heartrate data and not from somebody else.

WebSockets won't work with my current approach.

Can't you support both? WS and HTTP?

People started messaging me on Twitter asking why the overlay is not working anymore :(

I have zero experience with creating apps for iOS hehe

Answer 8 · 2020-10-13T13:46:14.000Z

Another thing, how fast this should be? I'm also a streamer and I was using it on my streaming, for me, it was fast enough before, I could see the heart rate changing on the overlay right after changing on my apple watch.

Answer 9 · 2020-10-13T13:59:51.000Z

Rest calls are throttled by watchOS. That's the main reason I switched. People were having periods of time where data wouldn't get through. People were also saying that their heart rate wasn't updating as fast as it should so I rewrote the code that gets the health data to hopefully be faster and more reliable. Also I uhh didn't know your thing existed so sorry about breaking it. When do those serverless functions need to trigger? Maybe we could work together on a solution? I would really like to stick with web sockets for communication.

Answer 10 · 2020-10-13T15:22:10.000Z

Hummm, I see. Maybe we could only use Pusher but it has a limitation on the free plan of 200K requests/day. I had like 40.000 in one day. We can share a project on Pusher and give it a try.

Here's pusher documentation for iOS: https://pusher.com/docs/channels/getting_started/ios

If we use the same project, we no longer need the IP, just a "code", so on the app people would just need to add this code.

Apple Watch -> Connect to Pusher -> Trigger an event to a specific channel based on the ID -> Overlay subscribes to this channel with specific ID -> Show heart rate

This way we can remove Serverless functions because we will use Pusher to be the middle term.

I think you will need the secrets, so I can send you over Slack or something...

The overlay listens to this event heart-rate-${id}, which is the event the apple watch will need to send the event to, so this ID is generated for each user. I generate a random one whenever the access my website.

My serverless function is pretty much:

const Pusher = require("pusher");

const pusher = new Pusher({
  appId: process.env.PUSHER_APP_ID,
  key: process.env.PUSHER_KEY,
  secret: process.env.PUSHER_SECRET,
  cluster: "us2",
});

module.exports = (req, res) => {
  const { id } = req.query || {};
  const { heartRate } = req.body || {};
  const isRequestUnknown = !req.headers["user-agent"]
    .toLowerCase()
    .startsWith("apple watch health data client");

  if (!heartRate || !id || isRequestUnknown) {
    return res.status(404).end();
  }

  pusher.trigger(
    "heart-rate-obs-overlay",
    `heart-rate-${id}`,
    {
      type: "HEART_RATE",
      payload: heartRate,
    },
    () => res.status(200).end()
  );
};

Answer 11 · 2020-10-13T15:30:31.000Z

Another idea, can't you make the iPhone make the HTTP request? Apple Watch only transmits the data to it, maybe it would be better performance-wise, sorry no idea if this is even possible... I think you need to have an iPhone in order to have an Apple Watch, right?

Answer 12 · 2020-10-13T15:31:31.000Z

I want your overlay to be an option, but I don't want it to be the only option. Mainly because servers cost money.
The iPhone can't be part of the equation because you can't guarantee the iPhone app is alive.

Answer 13 · 2020-10-13T15:32:52.000Z

Could the ID be generated on the watch?

Answer 14 · 2020-10-13T15:33:37.000Z

Another thing: If you do need a rest call to get things started, the watch can do that. It's only if you do a lot of rest calls that they get throttled.

Answer 15 · 2020-10-13T15:34:53.000Z

Ideally you can still get it working without any changes on my part though

Answer 16 · 2020-10-13T15:36:38.000Z

Could the ID be generated on the watch?

The overlay will need to know which ID is. How could we send this ID to the overlay? Maybe it's a design challenge than a technical one.

Another thing: If you do need a rest call to get things started, the watch can do that. It's only if you do a lot of rest calls that they get throttled.

This implies I will need a WebSocket server running and like you said, servers cost money :/

Ideally you can still get it working without any changes on my part though

Yeah, I'd need to change from Serverless to AWS or Heroku and implement a WebSocket server on my part. I'll think about it!

Answer 17 · 2020-10-13T15:37:54.000Z

Are you sure Pusher can't work? I keep seeing documentation talking about web sockets.

Answer 18 · 2020-10-13T15:38:32.000Z

Also I think you can do serverless web sockets with AWS if you can't do them with Pusher

Answer 19 · 2020-10-13T16:06:32.000Z

I will check their documentation and see what can be done, I'm not sure it can't work. I will also check AWS Serverless WebSockets.

Thanks for the ideas!

Answer 20 · 2020-10-22T17:08:24.000Z

Hi @Rexios80 , i'm working on the Amazon WebSockets API, however, I need to know what's the event name you are emitting from the watch, so I can listen to it. Could you tell me?

Answer 21 · 2020-10-22T17:09:37.000Z

What do you mean by event name? They're just web socket messages.

Answer 22 · 2020-10-22T17:12:56.000Z

When you emit something from the apple watch, you just call emit or any other name without any message? Just the value?

Sorry, I'm still trying to understand how Amazon WebSockets working, I'm also checking your code here: https://github.com/Rexios80/Health-Data-Server-Overlay/blob/master/public/app.js#L122

That's why I've asked.

Answer 23 · 2020-10-22T18:04:12.000Z

I added the AWS IP to the app settings and after like 5 seconds it starts showing a lightning icon with a line crossed. What does it mean? It doesn't crash or anything.

I can see I started receiving some connections already:

Answer 24 · 2020-10-22T18:07:51.000Z

Do you support wss:// from the apple watch or just ws://? Not sure if it makes any difference though.

Answer 25 · 2020-10-22T19:40:40.000Z

wss should work although I haven't tested it. Does the serverless websocket respond to pings? That's what determines if the watch thinks it is disconnected or not.

Answer 26 · 2020-10-22T20:06:41.000Z

I was able to make it connect, no problem at all, now the problem is that I can't use AWS WebSocket the way I wanted, or at least I lack some knowledge to do that.

I trust those random IDs to know which user I need to show the data to, but I couldn't find a way I can pass dynamic values through the WSS URL. I managed to pass it through query string parameters but I receive those values only once on the $connect event, I actually need to get the random id + heart rate information at the same time whenever the watch sends any message. I was able to receive it but without the unique id.

Another solution would be to create a WebSocket server myself and deploy it to Heroku, but I'm afraid their free services won't be good enough.

So unfortunately I will need to close the project or unless you can help me out here.

At the moment, you are sending this message heartRate:XX, for example. If possible, it would be nice if you could send a payload that looks like this:

{
 "value": "heartRate:XX",
 "queryParameters": "?id=RANDOM_ID"
}

And the URL would be something like: wss://domain.com/?id=RkXbGMqEfU5afEcAJd2NP

Not sure if you can send JSON payloads though. Or something like heartRate:80:RkXbGMqEfU5afEcAJd2NP

Thanks for your support!

Answer 27 · 2020-10-22T21:26:01.000Z

Is there no way to keep track of what client has what id?

Answer 28 · 2020-10-23T02:51:27.000Z

Aaah, this is,the ‘bad url’ issue

Answer 29 · 2020-10-23T02:53:55.000Z

@mroffbeat The normal overlay works if you want to use that. Sorry I broke his thing. The old communication method was unstable.

Answer 30 · 2020-10-23T06:27:56.000Z

Is there no way to keep track of what client has what id?

I couldn't find it. Not using the WebSocket API from AWS at least.

Answer 31 · 2020-10-23T13:11:25.000Z

I think you'd have to use AmazonDB with it.

Are you sure your solution is worth putting more time into? It made sense when my overlay sucked, but it's gotten a lot better recently.

Also if my app keeps growing, free tiers aren't going to cut it.

Answer 32 · 2020-10-26T14:10:36.000Z

I'm closing the issue, but if you have any other questions feel free to ask.

Answer 33 · 2020-11-01T18:14:21.000Z

Hey @Rexios80 just to let you know, I was able to make it work with your app again, just need to finish the AWS custom domain: https://heartrate.overlays.dev/

The flow now looks like:

Apple Watch -> WS to AWS WebSocket Gateway -> Lambda -> POST to Vercel Serverless <-> Redis to store the overlay id based on the connection id

Answer 34 · 2020-11-01T18:16:00.000Z

That's awesome! What do the server costs look like though?

Answer 35 · 2020-11-02T08:38:40.000Z

All free so far. If it starts growing and having many people using it simultaneously, then it might be a problem but if that's the case, I can come up with some pricing 🤷‍♀️

Answer 36 · 2020-11-20T17:46:41.000Z

I just wanted to let you know I'm working on an update that should greatly reduce the number of messages that get sent from the watch. This should help you stay in your free tiers.