Synchronous mode

[segmentio]

Synchronous mode

[nozpheratu]

@drubin Be warned, I ran into some issues trying to build my own synchronous wrapper for event logging and then incorporating it into my existing queuing system. As I understand it segment uses some kind of strange batch on their servers to queue logging and for whatever reason it isn't first come first serve and if multiple events are logged at nearly the same time they won't be logged in guaranteed order.

Since I only needed the event logging for GA I ended up just using Staccato.

[drubin]

👍 Assuming how a server is setup and architectured for a "http lib" is generally a bad idea.

Servers that implement queues/background workers will do it much better than a simple in memory queue and servers that don't need a background queue system won't have one.

Sidekiq/delayed job/sucker punch/ all do queue'ing as their SINGLE job and even they have issues. You should make your docs/integration plan easier to use with external queue systems.

[whatthewhat]

@nozpheratu thanks for the warning! I think the ordering issue could be solved in some cases by manually batching events using import.

We did end up starting a synchronous wrapper over at https://github.com/whatthewhat/simple_segment, but batching events is not implemented yet.

update: batching is merged and released to rubygems.

[sperand-io]

@whatthewhat FYI, we're linking to your library as an alternative from our docs. Big thank you for your contribution! :)

[christophe-dufour]

👍

[erickreutz]

👍

[nozpheratu]

👍

[whatthewhat]

A question for maintainers: Is this something that can be potentially added to this client?

This is currently painful enough, that I'm considering writing a separate simple synchronous API wrapper for our use case.

[drubin]

@whatthewhat I am also busy writing my own synchronous API wrapper.

Currently I have wrapped every method call in a

def track(params)
   analytics.track(params)
   analytics.flush
end

But honestly with the complexity of querying am more keen to have stable simplistic code. Since I already have a queuing system with proper workers/threaded pools.

[drubin]

@nozpheratu I have also given up on segment. Their staff are totally unresponsive. Their API's make bad design decisions and after much struggling trying to integrate it for more than a day (Legacy mixpanel data/formats trying to sync up their custom wrappers while still maintaining legacy events formats) I gave up.

I see the value segment.io adds in massive companies where marketing/customer service do not have control of production or can't write a line of code and switch out analytics frameworks every 2 weeks. But for engineers I see little value in a API proxy service they provide.

The fact not a single segment employee has responded on tickets in months is a clear indication their target markets aren't people that can use github.

[nozpheratu]

@drubin Actually, I still use Analytics.js on the client for some things. Regarding their support, have you tried emailing them directly? I personally have had really helpful and prompt responses from both their developers and support staff despite being on the free plan using this page: https://segment.com/contact

[whatthewhat]

Awesome, thanks!