Build scalable APIs using GraphQL and Serverless
•Als PPTX, PDF herunterladen•
0 gefällt mir•422 views
Current trends in software and backend architecture have been evolving towards a more loosely coupled more granular design. I am sure most of you have heard of microservice based architectures. The latest development on that front in the past couple of years has been the advent of serverless which allows you to run applications in very cost effective ephemeral services. This is why it is important to have a proper gateway for your API that is able to route all your requests to the designated endpoint. GraphQL stands out in that respect as being a mature open sourced standard started at Facebook.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (13)
Ähnlich wie Build scalable APIs using GraphQL and Serverless
Ähnlich wie Build scalable APIs using GraphQL and Serverless (20)
Mehr von Simona Cotin
Mehr von Simona Cotin (18)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Build scalable APIs using GraphQL and Serverless
- 1. Build Scalable APIs using GraphQL and Serverless
- 8. @simona_cotin –-Lee Byron a data-fetching API powerful enough to describe all of Facebook
- 11. @simona_cotin https://facebook.com/user/id/events { "name": "HelsinkiJS", "location": "Helsinki", "organiser": "Citrus", "attendees": [ { "name": “Sarah Drasner", "company": “Microsoft", "role": "Chef Of Avocados 🥑" } ]
- 12. @simona_cotin
- 14. @simona_cotin
- 15. @simona_cotin https://facebook.com/user/id/friends-suggestions { "name": "Golnaz Badazadeh", "profile_pic": "some_url", "mutual_friends": [] }
- 16. @simona_cotin https://facebook.com/user/id/friends-suggestions/id/mutual{ "mutual_friends": [ { "name": "Sarah Drasner", "profile_pic": "some_url", "tag": "Amazing!" } ] }
- 18. @simona_cotin Delay User Perception 0-100 ms Instant 100-300 ms Small perceptible delay 300-1000 ms Machine is working 1000+ ms Likely context switch 10000+ ms Task is abandoned High performance Browser Networking
- 19. @simona_cotin –-Ilya Grigorik The fastest network request is a request not made
- 20. @simona_cotin user(id:1) { name events { count } friends_suggestions { name mutual_friends { count } } } } "data": { "user": { "name": "Simona Cotin", "events": { "count": 4 }, "friends_suggestions": { "name": "Golnaz Babazadeh", "mutual_friends": { "count": 15 } } }
- 23. @simona_cotin type People { id: ID! name: String avatar: URL }
- 24. @simona_cotin type People { id: ID! name: String avatar: URL } type Team { id: ID! name: String points: Int people: [People]
- 25. @simona_cotin type Query { teams: [Team] } type Mutation { incrementPoints(id: ID!): Team }
- 26. @simona_cotin teams: async () => { let teams = await axios.get( 'https://graphqlvoting.azurewebsites.net/api/score' ); return teams.data; }, incrementPoints: async obj => { let response = await axios.get( `https://graphqlvoting.azurewebsites.net/api/score/${obj.id}` ); return response.data; }
- 27. @simona_cotin
- 28. @simona_cotin
- 29. @simona_cotin
- 30. @simona_cotin ✓ Performance ✓ Flexibility ✓ Tooling
- 32. @simona_cotin –-Steve Jobs The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.
- 33. @simona_cotin module.exports = async function(context, req) { context.res = { body: 'Hello ' + req.query.name }; };
- 38. @simona_cotin
- 40. @simona_cotin
- 41. @simona_cotin { "type": "cosmosDB", "name": "inputDocument", "databaseName": "admin", "collectionName": "Recipes", "connectionStringSetting": "tacos-sql_DOCUMENTDB", “direction": "in" }
- 42. @simona_cotin module.exports = async function(context, req) { context.res = { body: context.bindings.inputDocument }; };
- 43. @simona_cotin ✓ Reusable API ✓ VS Code dev & debug ✓ Easy Integration Datasources
- 46. @simona_cotin
- 47. @simona_cotin
- 48. @simona_cotin
- 49. @simona_cotin
- 50. @simona_cotin
- 51. @simona_cotin const body = req.body; let response = await graphql( typeDefs, body.query, root, null, body.variables, body.operationName ); context.res = { body: response };
- 52. @simona_cotin
- 53. @simona_cotin
- 54. @simona_cotin
- 55. @simona_cotin
- 56. @simona_cotin Easy Integration of Datasources Autoscalability Less code Easy Abstraction of Datasources Single Endpoint Smaller no requests Serverless GraphQL
- 57. @simona_cotin Easy Integration of Datasources Easy Abstraction of Datasources Autoscalability Single Endpoint Less code Smaller no requests Dev productivity
- 59. @simona_cotin
Hinweis der Redaktion
- The plot is this: Agnes here is looking at two pieces of tech apparently unrelated
- Turns out they do have a couple of things in common, they’re both on the hype train. Both GraphQL and Serverless are probably at the peak of their popularity where there’s literally a new community library probably created at this very moment.
- Another thing that they have in common is that they’re both extremely appealing to js developers. That’s not to say that they’re not being used by other types of developer, but in particular js developers ted to be excited about graphql because graphql changes the balance and empowers frontend developers to define their data needs without having to rely on the backend team. At the same time, serverless is also of great help to front end developers because it enables us to create small, reusable APIs for our static websites. As we’ve seen in Monica’s presentation, serverless can help us with a couple of things that browser don’t do. Things like storing secrets or
- Funnily enough, they both Both emerging at around the same time. Graphql was open sources as a specification in early 2015 and serverless late 2014.
- But there still one thing that connects them very strongly and this is what we’re going to spend time on discovering today
- You are probably familiar with the n+1 problem:when a request to load one item turns into n+1 requests since the item has n associated items. The term has been mainly described in the context of databases, specifically ORM where we lazy load child records, but it is in fact not confined to that. We can see this phenomenon elsewhere including web apis where we’re composing data from multiple endpoints or resources. This is also known as a Chatty API which is one of the UGLY aspects of REST APIs. A chatty API, is any API that requires consumer to do more than a single call to perform a single, common operation
- Why do we care about overfetching & under fetching so much? Well because they introduce a delay in our application. And our users perceive this delay in different ways depending on its length. Anything taking more than a second will prolly make our user context switch and more than 10 seconds abandon the task. And many roundtrips to the server add delay to our application, same as parsing data to filter out fields.
- https://hpbn.co/
- A single request
- Front end and backend teams sit together and define a contract that they’re going to communicate through; an interface between the two teams
- A strongly typed definition of all the operations that can be run against the API and their types
- A single request
- A single request
- A single request
- A single request
- A graphical interactive in-browser GraphQL IDE. Syntax highlighting Intelligent type ahead of fields, arguments, types, and more. Real-time error highlighting and reporting. Automatic query completion. Run and inspect query results.
- But the true power of serverless doesn’t come only from the custom code, it comes from how easy we can integrate with multiple datasources and 3rd party apis.
- To create a GraphQL backend for our API we use the graphql-js module that exports a core subset of GraphQL functionality for creation of type systems and servers. Our entry point is the graphql function which is capable of parsing, validating and executing a graphql request. It requires a schema and a request string but we can also send query variables and operation names as well as context object
- Choose a diff icon; one for cache
- Developer productivity
- Go build smith!
- Two pieces of tech apparently unrelated