ReactFoo Delhi

On React, performance and front-end engineering

Tickets

Rethinking frontend development using GraphQL

Submitted by Ramakrishna (@rramaa) on Wednesday, 14 August 2019

Duration: 20 mins crisp talk

View proposal in schedule

Abstract

Increase developer efficiency, increase performance and discover pure component architecture using GraphQL. Using directives, enabling/disabling features with simple flags and reactive updates.

Outline

Problems faced using REST and their solutions

  1. Mocking: During development the most common problem faced is mocking. Generally frontend(app/web or both) is blocked on backend due to unstable apis or breach of contract with the backend. Mocking is implemented in frontend to overcome this problem but different implementation is needed in both app and web to achieve mocking. Still there is a limitation that you have to mock entire APIs. With GraphQL you can achieve seamless mocking for both app and web and its as simple as writing “@mock”
  2. Backend-Frontend Coupling: Generally frontend objects are coupled with backend schema. If the schema changes, the api structure changes, hence the frontend changes unnecessarily. With GraphQL, things become decoupled between frontend and backend. GraphQL defines a schema which is consumed by the frontend. The objects are resolved using resolvers written in the server. When the schema changes, only the resolvers change, but there is no need for the schema to change.
  3. The eternal and relentless fight between frontend demands and backend supplies: Multiple and sometimes serial calls are needed to render a page in frontend and these calls over internet take a lot of time. GraphQL combines these calls returns a neat object to frontend
  4. Overfetching: Read only the data that you require.
  5. Breach of contract: How many times have you sent a build and the API calls failed as some you made a typo in the request. GraphQL locks the schema and provides static type checking. Eslint GraphQL plugin validates the schema for you. Autocomplete in queries is also possible by using relevant plugins.

True Componentization of React Components

  1. Things needed to render a component? HTML, style(CSS) and data
  2. React brought in the component pattern and HTML.
  3. CSS in JS brought in style componentization. The component now owns the style.
  4. What about data? Component defines the data it requires to render using fragments. A wrapper translates the data into a GraphQL query and supplies the data to the component

Feature Enablement

  1. We follow trunk based development.
  2. So lots of features are in the master branch and they all get pushed to staging/production etc.
  3. Someway needed to disable the features.
  4. Disabled features should also not bring their data. Possible easily with the “@skip” directive

Declarative way of implementing things

  1. Deferring an object
  2. Skipping an object
  3. Declarative queries and mutations

Requirements

Basic understanding of GraphQL

Speaker bio

I am a JavaScript enthusiast with 3 years experience in front-end development. Currently working as a front-end developer with Mindtickle, Pune.

Links

Slides

https://docs.google.com/presentation/d/1RfIo21wYmdP87mwYmzWH0te4RPVclvJmvgX6VjWzml0/edit?usp=sharing

Comments

  • Zainab Bawa (@zainabbawa) Reviewer 18 days ago

    Thanks for yesterday’s rehearsal Rama Krishna. Here are the points of feedback from the rehearsal:

    1. The GraphQL terms in the talk have to be explained with a concrete example. Related to this, the introduction to GraphQL has to be more detailed. This is to help set the context for developers in the audience who may not be familiar.
    2. Talk about tooling when you speak about REST and GraphQL.
    3. How and why did you get started with GraphQL? This part is unknown in the talk. Related to this, how has GraphQL made you a better developer? Explain concretely.
    4. Instead of going from GraphQL to front-end in your talk, go from front-end to GraphQL. This will help the audience at ReactFoo (consisting mostly of front-end developers) to relate to your talk better.
    5. Schema diagram in the slides is intimidating. You have to show some GraphQL queries. Show how you do this with REST and GraphQL. Currently, examples are missing in the presentation. Add more examples.
    6. Don’t mention REST negatively. REST is what most developers have used. GraphQL is recent.
    7. GraphQL casing has to be correct and consistent throughout the presentation.
    8. Explain how mocking happens. Currently, it is unclear.
    9. Code comparison between current code and previous code has to be moved before in the slides.
    10. Acknowledge the investment and effort on the backend so that front-end developers do not leave with the misconception that GraphQL doesn’t require any work from backend developers working on the application.
    11. Articulation needs to be smoother. Currently, the flow is interrupted because the talk isn’t practised. Related to this, speak with more emotion and passion. This is currently missing in the talk.

    Add the link to your revised slides by 30 October so that we can review and do a second rehearsal.

  • Zainab Bawa (@zainabbawa) Reviewer 7 days ago

    Thanks for the revised slides, Ramakrishna. Here is the feedback on the revised slides:

    1. There is too much text on the slides. Plus the font sizes are so large that entire slides just seem like text blurbs. Either change the font size or reduce the text to just 2-4 phrases.
    2. If you have taken definitions or references from other sources, add the reference/source at the end of each slide. Attribution is must and necessary.
    3. Also, change the casing of the titles on all your slides to sentence casing. Capitalized words on the titles distract the eyes.
    4. The explanation about ‘mocking’ is missing. A slide on what is mocking, with references to links that participants can check later, will help.

    Update the slides before the second rehearsal.

  • Raghavendra Satish Peri (@artofvision) 6 days ago

    Hello,
    At hasgeek events we are trying to make our events accessible for people with disabilities. To achieve our goal is to first get the content of presentations accessible. Here is some guidance to make the presentations accessible. Please use these fonts & size so that even able body people can see the content in the auditorium during presentation.

    Fonts and Font Size
    Because they are the easiest to read, only use Sans Serif fonts, such as Arial and Verdana. Since a PowerPoint presentation will most likely be projected onto a large screen consider how far the audience will be from the screen and choose a font size accordingly. The minimum font size for a PowerPoint presentation should be 24 points.

    For more accessibility info on making presentations accessible use the following link
    https://www.framingham.edu/Assets/uploads/about-fsu/accessibility/_documents/7-steps-accessible-ppt.pdf

  • Raghavendra Satish Peri (@artofvision) 5 days ago

    Hi Ramakrishna,
    Thanks for the wonderful talk. Here is the feedback & all the best,

    Lot of headings with what problems. give specific heading text instead of generic one.
    Practice more so that Articulation can be smoother.

Login with Twitter or Google to leave a comment