Q4 Results 13 May 2024 Live Updates: Investors will be watching the performance of players like ONGC, Indian Railway Finance Corporation, Bharat Electronics, Oil India, Steel Authority of India, Whirlpool of India, India Cements, <strong>Apollo</strong> Pipes, Honda India Power Products Limited, Tracxn ...

Q4 Results 2024 LIVE Updates: ONGC, Oil India, Steel Authority of India, Whirlpool of India, Apollo Pipes, more to announce earnings today - Industry News | The Financial Express

Apollo helps international manufacturers and brands scale on Western eCommerce platforms and marketplaces

Apollo

GraphQL is the alternative for REST made by Facebook. When facebook reached the limits of REST API, they had to make something breaking these limits. Through this article, you can learn what GraphQL is, how it works, and how to use it in your projects. GraphQL (Graph Query Language) is an API-level query language. Like SQL is used for requests to relational databases, GraphQL allows clients to request data from an API. For a good understanding of this article, you should have a basic understanding of TypeScript and NodeJS. Why is GraphQL so good? Receive only data you need. GraphQL allows you to manage what data API will return to you. This has a number of advantages. It helps network performance when the response contains a lot of data you don't need. Of course, REST can handle it via request parameters like , however much easier when it is available by default, does it? It is also useful if your API supports different types of clients which want to call less and fetch more. ?fields=name,birthdate Access to a complex graph of objects aggregated from different sources. GraphQL allows you to get a complex graph of objects by a single request. These objects might be from different sources. Clients and server API schemes are always in sync. Your clients and server have the same scheme, so it is easy to sync it. GraphQL anatomy To understand how GraphQL realizes all you’ve read above, let’s talk about what artifacts GraphQL includes. GraphQL includes schema, which describes the types of objects you can operate on. Take a look at the following schema: type App {
   id: ID!
   name: String!
} This is the type App, which includes id and name required fields. It means you can operate this object. But how to operate it? There are a few access operators in GraphQL. The first one (required one) - . This is a getter for your object. The second one - , is a setter. And the last one is a , which allows you to subscribe for updates of your type. query mutation subscription type Query {
   apps: [App!]!
   app(id: ID!): App!
}
 
type Mutation {
   createApp(app: AppInput!): App!
   updateApp(appId: ID!, app: AppInput!): App!
}
 
input AppInput {
   name: String!
   publisherId: ID!
}
 
type Subscription {
   appMutated: AppMutationPayload!
}
 
type AppMutationPayload {
   mutation: MutationType!
   node: App!
}
 
enum MutationType {
   CREATED
   UPDATED
   DELETED
} The code snippet above contains . Inputs allow you to define input parameters types. input AppInput Another important component of GraphQL - resolvers. Resolvers define how to handle queries, mutations, and subscribers. We will come back to it soon. Apollo Apollo Server is a Node.js implementation of graphQL server. There is good scalable architecture and a strong community that means it is a good choice for use. We won’t talk much about Apollo architecture, we’ll learn everything needed by code examples. Install dependencies "dependencies": {
   "apollo-datasource": "^0.8.0",
   "apollo-server": "^2.22.1",
   "graphql": "^15.5.0"
 },
 "devDependencies": {
   "@types/graphql": "^14.5.0",
   "@types/node": "^14.14.37",
   "ts-node": "^9.1.1",
   "typescript": "^4.2.3"
 } - allows implementing GraphQL server - allows implementing data sources (like database aggregators or rest api integrations) - graphQL package. Required by Apollo. apollo-server apollo-datasource graphql Server Initialization import {ApolloServer, gql} from 'apollo-server'
import {typeDefs} from './graphql/typedefs'
import {resolvers} from './graphql/resolvers'
import {dataSources} from './datasources'
 
const server = new ApolloServer({
 typeDefs: gql`
   ${typeDefs}
 `,
 resolvers,
 dataSources
})
 
server.listen().then(({url}) => {
 console.log(`Server ready at ${url}`)
}) Let’s understand the code above. We are initializing Apollo Server with several arguments. - this is a path for graphQL schema - as a said earlier, we will come back for that a bit later - data sources like DB aggregators and API integrations typeDefs resolvers dataSources DataSources import { AppService } from './app-service';
 
export const dataSources = () => ({
   appService: new AppService()
}); This is DI of dataSources. This format is required by Apollo. import { DataSource } from 'apollo-datasource';
 
export class AppService extends DataSource {
   constructor() {
       super();
   }
} dataSource might look like this. This is an aggregator, where you can implement business logic and accessors for data. Resolvers Finally, let’s talk about resolvers. As I said earlier, resolvers define how to handle queries, mutations, and subscribers. Take a  look at that: type Mutation {
   createApp(app: AppInput!): App!
   updateApp(appId: ID!, app: AppInput!): App!
}
 
type Subscription {
   appMutated: AppMutationPayload!
}
 
type AppMutationPayload {
   mutation: MutationType!
   node: App!
} And now take a look at the resolver: import { pubsub } from '../pubsub';
 
const APP_MUTATED = 'appMutated';
 
export default {
   Query: {
       apps(parent, args, {dataSources}) {
           return dataSources.appService.getApps();
       },
       app(parent, args, {dataSources}) {
           return dataSources.appService.getApp(args.id);
       }
   },
 
   Mutation: {
       async createApp(parent, args, {dataSources}) {
           const { publisherId, ...rest } = args.app;
           let app = await dataSources.appService.createApp({...rest}, publisherId);
           pubsub.publish(APP_MUTATED, {
               appMutated: {
                   mutation: 'CREATED',
                   node: app
               }
           });
           return app;
       },
       async updateApp(parent, args, {dataSources}) {
           const { publisherId, ...rest } = args.app;
           let updatedApp = await dataSources.appService.updateApp(args.appId, {...rest}, publisherId);
           publishAppUpdated(updatedApp);
           return updatedApp;
       },
       async setAppDevelopers(parent, args, {dataSources}) {
           let updatedApp = await dataSources.appService.setAppDevelopers(args.appId, args.developerIds)
           publishAppUpdated(updatedApp);
           return updatedApp;
       }
   },
 
   Subscription: {
       appMutated: {
           subscribe: () => pubsub.asyncIterator(APP_MUTATED)
       }
   },
};
 
