Not exactly. Although Segment has some backend integrations, most tags still need to be on the client side. Each tag typically tracks its own cookies and uses third-party cookies to learn more about each user. However, as those cookies are starting to go away and privacy is starting to increase, we may see a big shift.
I'm hopeful something like this will take off. I'm tired of adding so many slow third-party tags.
Ideally, CloudFlare would allow you to route specific paths to different backends so you could just aggregate multiple services within your single domain for the fewest connections and DNS lookups.
Feels crazy but this makes me think to proxy imgix, which uses Fastly (not supporting SPDY or HTTP/2 yet), through CloudFlare. I'll just set up CNAMEs on my imgix account that are subdomains of my main domain, then add them to CloudFlare with acceleration on - but no caching (since imgix serves images by user agent). This adds an extra datacenter to datacenter hop, but hopefully that's really fast and upgrading the client to SPDY or HTTP/2 would outweigh that.
Awesome! With that + HTTP/2 server push, we'll really be flying.
We already started to proxy our S3 / CloudFront assets through our load balancer so they can be cached and served through the SPDY (now HTTP/2) CloudFlare connection. However, since we're using imgix to serve different images by device, we can't allow CloudFlare to cache.
I've set up some tests to proxy Fastly through CloudFlare and my initial tests are inconclusive as to whether the crazy extra hop is worth it. It seems that if we have tons of images, it probably will be faster, but most of our pages only load about 6 images above the fold and lazy load everything else, so that might be why the difference is negligible. I'll have to test on a page where more images download concurrently to see if 1 extra hop to get SPDY and HTTP/2 is worth it.
We started using Google Cloud Storage when it first came out so that user uploads would be closer to them (in theory) due to GCS' distributed design. They seem to have periods of 15-90 minutes every few months where they start timing out or giving us huge errors and often times we don't even hear about it either. They don't have a status page any only announce via email list - usually way after we've been scrambling.
Anybody else have a bad experience with Google Cloud Storage? I'm wondering if we're better off going with S3. Most users on my site are uploading photos, so when that dies, everything is down.
[Disclaimer: I'm Dan, Context.IO's product manager]
We welcome InboxApp to the email API space. Like Context.IO, they see the value of helping developers build apps that interact with email. Building a platform like Context.IO, that abstracts complex systems, involves more technical challenges and product-level decisions, than you can keep track of. So, it’s not a surprise that our two teams came to different conclusions and have built somewhat different solutions. InboxApp made a choice to cache 100% of the email data, hoping to solve potential availability issues, which is key for some use cases. As a result, developers on that platform need to cover the costs for storing that data, whether or not they need it. We've worked with and spoken to hundreds of developers over the last few years and learned that the vast majority don't need that model and do not want to carry those costs. In the few cases where the dev needs a cache of every single message, many decide to store the data they need, instead of relying on a third party to store everything in their users’ mailbox.
If speed is the utmost concern and you are able to charge your users enough for your product to cover the cost of the platform while keeping your business afloat, then paying $5 a month per account might be cost-effective. However, if you prefer to use a header caching layer and you can engineer around caching the bodies, then using Context.IO for free is a better fit.
Just a couple quick points I should mention. Context.IO stores all of the message headers in our caching layer. Combined with our webhooks, applications are quickly notified of a change and can easily retrieve messages they care about. Exchange support is being used by initial beta testers on our Lite API right now. If you're interested in joining the beta test, please let us know!
• The Inbox Platform isn't a proxy later. It actually maintains a full mail sync, so response times are super fast. Context.IO is ridiculously slow (like 10-30 sec).
• Support for Exchange ActiveSync. They've been promising this for years, but haven't delivered it.
We also have client scaffolds, modern SDKs, a platform that deals with MIME, character encodings, and more. You get what you pay for here, and it's an actual platform that you can build an app on. Many of our customers have switched from Context.IO.
Do you have to throw out all your social rankings?
I've been wanting to switch to HTTPS but have been avoiding it due to significant accumulation of Facebook likes and some +1's. Last I checked, you had to do some big hacks to maintain your Facebook like count. Has anybody found a good way to handle this or do you just have to start over?
I've been looking for something like this for a while to provide copy / paste address book import functionality from Excel or any spreadsheet program. Google Apps script was interesting because you could do complex rules like adding validation but I don't think it's really designed to be dropped in to your site to be used by anonymous users and having Google Spreadsheets as a dependency isn't ideal.
However, for simple input this looks great. What else is out there? I saw the projects listed on this project's github but those weren't the same - just start editing and pasting.
I'm hopeful something like this will take off. I'm tired of adding so many slow third-party tags.