话题公司 › Shopify

公司:Shopify

Shopify Inc.是加拿大的一家跨国电子商务公司,总部位于安大略省渥太华,Shopify也是该公司所有的电子商务平台的名称。Shopify为在线零售商提供一整套服务“包括支付、市场营销、运输和客户契合工具,以简化小型商户开设在线商店的过程”。

根据公司披露的文件,截止2019年6月,Shopify平台在大约175个国家或地区有超过一百万笔业务,2020日历年的商品总成交额1196亿美元,较2019年增长96%。

Upgrading MySQL at Shopify

Learn how the Database Platform team performed the most recent MySQL upgrade at Shopify and how this changed our upgrade guidelines moving forward.

Remote Rendering: Shopify’s Take on Extensible UI

A deep dive into the latest generation of technology that allows developers to extend Shopify’s UI.

Building an App Clip with React Native

Being the first to build an App Clip in React Native that was going to be surfaced to millions of Shopify's Shop app users each day proved to be a challenging task.

The Vitality of Core Web Vitals

A deep dive into each metric of Google Core Web Vitals.

Shopify's Path to a Faster Trino Query Execution: Custom Verification, Benchmarking, and Profiling Tooling

Data scientists at Shopify expect fast results when querying large datasets across multiple data sources. We use Trino (a distributed SQL query engine) to provide quick access to our data lake and recently, we’ve invested in speeding up our query execution time.

On top of handling over 500 Gbps of data, we strive to deliver p95 query results in five seconds or less. To achieve this, we’re constantly tuning our infrastructure. But with each change comes a risk to our system. A disruptive change could stall the work of our data scientists and interrupt our engineers on call.

That’s why Shopify’s Data Reliability team built custom verification, benchmarking, and profiling tooling for testing and analyzing Trino. Our tooling is designed to minimize the risk of various changes at scale.

Below we’ll walk you through how we developed our tooling. We’ll share simple concepts to use in your own Trino deployment or any other complex system involving frequent iterations.

Debugging Systems in the Cloud: MySQL, Kubernetes, and Cgroups

An overview of how we investigated and solved the issue of some Kubernetes Pods running MySQL starting up and shutting down slower than other similar Pods with the same data set.

Reusing Code with React Native Packages at Shopify

At Shopify, we develop a bunch of different React Native mobile apps: Shop, Inbox, Point of Sale, Shopify Mobile, and Local Delivery. These apps represent different business domains, but they often have shared pieces of functionality like login or foundational blocks they build upon. Wouldn’t it be great to leverage development speed and focus on important product features by reusing code other teams have already written? Sure, but it might be a big and time consuming effort that discourages teams. Usually, contributing to a new repo is more tedious and error prone in comparison to contributing to an existing repository. The developer needs to create a new repository, set up continuous integration (CI) and distribution pipelines, and add configs for Jest, ESint, and Babel. It might be unclear where to start and what to do.

My team, React Native Foundations, decided to invest in simplifying the process for developers at Shopify. In this post, I'll walk you through the process of extracting those shared elements, the setup we adopted, the challenges we encountered, and future lines of improvement.

Shard Balancing: Moving Shops Confidently with Zero-Downtime at Terabyte-scale

Shopify’s infrastructure supports over 1.7 million merchants during their entrepreneurship journey. A key component of the current infrastructure is the underlying fleet of MySQL database shards that together persist every shops’ critical data. As traffic patterns change and new merchants onboard onto the platform, it’s possible that resource intensive shops end up living in the same shards. Certain database shards become unbalanced in their database utilization, shop traffic, and load. It’s important to ensure the shards remain well-balanced to mitigate risk of database failure, improve productivity of the wider infrastructure, and ultimately guarantee buyers can always access their favorite shops. This post explains how we’re able to balance our MySQL shards by migrating shops across shards—entirely online and with virtually zero consumer-facing downtime.

Making Shopify’s Flagship App 20% Faster in 6 Weeks Using a Novel Caching Solution

We built a custom write-through cache for the Shop app's home feed that reduced database load by 15% and overall app latency by about 20%.

Introducing LinNét: Using Rich Image and Text Data to Categorize Products at Scale

We reevaluated our existing product categorization model to ensure we’re understanding what our merchants are selling, to build the best products that help power their sales.

Other Driven Developments

Mental models within an industry, company, or even a person, change constantly. As methodologies mature, we see the long term effects our choices have wrought and can adjust accordingly. As a team or company grows, methodologies that worked well for five people may not work as well for 40 people. If all employees could keep an entire app in their head, we’d need fewer rules and checks and balances on our development, but that is not the case. As a result, we summarize things we notice have been implicit in our work.

Rate Limiting GraphQL APIs by Calculating Query Complexity

Rate limiting is a system that protects the stability of APIs. GraphQL opens new possibilities for rate limiting. I’ll show you Shopify’s rate limiting system for the GraphQL Admin API and how it addresses some limitations of common methods commonly used in REST APIs. I’ll show you how we calculate query costs that adapt to the data clients need while providing a more predictable load on servers.

Pagination with Relative Cursors

Using incremental page numbers for pagination scales poorly, so to solve this, Shopify uses relative cursor pagination to deliver faster queries.

Simplify, Batch, and Cache: How We Optimized Server-side Storefront Rendering

In the previous post about our new storefront rendering engine, we described how we went about the rewrite process and smoothly transitioned to serve storefront requests with the new implementation. As a follow-up and based on readers’ comments and questions, this post dives deeper into the technical details of how we built the new storefront rendering engine to be faster than the previous implementation.

To set the table, let’s see how the new storefront rendering engine performs:

  • It generates a response in less than ~45ms for 75% of storefront requests;
  • It generates a response in less than ~230ms for 90% of storefront requests;
  • It generates a response in less than ~900ms for 99% of storefront requests.

Thanks to the new storefront rendering engine, the average storefront response is nearly 5x faster than with the previous implementation. Of course, how fast the rendering engine is able to process a request and spit out a response depends on two key factors: the shop’s Liquid theme implementation, and the number of resources needed to process the request. To get a better idea of where the storefront rendering engine spends its time when processing a request, try using the Shopify Theme Inspector: this tool will help you identify potential bottlenecks so you can work on improving performance in those areas.

How Shopify Uses WebAssembly Outside of the Browser

At Shopify, we’re keeping the flexibility of untrusted Partner code, but executing it on our own infrastructure with WebAssembly.

Shopify第2篇:怎么让170万商户每月交35刀美金?

对于中小商家,SaaS企业会提供标准化的产品,价格较为便宜;也有针对大企业的解决方案,比如Shopify提供Shopify Plus,2000美金一个月起.....

首页 - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-21 20:16
浙ICP备14020137号-1 $访客地图$