Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
We all know the good feeling that comes from starting a green field project and being able to use all the great new technology. But what if you have a 460k LOC monolith but you really feel that a new GraqhQL API is the way to go. Well, if you have good design, you can totally do it, and here's how. GraphQL is all the rage for good reason. It's geared towards solving the problems REST API's have when used by modern front-end apps. However, new technology often has a way of breaking apart when subjected to legacy projects. How easy is it to create a GraphQL API for a commercial project with 7 years of active development and 400k users? What difficulties might you encounter that blurbs and blog posts won't tell you about? I'll cover all that and more in this riveting tale of fun, sweat and tears (of joy). rubyday 2020 - Virtual edition, September 16th 2020. https://2020.rubyday.it/ Next edition: https://2021.rubyday.it/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In the talk titled "Moving to GraphQL - the fuzzy parts" presented by Greg Kaczorek at RubyDay 2020, the speaker delves into the intricacies of integrating GraphQL with legacy systems, particularly focusing on the challenges and solutions that arise when transitioning from REST APIs. **Key Points Discussed:** - **Background on GraphQL:** Greg starts by recounting his previous experiences with GraphQL at Toptal, where the transition from REST to GraphQL proved beneficial for both backend and frontend developers due to GraphQL's flexibility and efficiency. - **Need for Standards:** He emphasizes the importance of establishing clear standards to maintain consistency across APIs, suggesting the use of enums for predictable outcomes while cautioning against their excessive use. - **Handling Complex Relationships:** Different approaches such as simple lists and the concept of connections for cursor pagination are discussed to manage many-to-one relationships effectively. - **Separation of Concerns:** Greg advises creating distinct schemas to prevent sensitive data exposure and recommends against one monolithic schema to avoid complications as the API scales. - **Flexibility vs. Complexity:** While separation of services allows for flexible development, it may create complexity for users needing to navigate multiple endpoints. He advocates for a single gateway that abstracts these complexities to provide users with a seamless experience. - **Schema Stitching vs. Apollo Federation:** He compares schema stitching as a rudimentary merging method with Apollo Federation, which offers a more integrated solution for managing various services within the API. - **API Growth Considerations:** As organizations grow, it is crucial to ensure that APIs remain clear and effective without sacrificing usability. Communication among teams is essential to avoid the creation of ugly APIs that can diminish developer morale. - **Practical Challenges and Solutions:** Greg also highlights the importance of addressing challenges early in the transition and shares insights on batching functions, error handling in GraphQL, and implementing efficient caching strategies. **Conclusions and Takeaways:** - Transitioning to GraphQL from REST can lead to enhanced flexibility and efficiency, but it requires mindful implementation to avoid common pitfalls. - A structured approach to API development ensures reusability while safeguarding sensitive data. - Continuous communication across development teams is vital in overcoming integration challenges and optimizing the GraphQL API experience.
Suggest modifications
Cancel
