Recent submissions

Comment · 5 years ago
I was genuinely surprised your comment doesn't end with an "/s", but anyway, I'd be interested to hear the rationale of users who pay for "smart people thoughts".
Comment · 5 years ago
Comment · 5 years ago
Comment · 5 years ago
Ever since xmlhttprequest (and even before that with images) we've been able to do server-side validation without a full page reload.

This "solution" completely ignores the purpose of client-side validation which is to a) reduce load on server-side resources, b) validate faster without the network latency and c) validate more securely and privately by not sending the content to the server.

Comment · 5 years ago
imo, "modern" would mean it removes or replaces features and characteristics which were exclusive to or popular in a previous time period but are not essential or can be replaced with "modern" alternatives.
Comment · 6 years ago
This is preventing me from reading (and possibly writing) with Cloud Logging APIs across multiple accounts and regions.

Also worth noting this incident is described as part of "Operations" but actually impacts "Cloud Logging" and is still using the old "google-stackdriver" category internally..

Comment · 6 years ago
I think there is some difficulty specific to Shopify here, as REST APIs go their original one was fairly sane and provided powerful features.

When their GraphQL API was released its data structures were similar but not identical to the REST API and some very important fields and features were missing which translated to a "90%" adoption by developers who needed those missing pieces. Additionally (and somewhat in keeping with points in the article,) they also introduced API versioning at this time which added a good amount of friction within the community.

More generally the issue with Shopify's GraphQL APIs is its lacking features (eg, list totals, offset pagination, object fields) which are (or had been) particularly important to the ecommerce domain and they've struggled to provide any meaningful alternatives.

As an example, developers working with ecommerce applications often have to process data en masse (fulfillments, inventory, etc..) and with the Shopify REST API and it's offset pagination these tasks were trivial to parallelise by simply chunking the workload based on the pagination method. In the GraphQL API offset pagination was removed in favour of cursor pagination which has no reasonable alternative to parallelise tasks in the same way, this requires developers to rewrite core logic and services for what may have previously been a very acceptable, efficient and most importantly working application.

The issue with Shopify's GraphQL API is not GraphQL itself, but rather the implementation of the API not meeting the requirements of the consumer - and the fact that those consumers were forced to switch to a different API without feature or even conceptual parity didn't promote feelings of joy or glee about the situation.

Personally I think their push for GraphQL was due to internal operational issues and their need for a more efficient system. This has been seen in their reasoning for reducing the timeout of an API used to fetch shipping options (from 10 seconds to 5 seconds) in preparation for Black Friday / Cyber Monday sales events, their announcement provided some developers less than a single business day to respond to the changes[1] which were dropped after community backlash and then changed to address the feedback.

[1] https://community.shopify.com/c/Shopify-APIs-SDKs/Changes-to...

Comment · 6 years ago
Completely forgot in the other comment but your product would be subject to GST, which is a tax. I can't imagine Google paying GST %s on their Australian ad sales, but it's a starting point.
Comment · 6 years ago
What if you as a European (company) employ 1000 Australians in Australia and have Australia specific resources (including sales) in Australia and use those Australian resources exclusively for Australia.. are you still not operating in Australia?
Comment · 6 years ago
Well done, it's a neat idea and if the service can provide a measurable improvement I think it's worthwhile to pursue further.

Seeing the service in action would really help both technical and non-technical audiences, I need to know it's not going to be a liability and my clients would want to see pretty colours / improvements.

Something like "before.pep.dev" and "after.pep.dev" would be great.

Comment · 6 years ago
Comment · 6 years ago
Comment · 7 years ago
And even more simply, verifying the user is a "real person" in contrast to verifying the user is the "right person".
Comment · 7 years ago
This was a problem before Twitter allowed 2FA via SMS, so I'd argue this is very much a Twitter problem.

Afaict this all stems from mixing verification with authentication, where verification may be required when creating an account and authentication (and possibly more verification) when using the account.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton