shopify graphql vs rest

By contrast, OData tells you exactly how it’s going to behave when you use the orderBy query parameter because its behavior is defined as part of the specification. Facebook famously said in one of their earlier talks on GraphQL that they didn’t version their API, and have never had a breaking change. gRPC's core team rules the code generation with an iron fist, which is both a pro and a con. ORDS (Oracle REST Data Services) is the Oracle REST service which delivers similar standardization for Oracle-centric applications. I'd call it completely lacking, not concise. Sure, but that utility also carries massive costs: the infrastructure and tooling required to work with those schema definitions, especially as they change over time. No way! Copyright © 2021 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved. I disagree that tooling is required to work with them in the GraphQL case - you still end up getting and sending JSON in the vast majority of cases. So while GraphQL gives you the ability to determine from the metadata what fields and functions are available, you still don’t know what they mean semantically. Build a Shopify App with Node and React; Make your first GraphQL Admin API request; Make your first REST Admin API request; Authenticate a public app with OAuth; Authenticate a custom app with OAuth; Add a new app extension; Build a sales channel app; Create a checkout with Storefront API Which is quite a bit more powerful than any custom solution. Does grpc-web work well? I think your instinct to reach for the straightforward solution is good. The other issue with JSON-RPC is, well, json. One thing to note about this comparison is the maturity of the specification. Big missing con for GraphQL here — optimization. As a team grows these sorts of standards emerge from the first-pass versions anyway. Also, there are a lot of OData clients that can help you get up and running with the OData service quickly and easily. Using prost directly was a little rough, but with tonic on top it's been a dream, Swift is at least supported via Objective-C, and swift-grpc looks solid. I agree with your preference. andrewingram 1 hour ago. That decision was reverted for proto 3.5. Slovakia Toptal Member Since May 10, 2017. The overall verbosity of a GraphQL queue tends to not be a huge issue either, because in practice individual components are only concerning themselves with small subsets of it (i.e fragments). It would be simpler and far more powerful. https://web.archive.org/web/20210315144620/https://www.danha... No mention of what I see as the biggest con of GraphQL: You must build a lot of rate limiting and security logic, or your APIs are easily abused. In this case you can decide to not put them in the GraphQl response but instead put a REST uri of them there and then have a endpoint like `/blobs/` or `/blobs/pictures/` or similar. I don't entirely disagree that gRPC tooling is nicer and more complete in some areas, but there's some misconceptions here. I like oData v4 and I try to use it when it is opossible. Seconded. The focus is on achieving interoperability across APIs for analytics, integration and data management. Don't you get the same benefit by writing a Swagger spec? Really, I don’t gRPC and GraphQL should even be compared since they support radically different use cases. It’s important to note that REST is an architectural style, not a standard. gRPC's ecosystem doesn't really have that pain point. Facebook developed GraphQL as a response to the less flexible REST convention. Of course this only works if you don’t reserialize it. There's many more things that can be done but you get the idea. Because if you use HTTP caching, you can use a CDN with 100s of global locations. While this entails an additional round-trip and is properly not the best usage for some cases for others like e.g. As much as I love a well-designed IDL (I'm a Cap'n Proto user, myself), the first thing I reach for is ReST. It’s easier to use a web cache with REST vs. GraphQL. It enables developers with SQL and other database skills to build enterprise-class data access APIs to Oracle Database that today’s modern, state-of-the-art application developers want to use, and indeed increasingly demand to use, to build applications. This has been a massive time sink in the past where you have to investigate nginx/*cgi, sonic/flask/waitress/wsgi, rails, and hundreds of other things for every single language stack each with their own gotchas. There’s a laundry list of applications that are already OData-capable, as well as OData client libraries that can help you if you’re developing a new application. Rust has tonic, which I've used to good effect as both as a client and server. - Load balancing > cannot easily inspect and debug your messages across your infrastructure without a proper protobuf decoder/encoder. I can google and get tens or even hundreds of articles about GraphQL, but I won't get the "points and counter points: a discussion that I get here. Similarly, for gRPC, you have a few questions: Do you want to do a resource-oriented API that can easily be reverse proxied into a JSON-over-HTTP1.1 API? Additional GraphQL con: it requires some thought and planning in order to ensure data is cacheable in CDNs and other reverse proxies. We contrasted the differences between OData, GraphQL and ORDS, which are standard APIs and services for querying and updating data over the Internet. its already conflating transport & serialization. We are stuck using it in go because another (Java-heavy) team exposes their data via it, and the experience has been awful even for a simple service. If missing, sends a standard graphql as POST. This is fine at a small scale. Sixty groups at Oracle use ORDS, including Oracle Database, Times Ten and NoSQL. by Maryam Fekri; Jan 22, 2021; Development; Apache Beam for Search: Getting Started by Hacking Time. You can even build tooling to automate very complex things: - Breaking Change Detector: https://docs.buf.build/breaking-usage/, - Linting (Style Checking): https://docs.buf.build/lint-usage/. it makes the life of designing an easy to use (and supposedly more efficient) API easier (for the FE) but much less so for the backend, which warrants increased implementation complexity and maintenance. Timestamp is fundamentally flawed and should only be used in applications without any kind of performance/efficiency concerns, or for people who really need a range of ten thousand years. Definitely not ready yet, and the scope may be large enough that it won't ever get there. These were basic principles I put in place at a previous company that had a number of API-only customers. And I still usually run it through the whole Rails controller stack so I don't drive myself insane. Buckle up, this is going to be a long comparison. It's certainly not the case that the benefits always, or even usually, outweigh those costs. Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences. Also, many of its design choices are fundamentally in tension with statically typed languages. It’s powerful, but using it means your application is tightly coupled to how that particular GraphQL service is implemented. API 101: SOAP vs. REST; Introduction to GraphQL; Comparing API Architectural Styles: SOAP vs REST vs GraphQL vs RPC; Even though GraphQL is on the rise and is being adopted by bigger and bigger companies, including GitHub and Shopify, the truth is that the majority of public APIs are still REST APIs. Not REST as in resource modelling but simply sending a request serialized as a JSON object and getting a response back as a JSON object. Of course json + compression is a bit more cpu intensive than protocol buffers but it's not having an impact on anything in most use cases. How much do you want to lean toward resource-orientation compared to RPC? It's ugly: ... edit: the page you linked to has similar rate limiting behavior for both REST and GraphQL lol. But they have one for Kotlin... Scala has several (approximately one per effect library): That's actually cool. You basically get it for free with REST. Too concise. Some target platforms even have multiple code generators representing different people's vision for what the code should look like. On the upside, it means that things tend to behave very consistently, and all the official code generators meet a very high standard for maturity. (not small) file up-/down-load it is quite nice as this is a operation often explicitly triggered by a user in a way where the additional roundtrip time doesn't matter at all. But gRPC isn't just protocol buffers. Also by people that have heard of relay but already have an existing codebase. Rate limiting and security are trivial these days, with an abundance of directive libs available, ready to use out of the box, and every major third party auth provider boasting ease of use with common GraphQL patterns. Guarding against this with the other two API styles can be a bit more straightforward, because you can simply not create endpoints that translate into inefficient queries. I kind of feel that the server itself should protect against attacks like that. One fairly interesting denial of service vector that I've found on nearly every API I've scanned has to do with error messages. REST-compliant web services allow requesting systems to access and manipulate textual representations of web resources using a uniform and predefined set of stateless operations. $120 billion: spent on Shopify’s platform in 2020. The biggest problem leading to this headache with REST APIs is that all of the fields are returned when you query an endpoint. This article compares standard APIs and services to query data over the internet for analytics, integration and data management. GraphQL is very close to what you've described, with some more defined standards. This is basically the reason every field in proto2 will be marked optional and proto3 is “optional” by default. GraphQL has addressed the problem of API versioning and maintenance by forcing clients to specify exactly which fields they require. It’s also easier to implement new fields and content types as your system matures. With more than 17 years of experience in front-end development — including an exclusive focus on Shopify theme development and design since 2017 — I’ve proven to be among the most skilled developers you can trust with your Shopify store. This reduces response size and processing in an application. Progress collects the Personal Information set out in our Privacy Policy and Privacy Policy for California Residents and uses it for the purposes stated in that policy. So when it comes to GraphQL vs. REST, which API is the best for your client’s needs? But if you can further point out that GraphQL has more functionality than is required, then you can basically make a YAGNI-style argument against GraphQL. reply. Shopify POS allows merchants to use Shopify as a point-of-sale app on a smartphone or tablet, or to use dedicated Shopify hardware. What if someone just made this direct sql interface safe/restricted? I rather see it as "folks in HN discussing about GraphQL today!". I don't think its completely unreasonable to look at a definition like REST and be dogmatic about certain aspects like HATEOAS which are arguably absolutely central to the original concept. Of course, the same could happen for standard REST as well, but I think the foot guns are more limited. The first option means you need to manually ensure that the client and server remain 100% in sync, which eliminates one of the major potential benefits of using code generation in the first place. API developers can proactively reach out to known consumers of fields to migrate off of deprecated fields. Specifically, the Scrooge (or Finagle) generator for Scala and Java supported different versions of Thrift libraries. Roy Fielding (author of the original REST dissertation): "A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). IDLs represent substantial complexity, and complexity always needs to be justified. GraphQL can also be a bit awkward for people who are used to dealing with web services because in order to query data, you don’t do a GET operation, which is how you would get results from a normal REST web service. Hasura makes that pretty easy as can be seen here: That's an end user experience on a platform. Apache Thrift is another great way of server-server & client-server communication. Tried it. OpenAPI is much more, well, open. I saw several Q&As on this topic and tried both approaches. Mind you having tried to create 'pure' HATEOAS REST API I think I prefer the contemporary approach! The overhead of GraphQL doesn't make it worth using at that scale. > unless you have Google's size microservices and infrastructure. GraphQL is much like REST in that it defines the way to interact with a web service, but it doesn’t tell you what the service does. And this behavior can be different on an implementation by implementation basis. 1. https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... Edit: Pretty much every REST API I see these days explains how to construct your URLs to do different things - rather than treating all URLs as opaque. Sorry, they were addressing the two points from the comment above. View Juraj. GraphQL also doesn’t tell you about primary keys and ORDS doesn’t tell you about nullability. And I wholeheartedly agree that the lack of consistent implementation is a problem in openapi. Sumit has been working in the data access infrastructure field for over 10 years servicing web/mobile developers, data engineers and data scientists. It's a shame - the client generation would have been a nice feature to get for free. For most users, the relative merits of these three considerations are going to be a much bigger deal than the question of whether or not to use JSON as the serialization format. Personally I prefer to have explicit control over the caching mechanism rather than leaving it to network elements or browser caching. I think it’s because of the robust discussion in these comments. It's ugly: https://shopify.dev/concepts/about-apis/rate-limits. > The flip side (IMHO, at least), is that simple build-chains are underrated. - Standard Authentication and identity (client and server) Jokes aside, isn’t this ultimately what we are all looking for? Both are terrible, IMO. In my opinion, it makes very little sense to compare GraphQL to REST from a client perspective - if you are only going to be hitting a single API endpoint, use REST (or gRPC I guess). However, it does not provide a mechanism to indicate that fields are deprecated. There’s no way to generically describe how it works. Finally, gRPC's proto files can import each other, which offers a great code reuse story. It's quite simple (easier in my opinion than in REST) to build a targeted set of GraphQL endpoints that fit end-user needs while being secure and performant. [0] https://jsonapi.org/format/#fetching-includes. You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info. a big thing not called out here that both gRPC and GraphQL natively do, but that REST does not natively do, is schema definition for the payloads. I've been in multiple shops where REST was the standard -- and while folks had interest in exploring GraphQL or gRPC, we could not justify pivoting away from REST to the larger team. You can manually adjust it to not do that, but it doesn't seem like a good design to me. Since it is a standard, predefined query you can cache the results. I personally like that, since it helps keep a cleaner separation between "my code" and "generated code", and also makes life easier if you want to more than one service publishing some of the same APIs. Looking at the SQL and metadata, does not look all that simple for such a simple case. Could you add some links? As a computer science student who tries to keep up with best practices, corporate adoption of technologies, and general trends in the industry, this is something I can't really get anywhere else. The browser supports built in caching without requiring a specific library; additionally the infrastructure of the web provides this as well. In GraphQL you have to essentially predefine all the queries in order to achieve the same cache-ability of responses. It's massively useful to know exactly what 'type' a received payload is, as well as to get built-in, zero-boilerplate feedback if the payload you construct is invalid. It lets you query the API with the fields and relationships you need for each occasion, almost like what you can do directly with a database. Let’s install the React Native on to our system. Wait, thrift interoperates poorly with Java? Just gRPC in/out of the browser. In my personal experience the other huge benefit is you now have a source of truth for documentation. (...) Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. On the downside, they tend to all be coded to the gRPC core team's standards, which are very enterprisey, and designed to try and be as consistent as possible across target languages. Not loading for me (PR_CONNECT_RESET_ERROR on Firefox, ERR_CONNECTION_RESET on Chrome). If so then you gain the ability to access it from Web clients, but may have to limit your use of some of gRPC's most distinctive features. I'd argue what you see as the biggest con is actually a strength now. Basically, you ask the server to "run standard query 'queryname'." Shadow DOM: A set of builtin JavaScript APIs for creating and attaching a private DOM tree to an element. Surprised no one has mentioned what (to me) is the killer feature of REST, JSON-patch [1]. I can't disagree there, and for all the work MS is putting into it right now for it in dotnetcore - I don't understand how they can have this big a blind spot. When you're many devs, many APIs, many resources, it really pays to have a consistent, well-defined way to do this. This is a guide to the top differences between SoapUI vs Postman. I’d be interested to see an analysis of major websites usage of HTTP caching on non-static (i.e. So we had to write our own code generator templates. Between soap and grpc, grpc is the better choice at this point. On their own, such arguments are indeed not useful. E.g. This description conflates them, when really there are three distinct ways to use JSON over HTTP/1.1: Actual REST (including HATEOAS), the "openAPI style" (still resource-oriented, but without HATEOAS), and JSON-RPC. REST can also return protobufs, with content type application/x-protobuf. I'm going to say install Shopify's GraphiQL app following this link. I feel like this is rather shallow, and, by focusing so heavily on just the transport protocol, misses a lot of more important details. gRPC has good support for mixing and matching the two, and making an intentional decision about how you do or do not want to mix them is again probably a much bigger deal in the long run than the simple fact of using protocol buffers over HTTP/2. Maybe the problem was related to having a project with both Java and Scala and over the wire interop would have been fine--don't remember the exact details. pictures are cached). REST API Industry Debate: OData vs GraphQL vs ORDS. > JSON objects are large and field names are repetitive. You have to limit not just number of calls, but quantity of data fetched. The official grpc-web [1] client requires envoy on the server which I don't want. https://andrewingram.net/posts/demystifying-graphql-connecti... https://github.com/protocolbuffers/protobuf/releases/tag/v3.... https://www.apollographql.com/docs/apollo-server/performance... https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... https://github.com/grpc/proposal/blob/master/A16-binary-logg... https://www.apollographql.com/docs/apollo-server/performance, https://github.com/jsmouret/grpc-over-webrtc, https://news.ycombinator.com/item?id=25600934, https://github.com/sudowing/service-engine-template. Developed internally at Facebook in 2012, before public release in 2015, GraphQL is a data query language deployed at companies such as Facebook, Shopify and Intuit. Though there are also solutions like Hasura where GraphQL makes sense at approximately any scale because it allows you to create an API from nothing in about 10 minutes. OData is more flexible in that queries can be easily written to return all fields. It does support a lot of the popular languages now. (In our case, app servers were extremely fat, slow, and ridiculously slow to scale up.). They're just one way to do pagination. youtube playlist: So yeah it might be "a lot" data were it RESTful, but we're not going to bottleneck on a single indexed query and a ~10MB payload. Each of these APIs are advancing to solve this, however GraphQL and ORDS don’t tell you scale and precision of data, whereas OData does. Recommended Articles. For my part, I came away with the impression that, at least if you're already using Envoy, anyway, gRPC + gRPC-web may be the least-fuss and most maintainable way to get a REST-y (no HATEOAS) API, too. The strength and real benefit of GraphQL comes in when you have to assemble a UI from multiple data sources and reconcile that into a negotiable schema between the server and the client. Edges and Nodes are elegant, less error prone and limits and skips, and most importantly - datasource independent. Since your API definition. It doesn't have to be confined to JSON. I'll second that. Value judgements aside, yes, you _could_ generate from swagger but with gRPC its built in and consistent. That's fine with a 100% trusted client, but if you're using this for a public API or web clients, you can easily be DOSed. I posted in verbose detail about that project a few months ago, so here I'll just provide a summary: The project auto provisions REST, GraphQL & gRPC services that support CRUD operations to tables, views and materialized views of several popular databases (postgres, postgis, mysql, sqlite). Client developers must process all of the fields returned even if they do not need the information. Sometimes you really want to be explicit rather than implicit, even if being explicit is kind of boring.). > unless you have Google's size microservices and infrastructure gRPC (with protocol buffers) is just tedious. e.g. Not for me. > Of course, if the argument is simply that it tends to be more challenging to manage performance of GraphQL APIs simply because GraphQL APIs tend to offer a lot more functionality than REST APIs, then of course I agree, but that's not a particularly useful observation. by Duncan Uszkay; Dec 18, 2020; Development; Simplify, Batch, and Cache: How We Optimized Server-side Storefront … Originally developed by Microsoft in 2007, OData is an OASIS standard REST API and is established among companies such as Microsoft, SAP, CA, IBM and Salesforce. That creates a larger barrier to entry for service developers. Indeed having no API at all would further reduce the challenge! I wrote one, it's not simple (. One thing that people seem to gloss over when comparing these is that you also need to compare the serialization. With required, you can never retire a field, and older service/client would not work correctly. I've seen v3 share at least models across multiple files - it can definitely be done. High traffic global/unauthenticated reads, especially those that never change, should get cached by the frontend (of the "backend", not the SPA) reverse proxy and not tie up appservers. And also not have the silly overhead of JSON-RPC. So, you're more likely to find a library that meets your own aesthetic standards, possibly at the cost of it being less-than-perfect from a technical perspective. I don't usually find restful api gen to be quite as seamless. A curated list of awesome things related to GitHub Actions. As soon as you start implementing field/resource customizability in a REST API you have roughly the same problems guaranteeing performance. However, there’s nothing in GraphQL that tells you what you can pass in for these arguments and how the values specified as arguments causes the function to behave. GRPC needs to support the language you're using. So there's a certain art to making sure you don't accidentally DOS attack yourself.