> Now rewrite your entire comment with sonos instead of ubiquiti.

[0] https://www.grymoire.com/Unix/Sed.html#uh-6

[1] https://beta.sam.gov/opp/588f5ed4becd4fc4abf6df8e7a918184/vi...

Edit: This[2] seems to be a notice of the contract being awarded to Oshkosh for exactly $481,877,752.00 USD.

[2] https://beta.sam.gov/opp/1e56c386808444d886124fc1927f4eb0/vi...

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.

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..

Comments URL: https://news.ycombinator.com/item?id=25298124

Points: 2

# Comments: 1

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...

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.

I'm assuming this is targeted at a non-technical audience (although posting to HN would suggest otherwise), but I suppose it could provide some benefit under ideal conditions.

Including a 24kb font for the three "pep" letters in the heading just tops off the eternal face-palming. Incredible.

[0] https://developers.google.com/speed/pagespeed/insights/?url=...

It falls apart especially quickly when adding an iOS, TV (JS) or other client (or server) codebase.

To resolve the multiple node_module directories you can use tooling like Workspaces[0] (with both npm and yarn) which hoists the node_modules to a "workspace level".

I'd be interested in hearing other annoying issues you have with multiple package.json files.

[0] https://yarnpkg.com/en/docs/workspaces/

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.

I think a better approach for everyone involved would be to only store references to videos which were posted more than x minutes ago. I'm not sure if they have that information when scraping though.

    data:text/html;base64,...

I think this use case provided a lot more value and depth than a more pedestrian "congratulations on graduating".