function publishAppUpdated(app) {
   pubsub.publish(APP_MUTATED, {
       appMutated: {
           mutation: 'UPDATED',
           node: app
       }
   });
   return app;
} This resolver totally defines all queries, mutations, and subscribers. And as you can see, we have access to data sources that were injected into ApolloServer. let app = await dataSources.appService.createApp({...rest} We deal with this, but what about subscribers? Subscription: {
    appMutated: {
        subscribe: () => pubsub.asyncIterator(APP_MUTATED)
    }
} And what is the code in mutations? pubsub.publish(APP_MUTATED, {
   appMutated: {
     mutation: 'CREATED',
        node: app
     }
}); This is pubSub. Maybe you know this pattern. Microservices usually communicate using it. This is required for subscribers in Apollo. And it makes sense because subscribers are WebSockets. Websockets keep connections, so it is easy to reach a high load. So, the Apollo team decided to handle it with this design solution. Anyway, there is an in-memory dummy, just for testing. Never use it in production. import { PubSub } from 'apollo-server';
 
export const pubsub = new PubSub(); How to test Run the app using the following command: ts-node src/index.ts Go to localhost:4000 via web browser and see the following: This is the test console Apollo. You can test queries, mutations, and subscriptions here. Congratulations! You’ve just learned how to build graphQL API using Apollo and Node.JS. Full code example you can find here: https://github.com/gandronchik/graphql-example

Intro Guide to the GraphQL API using Node.JS and Apollo

One of my side projects involves writing a around the Universal Chess Interface ( ). I originally developed a mock implementation and . That used version one of Apollo’s client/server stack, which . One of the biggest changes was the subscriptions interface and implementation, and I struggled for many hours to get that to work. Part of the problem is that the documentation is not very complete and rather scattered. This post will cover the most basic implementation of subscription service and the client code that uses it. GraphQL API UCI wrote about it awhile back changed quite a bit in version two Getting started The GraphQL server will be based on , which in this case will use an Express server as middleware. Subscriptions will use a that is attached to a plain HTTP server (also managed by ApolloServer, as we shall see). ApolloServer WebSocket There are two clients: the , and a client for use by Mocha to test the API outside of a GUI. For simplicity, I’ll keep the Mocha client code in the same folder as the server code. I also use Babel so I don’t have to think about and the like. GraphQL Playground Michael Jackson Scripts With that in mind, here are the packages to be installed: apollo-link, apollo-link-http, apollo-link-ws, apollo-server-express babel-cli, babel-core, babel-preset-env graphql, graphql-tools subscriptions-transport-ws mocha, chai I’ll provide a link to a working code repository at the end of this article. The Server The server is as basic as I could make it: express ; { ApolloServer } ; http ; { typeDefs } ; resolvers ; PORT = ; app = express(); server = ApolloServer({
  typeDefs,
  resolvers,
});

server.applyMiddleware({
  app
}); httpServer = http.createServer(app);
server.installSubscriptionHandlers(httpServer);

httpServer.listen({ : PORT }, () => { .log( ); .log( );
}); import from 'express' import from 'apollo-server-express' import from 'http' import from './schema' import from './resolvers' const 3031 const const new const port console `🚀 Server ready at http://localhost: ` ${PORT} ${server.graphqlPath} console `🚀 Subscriptions ready at ws://localhost: ` ${PORT} ${server.subscriptionsPath} An ApolloServer is created with schema and resolver parameters. The call passes in an express application instance. Finally, an HTTP server is created to handle the web socket interface to the subscription service. Both GraphQL and the subscription websocket share the same port, but under different protocols. applyMiddleware The Schema { makeExecutableSchema } ; resolvers ; typeDefs = [ ,
]; options = {
  typeDefs,
  resolvers,
}; executableSchema = makeExecutableSchema(options); executableSchema; { typeDefs }; import from 'graphql-tools' import from './resolvers' const `
  type Query {
    go: String!
  }
  type Subscription {
    info: String!
  }
` const const export default export The schema is very basic: will return a string acknowledgment, but behind the scenes it will fire off a method that sends publish notifications to subscribers. Subscribers subscribe through the subscription API. go info We can see how this works in resolvers.js: { PubSub } ; pubsub = PubSub(); TOPIC = ; infos = [ , , , ] publish = {
    setTimeout( infos.forEach( pubsub.publish(TOPIC, {info})), )
} { : { : { publish(); }
    }, : { : { : pubsub.asyncIterator([TOPIC]),
      },
    },
  }; import from 'apollo-server-express' const new const 'infoTopic' const 'info1' 'info2' 'info3' 'done' const => () => () => info 1000 export default Query go => () return 'going' Subscription info subscribe => () I’ve made the resolvers deliberately simple. For example, the asyncIterator method from PubSub is quite sophisticated (it supports filters and authentication, for example). Since it is already , I won’t delve into various options here. All the resolver above does is to publish an to all subscribers, passing objects as the body of the subscription. well-documented infoTopic info The Client As I mentioned, I’ll use two clients for testing. One is the built-in Prisma Playground, a service automatically provided by the ApolloServer (FYI: ). you can turn this feature off in production Testing in Playground To test, I’ll open Playground in Chrome, at Within Playground you can open up multiple tabs. For the first, I’ll subscribe to the : http://localhost:3031/graphql. infoTopic When this command is played, you will see a ‘Listening …’ response in the right pane, as shown above. Now you’re subscribed. Open another tab within Playground and query go: This sends back a response of “going”, so everything is okay. Now, going back to the subscription tab, you will see the published output: Testing using Mocha/Chai There’s a lot of boilerplate in setting up a client, so I’ve created a utility file to handle query and subscribe operations. It’s called fetch.js: fetch ; { execute, makePromise } ; { WebSocketLink } ; { SubscriptionClient } ; ws ; { HttpLink } ; gql ; uri = ; wsUri = ; link = HttpLink({ uri, fetch }); wsClient = SubscriptionClient(wsUri, { : }, ws); wsLink = WebSocketLink(wsClient); doQuery = { operation = { : gql ,
  }; .log( ) makePromise(execute(link, operation));
}; subscribe = { operation = { : gql ,
  }; execute(wsLink, operation).subscribe(handlers);
}; doQuery; { subscribe }; /* eslint-env mocha */ /* eslint-disable import/no-extraneous-dependencies */ // see https://www.apollographql.com/docs/link/index.html#standalone import from 'node-fetch' import from 'apollo-link' import from 'apollo-link-ws' import from 'subscriptions-transport-ws' import from 'ws' import from 'apollo-link-http' import from 'graphql-tag' const `http://localhost:3031/graphql` const `ws://localhost:3031/graphql` const new const new reconnect true const new const ( ) => query const query ` ` ${query} console `$query is ` ${query} return const ( ) => query, handlers const query ` ` ${query} return export default export The fetch.js code pulls in a lot of interdependent modules. For the test operations, I use to handle the interface between the server (which has to be running, btw 😉) and the GraphQL operations used by the tests. There are actually two interfaces here: one to handle query and mutation requests vis HTTP, and another that goes through a web socket to subscribe to a topic. apollo-link Most of this comes from the , but you will have to install a few additional modules I neglected to mention earlier: documentation node-fetch (installed globally via ) npm -g ws gql The module implements the HTTP that’s becoming a standard. The module is a WebSocket implementation for Node (there are others), and is a template literal tag that you can read more about . node-fetch Fetch API ws gql here The test itself is pretty straightforward: we first , then : subscribe go chai ; fetch, { subscribe } ;

