Apollo iGDSis in the Road Transport Tech Industry

Apollo iGDS

The Scene I am doing some experimentation and I want to try something with GraphQL on a React project. I already know something about GraphQL but I never really used it by myself. I begin searching for a good GraphQL backend and I settle with which seems the best out there at this moment: has a lot of guides and tutorials, it integrates with other services, it is very flexible and it’s free for developers. Bright green lights! Graphcool Graphcool has quickstart guides for both and Relay but I already decided what to use so I begin yarn-ing what it needs on my React project: Apollo "apollo-client": "^0.8.1","graphql-tag": "^1.2.3","react-apollo": "^0.9.0", The Mission I think about something not so original but always fun to work with: music bands and albums and songs and stuff.. always more exciting than :) Northwind Traders or Contoso Ltd. So I just want to read/write data from/to Graphcool. In GraphQL when you want to read you need , when you want to write you need . Queries Mutations I am not writing about queries because the focus of this story is about nested mutations and because queries are well explained and I got no problems during the implementation. LET THE PARTY BEGINS With the Graphcool “Console” (an awesome interface for db modelling) I created a rough-and-ready structure. type Band {name: String!country: Stringwebsite: Stringmembers: [Person]contact: Personalbums: [Album]} type Person {firstName: String!lastName: String!} type Album {name: String!year: Int!songs: [Song]} type Song {trkNr: Inttitle: String!duration: String} As you can see we nested two arrays on two different levels starting from the albums field of the Band model. So, to be clear, I want to store all this info using some data about STORMO music band, and I want to do it with a single mutation! The Problem The party suddenly crashes (and STORMO stop playing!) when I realize I don’t know how to create nested mutations, nor the (anyway very good) Apollo documentation can help me out. Moreover I was brave enough to use arrays and now my eyes are lost in the window… the physical one!! The Help After a few not-worth-mentioning tries i decide to use where I begin stalking in the general channel. the salvific Graphcool slack support , from Graphcool staff begins to help me in no time and when i finally explain in a comprehensible way my situation, he hands me… Nilan Marktanner The Solution Thanks to Nilan I relaize three things: the importance and, yes, the beauty, of a timely assistance nested mutations on Graphcool are improved and easyer to use when you write a nested mutation there is no need to write about the types of the nested objects! and that was exactly what i needed. Code Time The mutation I have to build mutation {createBand(name: "Stormo"country: "Italy"website: " "members: [{firstName: "Luca"lastName: "Rocco"}, {firstName: "Federico"lastName: "Trimeri"}, {firstName: "Giacomo"lastName: "Rento"}, {firstName: "Gabriele"lastName: "Coldepin"}]contact: {firstName: "Giacomo"lastName: "Rento"}albums: [{name: "SOSPESI NEL VUOTO BRUCEREMO IN UN ATTIMO E IL CERCHIO SARÀ CHIUSO"year: 2014songs: [{trkNr: 1title: "In Volo"duration: "02:50"}, {trkNr: 2title: "Supernova"duration: "02:10"}, {trkNr: 3title: "Fuga"duration: "01:24"}, {trkNr: 4title: "Perchè La Bambina Cade"duration: "02:46"}]}, {name: "7"year: 2009songs: [{trkNr: 1title: "Incosiderata Putrefazione"duration: "03:18"}, {trkNr: 2title: "Abbandono La Mia Volontà"duration: "03:20"}]}, {name: "Self-Titled EP"year: 2007songs: [{trkNr: 4title: "Quando Non Ci Sei"duration: "02:08"}, {trkNr: 5title: "Al Punto Di Non Ritorno"duration: "04:36"}]}]) {idmembers {id}contact {id}albums {idsongs {id}}}} https://stormo.bandcamp.com/ Using Apollo Client, I specify input arguments with GraphQL variables, so let’s see how it looks in this case: import gql from 'graphql-tag'; const BandMutation = gql`mutation ($name: String!$country: String$website: String$Members: [Person]$Contact: Person$Albums: [Albums]) {createBand(name: $nameCountry: $CountryMembers: $MembersContact: $ContactAlbums: $Albums) {idmembers {id}contact {id}albums {idsongs {id}}}}`; Using a form I compose the data like this: (but pay attention, apollo wants this object called ‘ ’ and nothing else!) variables const variables = {name: "Stormo",country: "Italy",website: " "members: [{firstName: "Luca",lastName: "Rocco",}, {firstName: "Federico",lastName: "Trimeri",}, {firstName: "Giacomo",lastName: "Rento",}, {firstName: "Gabriele",lastName: "Coldepin",}],contact: {firstName: "Giacomo",lastName: "Rento",},albums: [{name: "SOSPESI NEL VUOTO BRUCEREMO IN UN ATTIMO E IL CERCHIO SARÀ CHIUSO",year: 2014,songs: [{trkNr: 1,title: "In Volo",duration: "02:50" ,}, {trkNr: 2,title: "Supernova",duration: "02:10" ,}, {trkNr: 3,title: "Fuga",duration: "01:24" ,}, {trkNr: 4,title: "Perchè La Bambina Cade",duration: "02:46",}]}, {name: "7",year: 2009,songs: [{trkNr: 1,title: "Incosiderata Putrefazione",duration: "03:18",}, {trkNr: 2,title: "Abbandono La Mia Volontà",duration: "03:20",}]}, {name: "Self-Titled EP",year: 2007,songs: [{trkNr: 4,title: "Quando Non Ci Sei",duration: "02:08",}, {trkNr: 5,title: "Al Punto Di Non Ritorno",duration: "04:36",}]}]} https://stormo.bandcamp.com/ Finally, inside my React component I can use all of this to send my data to Graphcool import React, { Component } from 'react';import { graphql, compose } from 'react-apollo';import BandMutation from './../graphql/BandMutation'; class CompanySettings extends Component {constructor(props) {super(props);this.sendData = this.sendData.bind(this);} sendData(variables) {this.props.CreateBand({ variables }).then((response) => {window.alert('You submitted data about a new band');}).catch((e) => {console.error(e);});} render() {return <FormCreateBand onSubmit={this.sendData} />;}} export default compose(// with this I can use the mutation with this.props.CreateBandgraphql(BandMutation, { name: 'CreateBand' }),// I can write here other mutations or queries)(CompanySettings); Conclus… But wait! This is the beginning actually GraphQL is not the future, is the present, and it’s soo disarmingly good, in loving memory of REST Graphcool is an awesome service and its staff is careful and hyperactive (i’m quite sure they don’t sleep neither) Was there some fatigue?… Yes, of course! But with this kind of fatigue, for every minute of time that you invest, you will save A LOT more later, it depends on the project. P.S. The party now is going crazy, thanks to Storm{O} !! is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

