Doesn't work with Next.js in APIs (events seem sent but aren't available on Amplitude dashboard) about amplitude-node HOT 9 OPEN

Also, the UX on the server isn't great, because you're making either device_id or user_id required, but most of the time I don't know what's the device (it's an API call, there is no device) and sometimes I have no way to know who's the user either.

I think none of those fields should be required for server-side usage. They should both be optional.

from amplitude-node.

Okay, so it looks like it was because the call worked (200 response) but eventsIngested was 0.

And this is because of the user/device issue. I had to specify a device_id value even though I'm on a server and don't know what value to use. Should I rather use a dynamically generated value for every call?

from amplitude-node.

I've fixed it at 815ff95 (#374)

But this doesn't seem great, Amplitude now believes all events are related to the same user, which isn't really the case. So I'll rather use a dynamic UUID value as default user_id to counter this behavior.

I wish this had been explained in the README, I've lost a whole day on this.

from amplitude-node.

I'd like to know if it's necessary to await the flush() on Next.js API endpoints, I believe it is but that'd be great to have a confirmation. 😄

from amplitude-node.

Hi @Vadorequest, great to hear you solved the problem on your own.

1. The Amplitude-Node will call our Amplitude HTTP v2 API, the device_id and the user_id are semi-required there. So it cannot be all optional. If a device_id is not sent with the event, it will be set to a hashed version of the user_id. So you can set a dynamic UUID as default user_id when you don't know what's the user_id is and don't pass the device_id during logEvent.
2. In Amplitude-Node, the flush() function is async and will return a promise. So, yes, if you need to do something with the response you need to await it.

from amplitude-node.

In Amplitude-Node, the flush() function is async and will return a promise. So, yes, you need to await it.

I was asking in relation to https://vercel.com/docs/platform/limits#streaming-responses. I understand I need to await it if I want to do anything with the Response, but do I need to await it to make sure the event is sent in the context of AWS Lambda? If I don't await logEvent() but simply logEvent(), do I take the risk of the event not being processed? That's what a bit uncertain at the moment.

Ideally, I'd rather not await when calling logEvent, because I don't want to make any of my own API endpoints slower.

from amplitude-node.

@Vadorequest
To clarify your question,
You are using Vercel as the framework. And you are curious if ​Vercel does not support streaming responses will affect how you use Amplitude-Node and if you must add await when calling flush or logEvent?
cc: @ajhorst

from amplitude-node.

from amplitude-node.

I've opened a related issue on Next.js to try to figure out the pros/cons and best practices regarding all of this. vercel/next.js#26523

from amplitude-node.