Jump to content

Search the Community

Showing results for tags 'prisma'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Discuss
    • Welcome
    • General Discussion
    • Market and Trading
    • Promotions
    • Improvement Proposals
    • Masternodes
    • Decentralized Exchange
    • Developers
    • Off Topic
    • Meet Ups
  • Support
    • Help!
    • Bug Reports & Feedback
    • Our Chains
    • Meta
  • Block & Chain Games
    • General Discussion
    • Game Questions
    • Blockfight
    • Draggin' Dragons
  • Localized Forums
    • Arabic
    • Chinese
    • Hindi
    • Japanese
    • Russian
    • Spanish

Blogs

  • Halo Platform Newsletters
  • Articles
  • Block & Chain Newsletters

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 1 result

  1. Halo-Shannon

    Async Iterators and GraphQL awesomeness!

    Find final code here: https://gist.github.com/shadowcodex/587cd0ffbf49cefd3a00a56caf7a5f11 So we recently adopted to using graphQL on our backend for a lot of our systems. It provides a ton of benefits such as: Faster front-end prototyping Built-in pub-sub Easy event-driven systems Better bandwidth handling and not over pulling or under pulling data And so much more... Those are just a few of the reasons we are working with graphQL now, and we have to say we love it. The new DEX is built on it with a special flow that I'll do another post on someday, however, I wanted to focus on something very specific that isn't covered in the documentation of graphQL and that is handling subscriptions on the server side. Specifically, we use Prisma as our backend graphQL service and with it comes prisma-bindings. It's great, and they have several examples of how to work with mutations and queries. No examples of subscriptions exist. So to first work with them you have to understand that subscriptions in prisma-bindings return async Iterators. If you are familiar with javascript async/await then you will know that async means that it happens without waiting on it (more or less). So to work with these you have to handle the iterator to get the values you want. So how does it work? Well first you grab your subscription, I'm going to work off of the following data model: # Information around an address type User { id: ID! @unique # Unique id autogenerated by system // remove if you don't want two unique paramenters. address: String! # The halo address of the user lastSeen: String! # Unix Epoch Time of Last Event Containing this User } This means that Prisma will handle creating a few functions for us like createUser, updateUser, query Users, and subscription user. So to subscribe using prisma bindings we use the following code: prisma.subscription.user({}, "{ node { id } }") So we pass it our search options which in this case is {} or none. Then we well it what we want back from the subscription. Now if you were just to log out this you would get an object that looks like: { next: [Function: next], return: [Function: return], throw: [Function: throw], '@@asyncIterator': [Function] } Which is quite useless. However, if you know what you are looking at you can use to your advantage. We know there is a function called "next()" on the returned iterator. When working with iterators the function "next()" will return the next item in the list, now if you apply that to an async iterator then it will return a promise for the "next()" function. When the promise resolves, the values will give us what we wanted in the first place. Once next resolves you can call it, again and again, to continue getting objects as they are passed into the iterator. Ok I can call it and wait for promise to resolve and use ".then()" to grab the value, but that sounds tedious. And it is. Instead we can use await and a while loop to pick up all the next events as they come in. See the following code: while (true) { await iterator .next() .then(value => { callback(null, value.value); }) .catch(err => { callback(err, null); }); } So here we do: Start loop Wait for next to resolve Do something with the value it returns Loop back to await next item If you throw this in with a call back system you get something like this: const handleIty = async (iterator, callback) => { while (true) { await iterator .next() .then(value => { callback(null, value.value); }) .catch(err => { callback(err, null); }); } }; Where you can pass in your iterator and callback function of your choice. Your callback will be what function you want to fire when the iterator.next() resolves. If you remember the prisma-binding subscription resolved into an async iterator so you can use this to process and "watch" it as new events plow through. So a fully running system watching the user table for any new changes would look like so: const { Prisma } = require("prisma-binding"); const prisma = new Prisma({ typeDefs: "./../generated/prisma.graphql", endpoint: "http://localhost:4466", }); const handleIty = async (iterator, callback) => { while (true) { await iterator .next() .then(value => { callback(null, value.value); }) .catch(err => { callback(err, null); }); } }; const handleValue = async (error, value) => { if (error) { console.log(error); return; } console.log(value); }; const run = async () => { const ity = await prisma.subscription.user({}, "{ node { id } }").catch(err => { console.log("error:", err); return; }); handleIty(ity, handleValue); }; run(); ---- This allows us to add items to the user table, and any system utilizing this will fire off the handleValue function. Essentially this allows our systems to react to data as it enters our database whether that data is from an API, a blockchain node, or a smart contract. After we launch the DEX we will talk more in depth of how we use this to power the DEX Frontend. Thanks guys, gals, and non-binary pals!
×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. - Please review our other terms and privacy polices here: Terms of Use and Privacy Policy