Hey @tyvdh, I was playing a bit with the horizon-test and it went down ?.

Could you please take a look at it?

Thank you!

    jfuentes No worries. Back up now. There aren't a whole lot of checks in place atm so if you make a request which returns a MASSIVE amount of data or an overly complex filter the app may crash.

    Need to get some checks and auto rebooting in place.

      Hey Tyler this is absolutely beautiful! Forgive my ignorance about GraphQL but where can we get a list of all entities/fields in order to build some queries? This stuff is amazing!

      * facepalm * Top/right there is a Docs link

        Thanks, I'm in love!

        Hey quick question, can we submit queries using plain http POST? Is there any API endpoint for that? I played with the web UI which is cool but I'd like to make a query once in a while from a program to check for trustlines which is something StellarSDKs lack and it is in urgent need the more tokens get created. Someday when I grow up I'll get my own node and your posts are perfect guides for that but for now I'd be more than happy to hit your service once a day while I get used to server stuff.

        * To expand, I saw the links to https://api-test.gly.sh and https://api.gly.sh but do they get graphiql queries in the post body so we get the same responses as the web UI? The ones I tried are just proxies to horizon responses which is not what I want.

          Another * facepalm * haha so obvious, the web UI has to communicate with the server duh! I'll take a look, thanks!

          a year later

          This is related to the question posed on stackexchange here: https://stellar.stackexchange.com/questions/729/possible-to-get-a-list-of-account-holders-satisfying-certain-criteria-using-hori/730

          If I want a complete list of all native (xlm) accounts that meet a certain criteria, but have the results not just show on my browser but instead get fed into a db, is there a way to take the output from graphiql and get it into a database (there could be 1000's of accounts)? I don't want to overload your setup...

          The other option is the one I see mentioned on the above post's answers: setup an instance of stellar core and query the database, and then use that info to build my own database. Is that the only real option here or are there other alternatives?

            7 days later

            pdog Certainly! If you're planning on using this in production however I would set the Docker image up on your own servers but so long as you paginate the results and then page through them it should be 100% doable over a period of time as you page through.

              @tyvdh

              This is a great project! I totally overlooked it back then.

              I'm currently reaching the limits of Horizon with https://equilibre.io. For some portfolios it has keep 20 or more orderbooks up to date, plus the list of offers, and it's badly lagging. It is pretty clear that a GraphQL solution with compound data & subscription could largely improve this situation.

              It looks likes what you released so far is a sort of sophisticated demo (no orderbook support for example). Have you any plan implementing in completely?

              I have a few questions about GraphQL:

              • Could it fully replace Horizon?
              • How does it compare cost-wise with a RESTful solution?
              • Any way to guard against "abusive" requests?

                MisterTicot Hey, there! Appreciate the comments and questions.

                To answer the questions in short:

                • Yes, GraphQL could fully replace all existing Horizon functionality, and it wouldn't be too much work either. Would basically just need to add streaming support and mutation functionality back in.
                • Cost wouldn't be much different from an operating standpoint, you do have another service to standup and if you want custom functionality you'd have to build that in your self but if you're familiar with postgres or graphql it wouldn't take much time.
                • Great question and yes, there are several ways abuse could be mitigated. There are several articles and tutorials on the subject. Here's a good one for example. https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b

                As far as building these things out myself in gly.sh I'm doubtful. I'd really need to beef up my servers and add a lot of the support for things you've mentioned. While it wouldn't be terribly difficult or expensive, without a consistent Saas type business model it simply wouldn't make sense for me to provide a single solution for everyone. Better for everyone to host, run and customize their own instances at least until the concept of StellarQL matures and we get a better sense of what a single solution might look like as far as features and speed.

                    MisterTicot Also unless I'm mistaken you can already get the orderbook from the core graphql endpoint with a request something like this.

                    query allOffers {
  offers: allOffers(
    first: 100
    filter: {
      or: [
        {sellingassetcode: { equalTo: "WSD" }}
        {buyingassetcode: { equalTo: "WSD" }}
      ]
    }
  ) {
    nodes {
      lastmodified
      
      sellingassettype
      sellingassetcode
      sellingissuer
      
      buyingassettype
      buyingassetcode
      buyingissuer
      
    }
  }
}

                    That would return all offers buying or selling the asset code WSD

                      tyvdh

                      Thank you for the detailled answer. This is absolutely interesting. I think I'll dig in as soon as I can get myself some more free time.

                      Thank you as well for the offers query. I totally overlooked it.

                        16 days later

                        Pleased to announce I've recently launched fully synced production level endpoints for both the test and public networks. They can be reached at these new endpoints.

                        https://core.stellarql.com/graphql
                        https://horizon.stellarql.com/graphql
                        https://core-testnet.stellarql.com/graphql
                        https://horizon-testnet.stellarql.com/graphql

                        As of today I'm taking down the gly.sh endpoints.

                        Happy coding!

                        21 days later
                        2 months later

                        StellarQL is shutting down in favor of https://astrograph.io/. The folks over there are doing a better job at porting the Stellar database over to a GraphQL endpoint. Rather than have people choose, why not just choose the better service! 😃

                        Thanks for all the support and feedback during the lifetime of the project. It was a great ride and I'm confident the folks over at Evil Martians will take the idea to places I could have only ever hoped.

                        ❤️

                        14 days later
                        2 years later

                        Hi,
                        Could you give me the code to get alltrustline an asset
                        I tried with this code but it not work on https://pubnet.astrograph.io/

                        {allTrustlines(orderBy: [BALANCE_DESC], condition:{assetcode:"XRP", issuer:"GCNSGHUCG5VMGLT5RIYYZSO7VQULQKAJ62QA33DBC5PPBSO57LFWVV6P"}) {
                        nodes {
                        accountid
                        balance
                        assetcode
                        }}}

                        Thank you

                          StellarUAE Hi! Here's how you would do it in Astrograph:

                          {
  asset(id: "USDC-GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN") {
    balances(first:10) {
      nodes {
        account { id }
        spendableBalance
        authorized
      }
    }
  }
}

                          Astrograph was built from the ground up to be a fully-featured GraphQL server for Stellar network, rather than a thin wrapper around existing storages. A large part of the value of GraphQL lies in providing an abstraction between services and consumers, so the schema should not be tightly coupled either to particular service implementations or to particular consumers as they exist today. So in general don't expect Astrograph to directly expose Core/Horizon DB relational data.

                          You will notice here and there that we didn't limit ourselves by existing table structures or Horizon-defined representations of certain entities. Instead, we tried to follow schema-first approach and tried to map Stellar network on a graph in the most sensible way. For example, unlike stellar-core, in Astrograph asset is a proper top-level entity, and you can start with the asset and then follow the asset <1--*> balance connection to get all the balances, and each balance belongs to an account, so you can follow that connection, and so on until you get all the necessary data. Also, in certain cases we took the liberty to use different terminology (i.e. trustline vs balance).

                          There's some basic schema documentation, but I would recommend to use interactive documentation and playground with autocomplete, which also has schema embedded docs.

                          One final note is that we don't provide any SLA for our pubnet and testnet Astrograph instances, so they should be considered development playgrounds and not used in anything close to live systems. In particular, pubnet instance does not have the full historical data ingested.

                          If you'll have further questions, feel free to start a discussion on Github or jump in to our public Keybase group