GraphQL nested mutations with Apollo: small fatigue, max gain

I first wrote a version of this article just over 16 months ago, and it’s pretty impressive how much the GraphQL community has achieved in that time. First of all, the question is no longer Apollo or Relay, but rather Apollo or does one even need a fancy client at all. If you’re just testing the waters with GraphQL and don’t want to change your existing app too much, you can just use in your component like so: really fetch fetch('/graphql', {  method: 'POST',  headers: {    'Content-Type': 'application/json',    'Accept': 'application/json',  },  body: JSON.stringify({query: "{ hello }"})})  .then(r => r.json())  .then(data => console.log('data returned:', data)); The main benefit to adopting a GraphQL client is the cache implementation. Using fetch is fine to begin with, but you don’t want to be using it in an app where users quickly jump between views. In we use Apollo to cache query results — which gives us quite a noticeable boost in performance. How it works in practice: OnlineOrNot User opens a list of their GraphQL applications -> this list gets cached User opens a list of tests -> client has already fetched data about the applications, so it adds the tests to each application User now visits their list of applications again -> no new GraphQL request is made, all results are already in memory Essentially, the more the user clicks around your application, the faster your user experience becomes. On Bundle size One of the biggest complaints I hear about adopting Apollo is the bundle size (Apollo Boost, the “easiest way to get started with Apollo Client” weighs in at 30.7 kB min+gzipped), so luckily there are also alternative lightweight clients to consider: No article on GraphQL clients would be complete without mentioning . Though Amplify does take an ‘everything but the kitchen sink’ approach to features, and you get included with it: AWS Amplify everything Authentication Analytics API GraphQL Client Storage Push Notifications Interactions PubSub Internationalization Cache Thus Amplify may not suit your needs unless you’re building a whole product experience that relies on GraphQL and don’t want to customise your approach. Why I like Apollo Client The setup is considerably easier than Relay — it involves installing one package, and adding the to the root of your React tree. ApolloProvider The API is nice — they have an equivalent to Relay’s QueryRenderer called that does what it says: Query <Query    query={gql`      {        rates(currency: "USD") {          currency          rate        }      }    `}  >    {({ loading, error, data }) => {      if (loading) return <p>Loading...</p>;      if (error) return <p>Error :(</p>;      return data.rates.map(({ currency, rate }) => (        <div key={currency}>          <p>{`${currency}: ${rate}`}</p>        </div>      ));    }}  </Query> It can be used to manage state in your React app — that is, you can directly write to Apollo’s Redux-like store and consume that data in another part of the React tree. Though with React’s new Context API, and React’s best practices of you probably won’t need it. Lifting State Up import React from 'react';import { ApolloConsumer } from 'react-apollo';import Link from './Link';const FilterLink = ({ filter, children }) => (  <ApolloConsumer>    {client => (      <Link        onClick={() => client.writeData({ data: { visibilityFilter: filter } })}      >        {children}      </Link>    )}  </ApolloConsumer>); Downsides to Apollo It’s huge. It weighs in at 10x more than the smallest GraphQL client I’d consider using, and 3x more than urql Quirks Apollo is not without quirks however: Since Apollo uses to build its cache, forgetting to include in your query can cause some interesting bugs and error messages id id Why I dislike Relay Setup The main benefit to using Relay is that doesn't get included in your frontend bundle, saving your user from downloading the whole GraphQL parser - it "pre-compiles" the GraphQL queries at build time. relay-compiler What annoys me about Relay is that it requires a fair bit of work to even add to a project. Just to get it running on the client side, you need to: add a relay plugin to your config .babelrc set up relay-compiler as a yarn script setup a “relay environment” (essentially your own utility to pass data to the relay-runtime), and fetch add components to the React Components you wish to pass your data to QueryRenderer On the server side, you need to: Ensure the IDs your app returns are unique across all of your types (meaning you can’t return nice ID values like , they need to be like ) 1, 2, 3 typename_1, typename_2 Developer Experience The developer experience itself is pretty unpleasant too — needs to run each time you modify any GraphQL query, or modify the schema. In large frontend teams this means teaching everyone to run every time you change branches in Git, since almost all of our work involves fetching data from GraphQL in some way. relay-compiler relay-compiler Quirks Being one of Facebook’s Open Source projects doesn’t necessarily mean issues get fixed quickly. Occasionally, things break in unexpected ways: Using an old version of graphql breaks : relay https://github.com/facebook/relay/issues/2428 Errors don’t get sent via the error object in GraphQL when using QueryRenderer, instead one needs to create an type, and send the errors through the data object: error https://github.com/facebook/relay/issues/1913 Originally published at onlineornot.com on December 15, 2018.

Apollo vs Relay Modern: Which GraphQL Client to consider using in 2019

Photo by Chris Kristiansen ( ) https://unsplash.com/@chriskristiansen Table of Contents Part I: Setup and displaying short URLs using GraphQL Part II: Creating short URLs Part III: Creating serverless function for hashing (this post) Part IV: Short URL stats (number of clicks, etc.) Part V: User authentication Part III: Creating serverless function for hashing In this post we are going to take the hashing function we implemented in the previous post and move it to the . Graphcool functions Functions need to be defined in the Graphcool service definition file ( ). Graphcool supports the following function types that can be invoked either as webhooks or as managed functions: graphcool.yml Before and after operations ( **operationBefore** / **operationAfter** ) For this to work, you need to specify the operation on a model for which the function should be invoked. For example: , or . An example for when this type could be used is if we wanted to implement a feature that prevents certain users from creating more than X number of links. We could use the on and run a function that checks how many links the user already created and either throw an error or allow the creation to happen. Link.update Link.delete Link.create operationBefore Link.create Subscriptions Subscription requires a subscription query that determines when the function should be triggered (e.g. when an object is created, updated or deleted). The backing function is then executed after the mutation happens. An example of this could be if we wanted to send a welcome email each time a new user signs-up. Resolvers Resolvers are the most powerful types as they allow you to come up with a new mutation and/or query definition. We will use resolvers in one of the upcoming post where we will create a mutation for signing up and logging in users as well as a query that returns a logged in user. To be honest, we could probably use all of the options above to implement our hashing function. In short, here’s how we’d do it: Option 1: Using operationBefore/operationAfter We could use either of these two options. We would need to modify the in to remove the variable as well as make the hash field optional in the schema. Next, we’d move the function to the backend to either update the created link with a hash (if we use ) or create a hash and return it for the mutation to complete if we use . CreateLinkMutation CreateShortLink.js $hash createHash operationAfter operationBefore Option 2: Using a subscription Just like we the above option, we need to remove the variable from and write a subscription query that fires when new Link is created — we already have that query, so we could update it like this: $hash CreateLinkMutation subscription NewLinkCreatedSubscription {Link(filter: { mutation_in: [CREATED] })node {id}}} In the handler function, we’d get the data returned from the subscription ( ), next we’d get the count of all links, create a hash and finally update the existing Link with this mutation: id mutation UpdateLinkWithHash($id: String!, $hash: String!) {updateLink(id: $id, hash: $hash) {id}} Option 3: Using a resolver With a resolver, we would extend our existing API with a new mutation called . The function that would be executed when this mutation is called would go through similar things as if we’d use a subscription. Function would get the number of created links, generate a hash and then return that generated hash. Then, we could call our existing CreateLinkMutation and pass in the hash we from the . createHashMutation createHashMutation Since we will use a resolver for authenticating users later, let’s use a to implement this — it is! subscription option 2 Move the hash function to subscription Follow the steps below to create a subscription and move the hashing function to the backend. Create the folder in your project root graphcool/src Add file with the following subscription that fires each time a link is created and returns its id: createShortLink.graphql subscription {Link(filter: { mutation_in: [CREATED] }) {node {id}}} 3. Add file that fires off each time a new link is created. createShortLink.js 4. Install the dependencies for subscription function by running the following command from the folder where file is: graphcool package.json $ npm install graphcool-lib --save 5. Update the to reference the graphql and js file we created: graphcool.yml functions:createShortLink:type: subscriptionquery: handler:code: src/createShortLink.graphql src/createShortLink.js 6. Deploy the changes and create the subscription: $ graphcool deploy... Subscription Functions createShortLink + A new subscription with the name `createShortLink` is created. A couple of small things before we try out the subscription: Remove function, variable from the mutation and from . Below is the updated file: createHash $hash GET_LINK_COUNT_QUERY CreateShortLink.js 2. Make the field in optional, by removing the exclamation mark: hash types.graphql type Link @model {id: ID! @isUnique url: String!description: String} hash: String Run the again to update the type and we are ready to test this out! graphcool deploy Fire up the web site ( ) if you don’t have it running already and try to create a new link — everything should work exactly like before, the only difference is that the hashing function is now being invoked as part of a subscription on the Link. To really make sure that this works, you can run to get the invocation logs from your function(s). It looks like this: yarn start graphcool logs Testing the function If there’s an error, you will also get error details in here. Second option for looking at the logs and function invocations is to go to the , click on the and then on the function to get all the logs. http://graph.cool Functions createShortLink Function overview on Graph.cool Another helpful command for testing the functions is the command from the CLI. Instead of going through our web site to create new links, we can directly send a JSON payload to the function like this: graphcool invoke-local $ graphcool invoke-local --function createShortLink --json event.json Where can look like this: event.json {"data": {"Link": {"node": {"id": "LINK_ID"}}}} This way you can test your function for bunch of scenarios that might be hard to test through the web site — e.g. invalid payloads, non-existent link IDs, etc. Coming up In the next post of the series we will work on getting some short URL stats — number of clicks. In order to do that, we will have to come up with a handler for links. For example: if we generate hash “ABC123”, we will need to write some code that’s going to execute when user visits “http://localhost:3000/ABC123” and translate that hash to an actual link and redirect the user to it. Once we have the handler we can start collecting click stats. Thanks for Reading! Any feedback on these series is more than welcome! You can also follow me on and . If you liked this and want to get notified when other parts are ready, you should subscribe to ! Twitter GitHub my newsletter

Building URL shortener using React, Apollo and GraphQL — Part III

The Ultimate List of ICO Pools in the Bear Market — Q4 2018

This is the first post in the . Surprisingly, this post does not talk about itself, but about the problems it solves. And they mostly boil down to REST. Dive Into GraphQL Series GraphQL Update 25/09/17: Fix inaccuracies in the way multiple HTTP requests affect browser performance, and missing HTTP/2 mention. REST Unlocked API Centric Architectures First, nothing is wrong with REST . REST was a perfectly valid solution to the problem of building API centric architectures. Before REST, exposing a (SOAP) web service required complex tooling, hours of configuration, and a very large manual. And consuming such a web service required proprietary SDKs, resource intensive preparation and validation, and a very large manual, too. At the time, consuming a web service from a browser wasn’t even conceivable (think parsing XML WSDL with JavaScript) . per se except for Microsoft API-centric architecture REST, invented in 2000 and , shined because of its simple syntax. REST made requests and responses easy to build and parse, which is why frontend and backend developers around the world adopted it quickly. REST was also stateless and cacheable, which made scaling a piece of cake. It worked so well that today, API centric architectures are everywhere, and REST is the tooling of choice. popularized in 2007 But the world has changed since 2007. And the few shortcomings of REST, which were a good trade-off back then, are now a big pain for productivity, performance, and maintainability. Let’s see why. The Internet is Now Mobile In 2015, Google announced that . Since then, mobile Internet consumption has progressed steadily as developing countries jumped on the mobile Internet bandwagon, skipping cable connection altogether. So let’s face it: the web apps that we’re building today will be mostly used on mobile devices, and not on WiFi. for the first time, it had received more searches from mobile devices than from desktop Mobile devices over 4G or 3G are slower than on WiFi, because oscillates between 100ms and 600ms on 4G (up to 3500ms on 3G), and also because the quality of mobile connections varies a lot, which affects throughput in addition to latency. the latency overhead of radio communication For a single HTTP request, the response time dangerously approaches 1 second, which is the according to UX expert Jakob Nielsen. That means that the maximum number of HTTP requests a mobile app can make without losing the user’s attention is . user’s flow of thoughts limit one Let’s not forget battery life. Radio communications are power hungry, so mobile devices turn off the device radio as soon as possible, losing the channel they had established with the radio tower. To make a new HTTP request, a mobile device must wake up the radio, and request some bandwidth to the radio tower. This can drain the battery pretty quickly if app designers don’t count their HTTP requests. API-centric applications particularly suffer from latency and battery life on mobile, because they query their REST backend like crazy. Service-Oriented Architectures Suck (for Clients) Imagine a Twitter-like mobile application using a REST API for backend. Let’s list the resources the application must fetch to display the main page: REST backends expose . So the mobile app must send requests to several endpoints: one resource per endpoint to grab the current user name and avatar GET /user to get the number of unread notifications GET /notifications to get the list of the latest 20 tweets GET /tweets to get the profile of the authors of the latest 20 tweets GET /users?ids=[123,456,789,...] to get stats of the latest 20 tweets GET /tweet_stats?ids=[123,456,789,...] to send the view stats for the tweets displayed on screen POST /views That’s 6 HTTP requests — not even counting the requests for the avatar images, or the embedded media. Request 4 and 5 must wait the return from request 3. So that simple page will require way more than 1 second to grab the data it needs, even though mobile browsers can make between 4 and 6 concurrent HTTP requests. Besides, web and mobile apps tend to use more than one (understand: more than one HTTP domain). It’s very common to see applications rely on different REST providers for , , , , etc. The latency problem becomes even more painful in this case, because each new domain requires a specific DNS lookup, and the HTTP client can’t share keepalive connections between domains. service provider authentication avatars comments analytics To summarize, the main downside of REST is that it makes clients slow by default, especially on mobile. Grouping Requests Requires Work One solution is called . The idea is to request several related resources from one single endpoint, hoping the server knows the relationship between the two. Something like: data inclusion GET /tweets?include=authors,stats This allows to merge requests 3, 4 and 5, but that’s all. Data inclusion doesn’t allow to request of unrelated data (like tweets and notifications). aggregates In 2013, Facebook introduced another solution. They called it . It’s a REST endpoint where you can send several sub-requests in the query parameter: the Batch endpoint batch curl \    -F 'access_token=...' \    -F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/friends?limit=50"}]' \    https://graph.facebook.com Internally, the Facebook server queries their data stores, and groups the results into a single JSON response: [    { "code": 200,      "headers":[          { "name": "Content-Type",            "value": "text/javascript; charset=UTF-8" }      ],      "body": "{\"id\":\"…\"}"},    { "code": 200,      "headers":[          { "name":"Content-Type",            "value":"text/javascript; charset=UTF-8"}      ],      "body":"{\"data\": [{…}]}}] For purists, this batch endpoint is not RESTful at all, since it doesn’t really expose a . In addition, it doesn’t work when you need to pipe the response of one call (e.g. the list of tweets) to another one (the tweet authors profiles). resource Lastly, implementing the batch endpoint strategy takes time. It’s basically like developing a . I know it because marmelab has developed a Node.js middleware that does just that, called . That’s a component that every application developer should include in their REST server in order to reach a decent level of performance. That’s why developing a fast mobile app is so expensive. proxy server koa-multifetch No Standard Means Too Many Standards REST is not a standard, it’s an architectural style, a set of loose principles. These principles leave a lot of latitude to developers for implementation. For instance, can be either 200 or 204. As for pagination, you can use either a query parameter, a header, or, why not, and . The lack of unique REST standard for queries and responses caused the : Open API, OData, Hydra, JSend, etc. the recommended HTTP response code for a DELETE request page Content-Range limit offset explosion of REST standards When you need to query a web service, you can’t just use a standard REST client, because . You must either build a custom REST client from scratch, or tweak . Either way, this takes time. And when you need to develop a web service backend, you can’t just use the REST framework for your language. You must first spend a week in discussions with all the developers and software architects around you, and try to decide which REST flavor you should use. Oh, and don’t get me started on content type negotiation or . there is no such thing as a standard REST client a highly configurable and highly complex general purpose REST client HATEOAS The open-source boom has only accelerated the trend: Today, if you need a REST library, you have to choose from a heck of a lot of options. For JavaScript alone, there are . over 900 rest client npm packages So yes, freedom leads to diversity, but in the case of data communications over the Internet, diversity means waste. The lack of REST standard impacts the speed of development a great deal. Frontend And Backend Developers Need A Contract REST doesn’t have the notion of schema, a contract that describes exactly what a web service is supposed to return. Just like with standards above, the absence of schema leads to the multiplicity of possible documentation formats: JSON Schema, RAML, Swagger, etc. In many companies, backend developers still use a Word document to describe the resources and fields of their API. There are so many things to describe in an API contract that hand-made specifications are often incomplete. They lack description of error cases, data types, boundaries for arguments, etc. And they take ages to write, so they are always outdated. The thing is, without a clear contract describing the API, frontend and backend developers must make assumptions until they plug their components together. The more assumptions they make, the longer the integration phase lasts. The absence of a single schema in REST causes delays in development and frustration to developers. Agile Leads To Bloated Response APIs tend to change over time. But if the server API changes, all the consumers break. The usual solution is called : the server exposes several versions of the web service, and for a given version, the API never changes. Of course, , but we’ve already talked about that. As for the service consumers, they should be informed about the new release, and spend time updating their API calls. versioning there is no standard for REST versioning However, Agile software development leads to shorter release cycles. These days, . Asking developers to change the code of their service consumers so often is not an option. a popular web service can easily change several times a month That’s why some APIs don’t use versioning but instead. The idea is to a field in a resource response, but a new field instead. For instance, imagine that you’ve developed the response for a request as follows: evolution never remove or modify always add GET /users/:id {    "id": 123,    "name": "John Doe"} Then a Product Manager comes and asks for the ability to display middle names on tablets — but we still need to display the same name as before on mobile. No problem, just a new field: add {    "id": 123,    "name": "John Doe",    "full_name": "John W. Doe"} Until a new Product Manager (they change every 6 months) changes the UI completely in order to support name suffix, because the new boss insists on being called Edwin Denison Lowell, III. As the end users will upgrade their apps gradually, it’s important to support the previous name format, too. OK, let’s add more fields. {    "id": 123,    "name": "John Doe",    "full_name": "John W. Doe",    "full_full_name": "John W. Doe Sr."} You get the idea. The problem is that . In the Twitter API, a tweet consists of , most of which you don’t need if you want to display the top tweets about your company on a TV set in your meeting room. the longer a web service lives, the larger the resources become more than 30 fields But REST only contains the notion of resource — there is no notion of that you could use to, for instance, restrict the response to only the details you need. Attempts at mitigating this ( , ) exist, but they’re always optional. The default rule in REST is to require an entire resource, with all the fields. So REST web services become slower and slower over time, because their responses become heavier and heavier. fields sparse fieldsets partial responses HTTP CRUD Only REST is modeled after HTTP. It uses the HTTP verbs ( , , , etc.), requires HTTP transport, and suffers from the same performance and security problems as HTTP. Even if Roy Fielding's original REST paper , REST is HTTP only. GET POST PUT describes REST as protocol agnostic de facto Also, most of the discussions about REST describe CRUD (Create, Retrieve, Update, Delete) interactions only. For other communication scenarios (file upload, commands, remote procedure call, etc), you’re on your own. For instance, many modern apps require real-time updates. HTTP communication is based on a request and a response, it’s not designed to push updates without any request. Consequently, addressing the Publish/Subscribe scenario in REST requires a rather hacky approach: Client A sends a request to a central server every 10 seconds or so. GET /events One day, client B sends a request to the central server, with an event in the body POST /events Next time client A sends a request to the central server, it receives the event emitted by client B GET /events What a waste of resources (especially on mobile)! The only solution in HTTP REST land is to turn client A into a server: Server A sends a request to the central server, with a callback URL of as parameter. POST /subscriptions http://serverA.com/remote_events client B sends a request to the central server, with an event in the body. POST /events The central server sends a to server A, with the event in the body. POST /remote_events But how do you do that if client A is a mobile device? Does that imply turning every smartphone into a web server? It’s not a viable solution. Modern protocols like WebSockets or HTTP/2 solve one part of the problem (the protocol), but they don’t specify the data exchange format to use. And REST feels out of place for Pub/Sub with these protocols. For instance, WebSockets doesn’t have the notion of verb like HTTP — just messages. As a result, applications often use other architectures (like ) in addition to REST to handle these scenarios. WAMP The Solution(s) To summarize, the REST makes applications slow, harder and more expensive to develop, and too limited in functionality. These problems are real. Many companies suffer from REST, and many have tried to find a better alternative. architecture Maybe we can patch REST by adding all that it lacks: , , , , , etc. There are entire frameworks like dedicated to this task. My opinion is that it’s like trying to eat soup with a fork. You may manage to do it eventually, but is it really a good idea? I consider that REST doesn’t really match modern web apps requirements. And that’s unfortunate, given . HTTP/2 for request multiplexing batch endpoints sparse fieldset selectors schemas Swagger documentation API platform how much Marmelab, my company, has invested into REST Why not use SQL over HTTP? SQL has , , , , and it's standardized. Queries are validated against a database schema. But SQL restricts the possible actions to , , , and , so it's still too limited in terms of use cases. SQL also has a strong bias, which makes is far from ideal to query document or graph databases. But let's keep the idea of using a declarative query language. UNION JOIN HAVING GROUP BY SELECT CREATE UPDATE DELETE relational If you think you can address the limited functionality shortcoming by using plain old Remote Procedure Call (RPC), you’re on the right track. But the risk is to fall back to , and nobody wants to fall into again. SOAP the pit of utmost complexity Google invented to address the performance and schema pain points, and made it public in 2008. It’s a language-neutral, platform-neutral extensible mechanism for serializing structured data. That’s a good solution, but it does not address the problem of complex queries and aggregations. Nor does , another binary protocol for RPC. Protocol Buffers Apache Thrift Much closer to the holy grail is , open-sourced by Netflix in mid-2015. Falcor is both a server middleware and a client SDK. But it’s a tool, not an architecture. And it’s JavaScript-only; if you’re doing Objective-C or Kotlin, you’re out of luck. , and it lacks a powerful query language. Falcor Falcor doesn’t offer a schema and static types Conclusion There must be a better way. What we really need is to replace REST with a new architecture that allows to: Query aggregates of resources (e.g. tweets and profile, in one round trip), even from different domains Query an explicit list of fields, never a complete resource Provide a schema describing the syntax of the request and response Be a standard, but not too tied to the HTTP protocol Support Publish/Subscribe scenarios out of the box Shift the emphasis from the server to the client. I believe that an innovative tool recently published by Facebook solves this problem (hint: it starts with a G). Read to discover what it looks like. the next post in this series If you want to read more on the subject by other authors, I recommend the following articles: , by Jacob Gillespie From REST to GraphQL , by the GraphCool team GraphQL IS The Better REST , by the Apollo team GraphQL vs. REST , by Samer Buna REST APIs are REST-in-Peace APIs Originally published at marmelab.com on September 4, 2017.

Dive Into GraphQL Part I: What’s Wrong With REST?

Code Cracked for Code-Splitting + SSR in Reactlandia: React Loadable + Webpack Flush Chunks and more The code has been cracked for a long time now for server-side rendering and code-splitting . Until now — bar Next.js — there has been no easy to use common abstraction to achieve both simultaneously for the greater NPM community. This article presents several packages I’ve worked on for a long time now that I hope to be the final solution to this problem. individually simple + idiomatic import { flushModuleIds } from 'react-universal-component/server'
import flushChunks from 'webpack-flush-chunks'

const app = ReactDOMServer.renderToString(<App />)
const { js, styles } = flushChunks(webpackStats, {
  moduleIds: flushModuleIds()
})

res.send(`
  <!doctype html>
  <html>
    <head>
      ${styles}
    </head>
    <body>
      <div id="root">${app}</div>
      ${js}
    </body>
  </html>
`) TL;DR Run one of the below, and examine the code . There are 4 packages and 4 boilerplates: Universal Webpack boilerplates and done PACKAGES: faceyspacey/webpack-flush-chunks faceyspacey/react-universal-component faceyspacey/require-universal-module faceyspacey/extract-css-chunks-webpack-plugin BOILERPLATES: faceyspacey/flush-chunks-boilerplate-webpack faceyspacey/flush-chunks-boilerplate-webpack-chunknames faceyspacey/flush-chunks-boilerplate-babel faceyspacey/flush-chunks-boilerplate-babel-chunknames THE STORY James Kyle about 2 months ago laid the groundwork for what needed to be done in his now famous article ending with “use this shit,” which even inspired Arunoda with his “dynamic” component contribution to Next.js 3.0. And so React Loadable was born. React Loadable ultimately offered a solution that perhaps many had made something similar to, in one way or another. And which similarly had the same problem: it only solved the problem of having an async client-side component. What was most important was James Kyle’s discovery near the end of the article regarding how even though you may have an async component, you need it to render both asynchronously and synchronously, and that buffering/flushing the IDs of modules that were synchronously loaded on the server could lead to figuring out what initial chunks to send to the client. As such, it turned out that the asynchronous aspect in fact was the easier task. Rendering the client synchronously as you did on the server requires lots of labor. You have to render synchronously on the server (in either a babel or webpack server environments) AND synchronously again on the client on initial load of the page so that React checksums match up with what was received from the server, and so an additional rendering did not occur (and so you don’t lose precious milliseconds or seconds loading modules asynchronously). Even this turns out to be just the beginning of the problem — because what about actually discovering which chunks the module IDs or paths correspond to? What about serving them? What about stylesheets? Are you just going to always render your style sheet as one big main.css instead of breaking it up into chunks like your js have to use the new and exciting tools which come with their own caveats: they don’t generate static cacheable sheets and eat up cycles continually at render time both on the client and server? What about HMR? The list goes on. To do code splitting plus SSR right requires a laundry list of things checked off to do with ease, and more importantly: . OR idiomatically AND SO WEBPACK-FLUSH-CHUNKS WAS BORN And so I studiously went on my way to solve a problem I had put up with in the past by getting the benefits of code-splitting . If you’ve done this, you know the drill: Then when you’re done you can dynamically call require.ensure and choose which component to load, and more importantly toggle between rendering the synchronous one on the server and the asynchronous one on the client. And when you were done, you/I just settled for no server-side rendering and no SEO benefits. without SSR + SEO create a map of possible components you want to load asynchronously where each key is the name of a component and the value is an object containing an asynchronous value and a synchronous one (for the server). Basically, after hearing all the excitement about code-splitting, I couldn’t believe how little we all were getting for it, and how much farther it had to go. Anyway, everything is a progression and ultimately that’s the really exciting thing about everything what’s happening in . I’m not even gonna say the words “Javascript F***gue” to paint the picture, but to me it’s the exact opposite. It’s all of us evolving the perfect [software] world in a decentralized way. The future is here. Or rather, it’s just begun. Reactlandia MOTIVATION: THE PAST PROBLEMS /w CODE SPLITTING So what were the precise problems? What have been the shortcomings of code-splitting? Webpack long ago introduced the capability of code-splitting. However, it’s been an enigma for most . Firstly, just grokking the original require.ensure API and how to create your Webpack configuration to support it wasn't a natural thing for many. More importantly, if you were just to read how developers were using it, you'd think it was a done deal. But anyone who's tried to take this feature full circle and incorporate server-side rendering were left scratching their head . (me at least) (to me, it was surprising how little-talked-about this was) What's the point of code-splitting when on your initial page-load--if code from additional chunks was evaluated server-side--it required an additional request to get them? Sure, as your users navigate your single-page app it came in handy, but what about SEO? What about loading spinners after your initial page loaded? If you're like me, you ended up only using code-splitting for a few areas of your app where SEO wasn't important--often lesser used portions of your app. There has been no off-the-shelf solutions to handle this besides Next.js, which requires you making a commitment to a “framework.” Coming from the Meteor world, and having left it a year and a half ago, not showing I was not going back to Framework land. So, React can synchronously render itself in one go on the server. However, to do so on the client requires all the chunks used to perform that render, which obviously is different for each unique URL, authenticated user, etc. While additional asynchronous requests triggered as the user navigates your app is what code-splitting is all about, it’s sub-optimal to have to load additional chunks in the initial render. Similarly, you don’t want to just send all the chunks down to the client for that initial request, as that defeats the purpose of In addition, if your strategy is the former, won’t match and an additional unnecessary render will happen on the client. code-splitting. checksums As a result, the goal became to get to the client precisely those chunks used in the first render, no more, no less. SOLUTION By now you probably get that the solution revolves around somehow triangulating the data you have available such as the rendered module IDs to determine what chunks to spit out from the server. In general I’m breaking the whole solution down into 2 parts: frontend backend James Kyle pioneered the “frontend”: when used on the server, skips the phase and synchronously renders your contained component, while recording the ID of its corresponding module. React Loadable loading may be used multiple times and therefore may record multiple split points. React Loadable What (i.e. the “backend”) does is cross-reference those module IDs (or paths if using a Babel server) with your Webpack stats to determine the minimal set of “chunks” required to re-render those modules/components on the client. The “chunks” themselves contain ALL the files corresponding to the chunk (js, css, source maps, etc). So from there outputs strings, React components, or plain arrays containing the precise javascript files (and CSS files) to embed in your HTML response. Though it has a available to you, it also automatically handles your main, vendorand possible bootstrap chunks, putting them in the correct order. It even creates React components you can pass to renderToStaticMarkup. Perhaps the most important thing it provides is simply the precise and details laundry list of things you must do to . Webpack Flush Chunks Webpack Flush Chunks lower level API setup your Webpack config It’s not the hardest thing (though for whatever reason, remained arcane for so long). What it takes is getting extremely familiar with all the stats spit out by Webpack. It also requires figuring out how to match Babel paths to Webpack module IDs if you’re using a Babel server. In short the code isn’t too complex and very maintainable, but required a lot of thought and trial and error to figure out. is That’s the end of the story. Use Webpack Flush Chunks. in the words of . “Use This Shit” James Kyle NEXT: CSS Well not quite. There’s also CSS. I have a lot of opinions on this one. But I’ll save most for the readme to . Extract CSS Chunks Webpack Plugin I also have answers. It boils down to: the fact that Using CSS Modules already is “CSS-in-JS” Wasting cycles on both the client and server rendering CSS is just that — a waste! Cacheable Stylesheets are just that — cacheable! is a must HMR And: guess what? If you can just like your JS you don’t need to generate “render-path” CSS to send the least amount of bytes over the wire. In fact, you send less! chunkify your CSS See with true_r_ CSS-in-JS solutions like StyleTron, Aphrodite, etc, all your CSS is represented in code anyway, aka javascript. So you may be sending the smallest amount of CSS possible, but you’re sending it all down in the form of javascript and . IN ADDITION NO MATTER WHAT It also turns out that if you can statically chunkify your CSS, you’ve achieved the 80–20 rule: you’ve achieved the sweet-spot of 80% optimization in how little CSS you send over the wire. See, the real problem is, for example, sending over the CSS of your private user panels to your public-facing site or vice versa. If you have many sections/panels, your CSS exponentially grows and is sent everywhere. However, if you have a straight-forward mechanism to breakup your CSS into chunks by sections you’ve solved 80% of the problem, if not more. Again, you can read the readme for a lot more thoughts on this. It boils down to static determination of what CSS to send being a damn good solution. Going after that last 20% by sacrificing render cycles and having to use custom hocs — IMHO — is nitpicking and results in diminishing returns. Extract CSS Chunks Webpack Plugin Did I mention when u do I in fact request async chunks, those chunks have the CSS ready for injection embedded in the JavaScript again? See, it creates two js chunks: one without css which is sent in initial requests along with real stylesheets AND another for async requests which has CSS injection as usual! This gives u the smallest possible initial js bundles. Did I mention — unlike the original — Extract Text Webpack Plugin it supports HMR! “USE THAT SHIT!” MORE Yes, I got more. You wanna make your own Async Component because neither nor serves your needs? React Loadable React Universal Component Well, the core aspect for all this “universal rendering” goodness has been abstracted/extracted into its own package: faceyspacey/require-universal-module And what you make with it will along with just as easily as and . flush chunks Webpack Flush Chunks React Loadable React Universal Component This time, I really won’t say anymore. USE THAT SHIT! REACT UNIVERSAL COMPONENT But let’s not get ahead of ourselves. A lot has been put into React Universal Component to make it the — what I’m calling “Universal” — component. React Loadable kicked ass and this is its after all! be-all-end-all spiritual successor Basically everything under the sun (from PRs, issues, other packages, etc) has been included in it. With discretion of course ;) I’m trying to think of a few noteworthy capabilities to point out (as just reading its probably is the best thing to do once again). Well, lets look at some code: readme import universal from ‘react-universal-component’

const UniversalComponent = universal(() => import(‘./Foo’), {
  loading: Loading,
  error: Error,
  timeout: 15000,
  minDelay: 300,
  chunkName: ‘myChunkName’,
  onLoad: module => replaceReducers({ ...reducers, module.bar })
  key: ‘Foo’ || module => module.Foo,
  path: path.join(__dirname, ‘./Foo'),
  resolve: () => require.resolveWeak('./Foo')
})

export default ({ isLoading, error }) =>
  <div>
    <UniversalComponent isLoading={isLoading} error={error} />
  </div> et voila! A 2 argument API like Next.js’ , and an options argument with a super clean surface , which itself is also inspired by . dynamic like Vue’s React Loadable Not all those options are required. In fact they are all optional. which as you’ll read at the end of the readme — thanks to — may very well be the basis for an even . You could even have an async-only component Async Reactor further evolution in universal rendering There’s still a lot more than meets the eye. For one, you can wrap the resulting <Universal Component/> in a HoC that does data-fetching (i.e. some separate async work) and re-uses the Loading component (DRY) via the isLoading prop, etc. It makes for a perfect match for Apollo and the like. Both promises will run in parallel, and the same loading spinner will show. You can use onLoad to utilize other exports from the module to do related work: replacing reducers, updating sagas, perhaps something with animation, etc. If 15000milliseconds is reached, the error component will show. Thank you Vue. The minDelay is different than what React Loadable has. It results in a more responsive component. Instead of waiting a few ms to see anything, it always shows the spinner . And you can set the minimum amount of time before the async component can show. This also helps with animations. Say your page with the spinner in it slides in and the sliding animation takes 500ms — well, now u can avoid rendering jank from messing up your sliding animation by prolonging the page update until the sliding animation is done. It also better solves the original problem of avoiding flashing between the loading spinner and the component since, no matter what, they could appear around the same time without a minimum delay you can control. The readme has you covered there aswell. This is just off the top of my head. immediately It has support for HMR which React Loadable has yet to attain. Same with all your async CSS if you’re using . Extract CSS Chunks Webpack Plugin Lastly, instead of being restricted to promises with import() that calls require.ensure with a callback, which gives you the additional capabilities of require.ensure. You can actually do all the stuff Async Reactor does including data-fetching in it. More importantly, . This is a story for another day, but checkout as you review this stuff. Even if you’re very familiar with React Loadable, but you haven’t checked that, it will likely throw you for a loop [in a very good way]. you can use a function the props are passed as an arg so you can determine what data to fetch dynamically Async Reactor The interface proposed by has a lot of potential for becoming the idiomatic future of combination async/sync “universal” rendering. Async Reactor Basically it has potential to be the greater NPM community’s answer to Next.js’ s if it has a recursive promise resolution system like Apollo. Read the end of the readme to hear me go off on what I think is the future. getInitialProp And did I mention: you don’t have to use it in a sever-rendered scenario. That’s just where it shines. If you read the readme (and compare it to ), you can do some pretty cool things with the async component argument. Async Reactor Async-only is a primary use case for this package as well. CONCLUSION THERE’S FAR MORE YOU CAN DO AS YOU’LL READ IN THE READMES. SO MANY BASES ARE COVERED. GOODBYE. USE ALL THIS SHIT. PS. Did I mention Webpack’s “magic comments” feature which just came out is fully supported as well? Just use it and name your chunks and call flushChunkNames instead of flushModuleIds and pass chunkNames to universal(asyncWork, { chunkNames }) to make it work. It will save your server some cycles from doing all I had to do to jump through hoops to cross-reference module IDs with stats. Richard Scarrott’s Webpack-Hot-Server-Middleware (HMR on the Server) is world class. Examine its usage in the boilerplates. . The boilerplates themselves — I might add — are pristine. Enjoy! It’s important because this is supposed to the most modern [non-restricting] React/NPM developer experience for serious apps and related Developer experience goodness everywhere, hopefully you find it all to be idiomatic.

APOLLO IGDS

apolloigds.com

-- employees

Since n.d.

COMPANY RANKING

APOLLO IGDS

EVERGREEN INDEX #727

Representing this company? Click here to claim and customize this page!

Apollo iGDS WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

APOLLO IGDS

apolloigds.com

-- employees

Since n.d.

COMPANY RANKING

APOLLO IGDS

EVERGREEN INDEX #727

RELATED COMPANIESRANK

STORIES ABOUT APOLLO IGDS

Representing this company? Click here to claim and customize this page!

Apollo iGDS WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!