chai.should();

describe( , { .timeout( ); handlers = { : { .log( , data); (data.data.info === ) { .log( )
        process.exit( );
      }
    }, : .error( ),
  }; it( , () => { query = ;
    subscribe(query, handlers);
  });

  it( , (done) => { query = ; { res = ( fetch(query)).data;
      res.should.have.property( )
      res.go.should.equal( )
    } (e) { .error(e)
      done(e)
    }
  })

}) /* eslint-env mocha */ import from 'chai' import from './fetch' 'subscribe, then go' ( ) function this 5000 const next ( ) => data console `received data:` if 'done' console 'exiting...' 0 error => error console `received error ` ${error} // get the subscriber ready... 'subscribe' async const `subscription {
          info
        }` 'go' async const `query {
            go
        }` try const await 'go' 'going' catch console The object (passed to the method) is what receives the publish notifications. When the last published message is received, the test process is terminated. hander subscribe Conclusion You should explore the links provided, as there is a lot more about GraphQL subscriptions that I wasn’t able to cover in this article. I’ve also included a few relevant links, below. A complete github repository containing the code above can be found . Enjoy! here Tutorial: GraphQL Subscriptions (server-side) — Apollo GraphQL apollographql/graphql-subscriptions: A small module that implements GraphQL subscriptions for Node.js SSL on Apollo Server 2.0 + Subscriptions · Issue #1338 · apollographql/apollo-server apollo-link-ws | Apollo Link Composable networking for GraphQL | Apollo Link Apollo Client | Apollo Client

GraphQL Subscriptions Using Apollo 2

Apollo is the best solution for managing remote data with a client cache. But if you are already using Apollo (or another client cache like Relay), the question is: What should you do about the rest of your client state? React’s new context API (available in 16.3 or as a polyfill) has opened up new possibilities for dealing with app state. At , we’ve been trying to find that blissful state that combines the data from the server, component state, and the app state, which hasn’t always been smooth. OK GROW! App state is tiny I became interested in Redux after watching Dan Abramov’s seminal talk at ReactEurope. After I’d learned the basics of Redux, I began looking for information on “advanced Redux.” But that brought me face-to-face with the problem with Redux for users: Every tutorial I found turned out to be implementing a client cache. You would learn the three or so ways to do async with Redux and then implement those async actions to work with your Redux store. But Apollo’s client cache already does all of that. It has all of my loading and error states handled, it deals with optimistic updates, you name it. So what’s left to manage? Apollo The answer, as it turns out, is very little for most apps. Most of it should just live in components. React What about centralizing to Redux for better testability? I agree that this makes testing very easy, but I have two problems with it: The whole point of having a component system is for encapsulation. React allows you to put state into your components so that when you are working elsewhere, you don’t have to think about what’s happening in that component. As soon as you try to separate that functionality, you have keep two things in your head, the component and the state (which is now probably in a separate file, so you need more buffers open). Not only that, but there is also risk that somebody else (never you!) would be tempted to grab that state from a different component. It breaks encapsulation. I’ve heard of developers making their entire app out of functional components with all state coming from Redux. Hey, I had a “let’s use all functional components!” phase too. But having a global store bypasses the top-down data flow and makes your app harder to reason about. Also, that’s a lot more code! Removing state from components feels un-React-y. Some of this movement stems from the fact that testing components has been pretty awkward for a long time, but I think we can solve that using tools like (more on this in a future post), or possibly a new tool like . React Test Renderer Cosmos There are apps that will really benefit from Redux, so I’m not saying not to use it. But in my own work, I have not been able to justify the overhead once Apollo took over remote data synchronization and caching. What state is left to manage? If you put most of your state into components and have a client cache, what’s left? Almost nothing. In one app, I had only a single global state variable to manage. But I tried managing it directly with the old Context API, and that convinced me that app-wide state is still a problem worth solving! Here are some things I think legitimately belong in app-wide state: Top-down data propagation runs into a roadblock when you hit a routing boundary. Of course you’ll pass some params to dependent routes, but passing shared state is a recipe for disaster. Just use app state instead. State that needs to be shared between routes. Sure you could put it in your root component and pass it down, but why? As an aside, I think a case can be made to store current session information (e.g., is the user logged in) in state even though you can also do that with Apollo. State that is used all over the place. In the last app I worked on, we tried . The logic is compelling: Since you already have a nice library to query and update values in the database, and since most of your data will already be in that format, why not just store your app state the same way? Then you have one way to do things, and you can use the existing reactive query components to update UI elements regardless of whether the data is local or remote. Apollo Link State To be fair, Apollo Link State totally works, though I ran into some sharp edges on what was then a new addition to Apollo. The real problem is that the way you produce and consume local app data just doesn’t match the pattern of remote data. Queries for remote data tend to be specific to one part of your app and don’t repeat much. The queries are intentionally verbose to clarify the relationship between the client and server, and they may reside in their own files and may have options for optimistic updates, updating based on mutations, etc. They also make extensive use of loading/error state, the ability to select which fields you need, etc. But by definition, app data is ubiquitous and simple — usually key-value pairs, or sometimes objects that are needed in various combinations that are read and updated in multiple places in your app. You don’t need to select fields, deal with loading state, etc. Writing queries for these things is simply awkward and excessively verbose, and don’t forget that queries and mutations require separate code. Here’s an example: We had an app for ordering from restaurants. If you leave your table, it should clear incomplete orders and remove the table number you were sitting at. But you shouldn’t be able to do that if you have an unpaid tab (ticket). We had components with render props to compose in the state queries and mutations, and this was a piece of code that appeared in the app: <ClearOrder    render={clearOrder => (      <SetCurrentTable        render={setCurrentTable => (          <GetOrderStatus            render={({ ticketId }) => (              <HeaderButton                label="Leave Table"                disabled={!!ticketId}                onPress={() => {                  clearOrder();                  setCurrentTable({ qrCode: '' });                }}              />            )}          />        )}      />    )}  /> It’s almost enough to make you go back to higher order components! 😱 Actually, I think HOCs would be a good solution here, but composing individual operations is still pretty heavy. Enter Unstated Before we look at Unstated, I should say that you don’t need to use any other state library at all! The is quite nice and may be all you need, allowing you to keep state in a root component. That said, here’s that same component written with new Context API Unstated <Subscribe to={[Table, Order]}>  {(currentTable, order) => (    <HeaderButton      label="Leave Table"      disabled={!!order.state.ticketId}      onPress={() => {        order.clear();        currentTable.set({ qrCode: '' });      }}    />  )}</Subscribe> I find it much more readable, and there are fewer levels of indentation and fewer lines of code. It avoids the pyramid of doom in two ways: Get and set functionality can be shared in one state object, reducing imports. Order and table state could have been combined to one object if we preferred that. We are dealing with classes, so we can combine as many things as we like on that container. There’s a built-in way to subscribe to multiple state containers in one component – the prop takes an array of state objects. Subscribe to Finally, if we compare the code to perform , one of the actions, the difference becomes a little starker: clearOrder The GraphQL is simple enough but doesn’t tell us much: mutation clearOrder {  clearOrder @client} And the resolver ends up looking a lot like a Redux reducer. clearOrder: (_, __, { cache }) => {  const data = cache.readQuery({ query: GET_ORDER });  // make sure you mutate your object correctly  // or other state could be affected  data.items = [];  cache.writeQuery({ query: GET_ORDER, data });  return null; // if you forget to return null, you'll get errors}, The equivalent method in the Unstated class would be a one-liner: // make sure you bind your method if you might pass it// as a propclear = () => this.setState({ items: [] }); Ah, That feels better! Testing with unstated Because Unstated creates an object that is not a react component, you can test it without rendering the component just as you might with Redux: test('clear order', () => {  // instantiate and set up our state object for the test  const orderState = new OrderState();  orderState.setState({ items: ['hamburger'] });  orderState.clear();  expect(orderState.state.items).toEqual({ items: [] });}); Or you can test it in place by injecting it into a component tree with the prop: inject test('clear rendered Orders', () => {  // render an Orders component with the same orderState as above  // (here with react-test-renderer)  const tree = TestRenderer.create(    <Provider inject={[orderState]}>      <Orders />    </Provider>,  );  // make sure our order rendered (1 item)  expect(tree.root.findAllByType(OrderItem).length).toBe(1);  // "press" the leave-table button by calling its onPress, which will  // call our `clear()` method  const leaveTableButton = tree.root.findByProps({    testId: 'leave-table-button',  });  button.props.onPress();  expect(tree.root.findAllByType(OrderItem).length).toBe(0);}); Follow Your Bliss In fact, Unstated is so easy to use, it would be easy to use it for everything, but that’s not really the intent of the library. Use it judiciously, though, and it will fill in a small but very important hole in your state management. Using Unstated in my current project feels like I’ve finally arrived at a complete data solution, and I’m no longer wishing for something different. Originally published at www.okgrow.com .

State of Bliss: Handle Your State with React, Apollo, and Unstated

You shall fail… successfully Errors are common to all computer programs; they might be hard to maintain, but properly dealing with them is without any doubt the most critical part of building applications. In the context of a Client/Server architecture we need the Server to output and that the Client can and in order to . well-formatted easily identifiable errors seamlessly read, process handle fail successfully E.g. a successful failure GraphQL powered APIs are no (pun intentional 😏) to this rule. Here is what the latest draft of the GraphQL specification says about how error outputs should be formatted. Exceptions (Sun, Jun 10, 2018) If the operation encountered any errors, the response map must contain an entry with key . _errors_ Every error must contain an entry with the key with a string description of the error intended for the developer as a guide to understand and correct the error. _message_ GraphQL services may provide an additional entry to errors with key . This entry, if set, must have a map as its value. This entry is reserved for implementors to add additional information to errors however they see fit, and there are no additional restrictions on its contents. _extensions_ With this in mind, a typical error object should look something like this: ..."errors": [    {      "message": "Only Prophets can do this",      "locations": [ ... ],      "path": [ ... ],      "extensions": {        "code": "NOT_A_PROPHET",        "timestamp": "Thu Jun 21 17:03:00 UTC 2018"      }    }  ]... Remember that we want the error output to be “ and ” meaning it should contain at least one field than can be seamlessly processed by a computer. well-formatted easily identifiable First candidate to consider is , a Since it is formatted to be read by a human, it could potentially be an expressive long string containing unwanted characters ( etc…) thus not ideal. message “string description of the error intended for the developer[…]”. %, ç, à, $, €, @, white spaces, According to the specification, should be the dedicated space for any additional entry to Here, it gives us the ability to attach a key, providing a datum that can be extensions errors . code machine-readable “ seamlessly read, processed and handled ”. if (error.extensions.code === "NOT_A_PROPHET") {  // Do Something} Moving forward 🏇 We just saw that there are guidelines on how to output errors in the context of a GraphQL API. With that we should be able to: Throw and output and errors — thanks to — within our resolvers. spec-compliant identifiable _extensions_ Identify and handle errors client-side to . fail successfully However, the specification doesn’t specify guidelines for issues like APIs errors documentation, retry or failure handling, meaning that there are countless ways to properly arrange our code base for that purpose. The absence of explicit convention led me to build . Apollo-Prophecy The way of the pagan First, let’s illustrate what maintaining errors can be like without . To that end we’ll be using , a prominent, spec-compliant, fully-featured and well-maintained GraphQL server implementation for nodeJS. Apollo-Prophecy Apollo Server Because we’re using , we can use the constructor : errors thrown using this constructor produce a spec-compliant JSON output like the one above. Apollo Server ApolloError(message, code) throw new ApolloError("Only Prophets can do this", "NOT_A_PROPHET"); In order to make it easier for us to store errors we could organize our server-side code the following way: And properly handle errors like this: Done, right? No, we can do better. With this configuration, we end up doing the same work twice: since on the server we would have to write a client side. for every existing error entry corresponding key I don’t know about you but I prefer to say DRY. To leverage API documentation 📑 One of the most interesting propositions of GraphQL is that While this is usually done through a mechanism named “introspection queries” — giving us detailed information about the fields and types in our schema — this doesn’t mean that we cannot add documentation material to the schema itself: API should be self-documenting. What if errors were part of the schema? Here is how we could exploit this: We include errors in the schema: 1. type ErrorExtensions {  code: String!}

type Error {  name: String!  message: String  extensions: ErrorExtensions}

type Query { We create the corresponding resolver on the Query field: 2. ...const resolvers = {Query: {...errors: { ... }}}... That’s cool but what about the client? 🤷 Assuming that information about errors are accessible through our APIs, we need to find a way to access them from the client, keeping in mind that we want to avoid doing the same work twice. From here we can discuss two different implementations: Every time our app launches, the client could . perform a query to fetch all errors codes and store them locally 😒 Meh… Handle it on the dev-side by fetching and as part of the build process. storing errors statically in the codebase 💁 Why not? Since correct error-handling is critical to the good functioning of your application, going with would make fetching all errors’ definitions a mandatory step of the app launch process — therefore increasing loading duration. option 1 That’s why for cleanliness and overall performance, I like the better. second option The prophet way? 🧙🏼‍ I’ve started working on : a code generation Command Line interface that does what we need (and a tiny bit more!). It will: Apollo Prophecy Generate errors that we can throw in our resolvers and expose through the schema as documentation — apollo-prophecy generate Query the server schema and generate file with methods and helpers to gracefully consume errors — apollo-prophecy ask The goal is to always keep you server and client errors repository in sync. First, install it through your favorite package manager. [npm | yarn] install -g apollo-prophecy To generate errors like a greek God 🔮 The command will create a file containing throwable error classes. It takes as input a JSON file formatted like this: generate It can be run like below (if nothing is specified it will look for an file inside the running folder): errors.json apollo-prophecy generate errorsDef.json Using the above the CLI will generate the following file. errosDef.json Here are the generated file key components: — plain JSON array meant to be used as documentation output. It contains all error representations with their static data: , , . errorsList name message extensions -> code Always generated but empty if there is no error to generate. — GraphQL object type that we can include in our . It should be used alongside for documentation. . errorType schema definition errorsList Always generated as is — class extending ApolloError meant to be by other errors in this file. . PropheticError inherited Always generated as is — those are the two custom error classes generated with the information of the JSON file input. NotAProphetError ProphetNotFoundWithId We can use all these elements in our server. Given that we need errors to be part of our schema, we can do the following: import { errorsList, NotAProphetError } from './gen/GeneratedErrors' Query: {errors: () => errorsListgetAllUsers: () => {...throw new NotAProphetError()},} Hmm ok… Does that make us prophets now? 🤔 Not yet; prophets need to communicate with gods in order to anticipate the future, don’t they? Using , we can do something similar with the command : Apollo-Prophecy ask apollo-prophecy ask http://localhost:3000/graphql [--field] This will send a request to the specified endpoint and try to perform a GraphQL query on the option to try and fetch errors’ information (if nothing is specified, an will be queried by default). --field “errors” field Below is an extremely simplified version of the generated file. If you want to have an idea of what it really looks like go and ! try it yourself —an enum with the codes of all errors exposed in the schema. PropheticErrorCode and are the real two helper methods that enable us to handle client-side errors in a clean and reusable way. errorHere isThis - errorHere(error) When called, it returns an object that has found on the server. Depending on the supplied argument, the called property returns either : one property named after each errors true or false import { errorHere } from `./_generated/Errors.ts`; ...(error) => {if(errorHere(error).isNotAProphetError){// Do something} else if(errorHere(error).isProphetNotFoundWithId){// Do something else}} - isThis(error) When called, it returns an object that has found on the server**.** one handler function named after each errors import { isThis } from `./_generated/Errors.ts`; ...(error) => {isThis(error).UserNotFoundError(() => ...).NotAProphetError(() => ...).handle()} Handlers return the same instance object than , so that each function call can be chained. Once the method is called, it initiates the check and calls the corresponding handler if there is a match. isThis handle And… voilà! Thanks to the command we can keep our client-side error repository in sync with the API through the schema. By using and we now have a clean and expressive way of handling errors — and look, the code is pretty too! ask errorHere isThis Conclusion Just like any young technology, still has gaps to fill. is built to fill just one of these gaps: . But this isn’t the end of the conversation; is open-source, and I’m sure together we can come up with even better ways to improve it. GraphQL Apollo-Prophecy how we implement error handling and documentation Apollo-Prophecy Already there is a lot of work and fixes to be done on ; contributions and suggestions are both welcomed and needed. Please visit and take look at existing or even s. Apollo-Prophecy Github issues create new one If you’ve come this far, thank you for reading ❤️ I really hope you enjoyed this post and I’d love to hear your thoughts and feedback 🙂. _apollo-prophecy - 🔮 GraphQL error management made Easy, generate custom machine-readable errors for Apollo…_github.com theGlenn/apollo-prophecy

Handling and documenting GraphQL errors using Apollo-Prophecy + Apollo

and its ecosystem are awesome and makes using it a pleasure. If you are writing a javascript application today I can’t stress enough how much simpler these two technologies will make that process. GraphQL Apollo A has recently and released there own mechanism to help you store local state in their cache. I’m really excited about this move and believe that this will further simplify the process of frontend development. However it does add complexity in the fact that there not many resources or third party library support out there for yet. This tutorial aims to help change that. 😀 pollo moved away from Redux apollo-link-state By the end of this tutorial you will have: Setup a React project using create-react-app Used to store and query for information apollo-link-state Written some stateless components with help from recompose Special thanks to Peggy Rayzis and the Apollo team for all the awesome work and communication that has been going out around this product. See her Future of State Management post to see what initially brought we over to this technology Getting Setup Before you start Please make sure you have the following installed and/or ready to go: Node Npm Yarn Initialize the project First before we can dive into Apollo we need a React App to use it with so lets create a React project called using . link_state_demo create-react-app # Download Create React Appyarn global add create-react-app # Use it to create a React Projectcreate-react-app # Navigate to the projectcd link_state_demo Add Additional Dependencies Next we want to add , , and among other supporting libraries. apollo apollo-link-state recompose lodash yarn add apollo-boost apollo-link-state react-apollo graphql-tag graphql lodash apollo-client-preset recompose Kick it off! It’s that simple, now we can just start our dev server and go! yarn start You should now be able to navigate to _localhost:3000_ and see your application running. create-react-app running out of the box Modify App.js to be Stateless Optional! I prefer to write my components using React’s stateless components because I It helps to simplify my code by: believe Reducing boilerplate Increasing Readability Discouraging lifecycle methods Encouraging a healthy separation between UI and Application Logic Though these are opinions and not required for using this demo! To change over to using stateless components is as easy as copying the code below to your file: app.js Setup the Apollo Client To begin we will have to set up our Apollo client. This is fairly simple and will involve the modification of one existing file and the creation on another. Setup the ApolloProvider Open and wrap in Apollo’s . index.js <App/> ApolloProvider Setup the ApolloClient Create a new file named and initialize the cache and the Client.js ApolloClient Setup State logic that will support a To-Do List (A To-Do List Demo! How Original!) Now that we have the Apollo Client setup it’s time to begin adding the methods, queries and components that will allow us store and modify local state in the Apollo Cache. Add apollo-link-state to Client.js Below you’ll find an updated which fully implements all the necessary tools to use to handle Todo list state. However before you dive into it you should understand what the sections do: Client.js apollo-link-state Defaults The default values that our local cache falls back to when the application loads. GraphQL This section houses the GraphQL queries which are used in the following ways: Finding data from the cache Finding where to insert data into the cache There are a few differences to pay attention to: The **_@client_** decorator This is what tells Apollo that these queries target the local cache. Query vs Mutation The keyword in the context does exactly what you expect, it looks for the data in the cache and returns it. query @client However the keyword tells us that it needs to modify something in the cache. To do this the mutation looks for an identically named function in the resolvers object we pass into which we define further down. mutation CreateClientStore Cache Mutations These are the functions that are called by our mutation queries. They are given the parameters sent to the query and an instance of the cache with the intention that we use these to update the state held inside. Store This is where we tie together our cache, client state, defaults, resolvers and the Apollo Client to give the ApolloProvider the ability to store state using . apollo-link-state Helpers Here we’ve created a Higher Order Component to help give a child component access to the functions needed to interact with the state mechanism we’ve just setup. What this all looks like Setup the TodoList Component Next we need to actually use the queries we defined above. To do this we are going to create a basic To Do List that lets us add items to a list and clear the list. Create TodoList.js Add TodoList to our App We then just need to add the to our container and it should be good to go. TodoList App What it should look like Navigating back to you should see: localhost:3000 And thats it! You’re now storing state locally using apollo-link-state Wrap up Simple solutions and simple architectures lead to a better and more stable systems in the long run. While GraphQL has helped to simplify query logic the Apollo Team has been doing an equal amount of work to simplify the rest. Because of this I’m happy to include these two technologies where ever I can. In this specific case has proved to be a valid alternative to Redux and has saved me from: apollo-link-state Adding another technology and paradigm Splitting my state into multiple locations Adding more that one method to get application state. The only caveat so far is that Link State lacks some tooling and third party library support that the Redux community enjoys, but I believe that is a very small and very temporary issue. Coming up next We dive into how to set up for success when handling additional stores. apollo-link-state N _Overview_medium.com Setting up apollo-link-state for Multiple Stores This is open source! you can 🧞‍ find it here on Github ❤️ I only write about programming and remote work. If you I won’t waste your time. follow me on Twitter

Storing Local State in React with apollo-link-state

Take a look into your future 🔮 I want to touch on how to set up to allow for support of multiple stores without interfering with one another. apollo-link-state In my last post we went over how to setup for basic use: apollo-link-state _Special thanks to Peggy Rayzis for all the awesome work and communication that has been going out around this product._medium.com Storing Local State in React with apollo-link-state Now in this tutorial this is the moon we’re shooting for: Moving to its own file. withClientState Moving specific resolvers and mutations to their own files. Writting an elegant way to merge together multiple stores. Adding a new Notes feature to the previous demo. Lets Dive in! 🚀🌙 My biggest problem when using apollo-link-state To kick this off I want to talk about the problem we are trying to solve. It boils down to that expects only one value for and one value for which is incompatible if you have more than 1 object you want to store. CreateClientState defaults Mutations.resolvers This will get unruly fast It’s incompatible because it forces us to keep the and for multiple logically separate features in one place. OR if forces us to explicitly reference a / from a separate file every time we create one. resolvers defaults resolver default This is bad and in a medium to large app is a great way to make your logic hard to track. How can we solve this Thankfully the solution to this is really easy! It involves the following: 1. Move our CreateClientStore out of client.js file Move the configuration of your client store to its own file to help highlight that this is a very specific and a very important piece in our application. Our new should look like this: client.js 2. Move our defaults, resolvers, and queries to their own file @client Break out the and for a specific area of functionality into their own “store” files to help ensure as the application grows code is logically co-located. defaults resolvers 3. Tie it together with some lodash magic 🧙‍ Finally we use some helpers from lodash to merge the export of each file into one. This allows us to define and in separate files and bring them back together during configuration. store resolvers defaults Look at the _mergeGet_ function specifically to see how this occurs. Adding another feature becomes easy-peasy Now that we have the above infrastructure in place adding a second feature is just as easy as adding the 100th feature. Lets test out this statement by adding a Freeform notes field to the application. 1. Create the Notes Store Nearly identical to the Todo Store above. 2. Hook up the new Store Import the new store into and add it to our . CreateClientStore.js STORES 3. Create the Note Component Now that we have the store created and wired in it’s time to put it all to use. 4. Add to app.js Finally add our new component to our container. <App/> See it in action! You should now be able to run the update demo and see our new note’s feature in action. Simple. Wrap up I wanted to put this out because I think this Apollo’s version of maintaining local state has some real potential and as a young project the more support it gets the more we should see if grow and thrive. Part of supporting a project is learning how to use it and learning how to improve on it. I hope this helps do both! Happy coding! 🧞‍ This is open source! you can find it here on Github ❤️ I only write about programming and remote work. If you follow me on Twitter I won’t waste your time.

Setting up apollo-link-state for Multiple Stores

✨ an AWS experiment ✨ Motivation We started a big project few months ago: . migrate our application to GraphQL With and with many nested ressources, the maintainability and performance of the application were getting worse every month. 300+ React Component 20 API endpoints Once this project finished, we wanted to ensure that GraphQL fulfil his promises, so we decided to track migrated components “perceived performance”. We wanted to watch the performance of our GraphQL Ruby API over time and avoid UX/performance regression. Considering that we already use a lot of external SASS (NewRelic, Cloudinary, AWS, Segment, OAuth0, …), instead of building a full AWS data ELK stack, we decided to build a simple and low-cost performance “dashboard”. Since our Segment account save all raw data in a S3 bucket, we decided to use this data by sending a custom event . Perfomance.QueryLoadTime Note: is a SASS Analytics API that provide integrations with 200+ services like Hubspot, custom webhooks or AWS. Segment The Architecture Of course, Segment can easily be replaced by AWS and AWS Kinesis Firehose API Gateway The front React application is sending a custom event to Segment each time a specific GraphQL request end.The event is then stored in S3 as JSON raw data files. Perfomance.QueryLoadTime Then, every week, the data is fetched from S3 and consolidated, ready to be used in Google Sheets. Let’s see how to make it work out ! Send performance data — setup Apollo with Segment is a GraphQL client compatible with React Apollo Data For this, we need to write a that intercept some filtered queries and send performance data to Segment. custom link You’ll see below a service.Don’t worry, this is our Segment client wrapper. JasonBourne It’s all.All you have to do is to add this to your instance. link ApolloClient export const client = new ApolloClient({link: ApolloLink.from([perfMonitorLink, networkLink]),cache: apolloCache}); You’re all set for the front part. Build consolidated data — Setup AWS Athena Athena is a service of Amazon that allow to run SQL queries against S3 files. Configuring Athena is quite easy, you need to: create a database create a table by specifying a source and the data structure create a named query and save it The data Here is the raw data structure that Segment store to S3(for the event) Perfomance.QueryLoadTime You’ll notice that many field are not relevant for data analysis, so we’re gonna only keep a subset. Create a database and a table The “Create table” UI available on AWS Athena do not allow to create table with complex data structure (nested field, union type field, etc), so we need to write a create table query, by hand ✍️ Note: Athena use a language to describe data, here is the wanted query : Apache HIVE CREATE TABLE The query expose the data format (JSON), data structure, the source and the destination To do so, we can use a wonderful tool called .This is an open source project — recommended by AWS official documentation — to generate HIVE query from JSON raw data. [hive-json-schema](https://github.com/quux00/hive-json-schema) In short, given a JSON example file, it generate a corresponding query. CREATE TABLE , it’s really simple (take 5 minutes maximum). Read the doc Write and save a SELECT Query The table is now ready, we can write a query.Here’s ours: SELECT SELECTproperties.ellapsedMs, properties.operationName, sentAtFROM "segment"."perf" WHEREevent = 'Performance.QueryLoadTime'ORDER BY sentAt DESC; Since it’s plain SQL, you can select all the field available on this table. Run the query and save it. NB: each time a query is executed, Athena store the CSV result on your S3.To know where (which bucket), go to Settings. Problem Athena do not propose to run a saved query periodically.However, we can use the AWS Athena API to run a query remotely.Next step, the lambda. Keep data fresh — Setup a periodic AWS Lambda AWS Lambda is a service that allow to create . serverless functions Serverless architectures refer to applications that significantly depend […] on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”)[…] . By using these ideas, […], such architectures remove the need for the traditional ‘always on’ server system sitting behind an application. Depending on the circumstances, such systems can significantly reduce operational cost and complexity at a cost of vendor dependencies and (at the moment) immaturity of supporting services. Martin Fowler — Serverless Architectures We don’t want to go on AWS Athena UI every week to run the saved query manually, so we need a Lambda that run our query very week. Here’s how to do so: Create a periodic lambda Ensure lambda have sufficient rights to call Athena and store results to S3 Create a “periodic lambda” Go to “Create Function” and select “Node 6.10” and “Create a custom role”.You’ll be redirect to , click on “Allow”. AWS IAM Please write down the name given to the IAM role, it will be used later. Then click on “Create Function”. Select a trigger You’ll arrive a page like this. In order to run, a lambda need to be invoked.We want to invoke our lambda on a weekly basis, like a CRON task. offer this feature. AWS Cloudwatch On the left, select “CloudWatch Events”, then use this configuration : The lambda will be invoked by a Cloudwatch event every 7 days. The lambda IAM role This is the nifty part, you’ll need to go to IAM and find the role you just created. Then ensure that the role has the following permissions: : , Athena GetNamedQuery StartQueryExecution : , , , S3 ListBucket CreateBucket PutObject ListAllMyBuckets This will allow the lambda to find run a query and store it results on S3. NB: I highly encourage you to dig in the AWS IAM documentation in order to understand all the implications. The lambda code The lambda must : Get the named query by id Start the query Terminate lambda execution NB: To get your Athena Query ID, open the query from Athena “Saved Queries” and copy the id from the URL Displaying data — Configure Google Spreadsheet Now the consolidated data is fresh and available, we need to : get the consolidated data format date field — if any build a pivot table build a chart Copy the content of the last CSV file created by AWS Athena You’ll find the file in the bucket specified in the Lambda source code. Remember, we specified a custom output location to the AWS Athena start query call. Copy the content of the file, and paste it in a new sheet. Format data In case you’re dealing with date field, here’s a trick. Google Spreadsheet do not understand the ISO date format, we need to “format” it.Here is the formula, apply it to a whole new column for each needed field. = DATEVALUE(MID(C2,1,10)) + TIMEVALUE(MID(C2,12,8)) ⤴️ Here you’ll get a “MM/DD/YYYY HH:MM:SS” format Remember to change the column format to “Date time” Build the “pivot table” The consolidated CSV data is no yet usable.Since the data use many dimensions (sentAt, operationName) for a single value (elapsedMs), we need to build a “matrix/pivot table”. For this, create a new sheet and go to “Data>Pivot table …” Here is an example of pivot table configuration, it’s very “data-specific”. Configure the chart The configuration of the chart is very personal and depend on what type of data you have, here’s an example of time-based performance data. My favorite chart type for time based performance data is ⤵️ Scatter chart Or the classic Smooth line chart with average valuesinstead of detailed values ⤵️ This helps us to see the trend and maximum values in a glance ✨ Conclusion Pros only pay for Lambda execution and Athena query once a week very flexible configuration geeky 🤓 Cons Solutions already exists : ELK, AWS Quicksight, Tableau Copy-paste data every week not configurable for a non-tech Future and improvements 📈 CVS file data pasting step This step is hard to automate easily because AWS Athena create a unique .csv file in S3 each time a query end.A workaround could be to do 2 things : update the lambda to save the result of the query in a file named and on S3. latest.csv save it publicly Then use awesome function in Google Spreadsheet IMPORTDATA() This way, the data will always be the freshest one! Support for many queries We may want to create many Athena queries (examples: BI or advanced cross analytics-tools reporting) For this we can update the Lambda function to update all or many queries. What about Tableau, AWS Quicksight or Datadog ? Of course, there is a lot of battle-tested and professional solutions.This blogpost expose a solution to a specific context with a particular financial and technologic constraints.We could totally configure Datadog or pay a Tableau licence, but it would not be that fun! This is of course an experiment and temporary solution. Thanks for reading! 🌞 I hope you learnt some things about AWS or GraphQL.Please feel free to drop a comment if i missed anything!

Build performance reports for your Apollo React Components in 30 minutes. ⏲️

When developing a website that interacts with a REST API, a common path is to use a network management library together with Redux to manage state. This means writing reducers, actions, and state management for the different stages when communicating with the API. With good design, this can be generalized using HOCs, or some other structure to avoid repeating code. The Apollo stack aims to simplify development of applications that consume an API. GraphQL For the backend part of the stack, it uses instead of REST. is a query language created by Facebook in 2012 for describing the capabilities and requirements of data models for client‐server applications. It tackles several of REST’s shortcomings, providing an easy way of defining data structures and queries so that development and usage of the API is easy and flexible. GraphQL GraphQL Some people are even calling it REST 2.0. There is a whole ecosystem around GraphQL. Some notable examples of tools are: provides a way to use GraphQL like a backend-as-a-service. GraphCool to validate queries using ESLint, avoiding typos and warning the developer if something changed in the backend. Plugins exists Some are pointing to (an interactive tool for exploring and testing GraphQL backends) as the killer app for GraphQL. GraphiQL is a GraphQL client for , React Native, Angular, Swift and Java. When using it, you get options for configuring caching, mutations, optimistic UI, subscriptions, pagination, server-side rendering, prefetching, and more. Apollo Apollo React It can be incrementally adopted, meaning that it can be implemented for small components, coexisting with non-apollo components. Apollo uses Redux under the hood, so it can plug into existing Redux applications and all Redux development tools will work with Apollo’s queries. All code related to API interactions gets managed by Apollo, allowing the developer to just define what data a component needs. , these are some useful resources: Besides the official documentation : an excellent 6-part tutorial for implementing the full Apollo stack. Full-stack React + GraphQL Tutorial : Top 3 things to know coming from REST. How do I GraphQL? : How GraphQL turns a query into a response. GraphQL explained : Keeping your components pure with HoCs Simplify your React components with Apollo and Recompose

APOLLO

apollosuite.com

-- employees

Since n.d.

COMPANY RANKING

APOLLO

EVERGREEN INDEX #176

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

Apollo WIKI

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

APOLLO

apollosuite.com

-- employees

Since n.d.

COMPANY RANKING

APOLLO

EVERGREEN INDEX #176

RELATED COMPANIESRANK

STORIES ABOUT APOLLO

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

Apollo WIKI

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