Factom Open API — REST+GraphQL Open-source Factom API Server

Unrestricted Public Thread

  • Viewed Anton Ilzheev BI Foundation BI Foundation Bedrock Solutions Bedrock Solutions Blockrock Mining Blockrock Mining BuildingIM BuildingIM Canonical Ledgers Canonical Ledgers Cube3 Cube3 DBGrow DBGrow De Facto De Facto Factom Inc. Factom Inc. Factomatic Factomatic Factomize Factomize Factoshi Factoshi Federate This Federate This Go Immutable HashnStore HashnStore LUCIAP LUCIAP LayerTech LayerTech Matter of Fact Matter of Fact Multicoin Capital Multicoin Capital Prestige IT Prestige IT RewardChain RewardChain Stamp-IT Stamp-IT The Factoid Authority The Factoid Authority VBIF VBIF
  • Not Viewed Crypto Logic Crypto Logic
Secured
#1
Hello Operators and Guides!
Factom Open API is a combo REST + GraphQL API Server, that connects to factomd node (locally or remotely, e.g. to Open Node) and allow developers, operators & enterprise to easily interact with the Factom blockchain.

We need your feedback & ideas on Open API features and functions, if you have them.
We are going to apply Open API as a grant project for the next grant round (with the same USD amount as earlier), and I would be glad to discuss the project in advance and improve it with additional features if it will be useful & needed :)

Main features:
  1. Additional high-level functions
  2. 
Fast & easy set up of environment
  3. Simultaneously support of traditional REST API + modern GraphQL API
  4. Doesn’t require to keep blockchain locally & powerful hardware/VPS (so Open API may be installed & used even on Digital Ocean minimal $5/mo VPS)
  5. No separate factom-walletd instance required: all transactions are prepared and signed inside Open API, you just put EC private key in config
The whole description of Open API is in presentation attached.
 

Attachments

Secured
#2
This looks deceptively significant, Anton. I’ve already shared it with a friend working on a relevant project.

I know it’s called “Open API” but is it open source? How would someone who doesn’t understand crypto and just wants to hash data to factom utilize it? Are you guys offering to handle that as a service?
 
Secured
#3
This looks deceptively significant, Anton. I’ve already shared it with a friend working on a relevant project.

I know it’s called “Open API” but is it open source? How would someone who doesn’t understand crypto and just wants to hash data to factom utilize it? Are you guys offering to handle that as a service?
deceptively? Have you carefully read this? :)

> I know it’s called “Open API” but is it open source?
1. It's open-source

> How would someone who doesn’t understand crypto and just wants to hash data to factom utilize it?
2. You install it on server, connect it to Open Node (in config), set private EC address in config and then just use it.
Paying own 1 EC per 1 KB of data.

> Are you guys offering to handle that as a service?
3. What do you mean? It's free to use open-source API. Open-source code, your server, your EC — you can use it for personal or commercial purposes with no restrictions.

--
Added to p.2:
Basically, unique EC address may be also generated inside Open API web UI, so you even don't need to download Enterprise Wallet or use MyFactomWallet :) You need just fund it and use.
 
Secured
#4
deceptively? Have you carefully read this? :)

This may not have translated well. What I mean is that this seems more versatile and valuable than most people realize at first glance. It’s awesome!

> How would someone who doesn’t understand crypto and just wants to hash data to factom utilize it?
2. You install it on server, connect it to Open Node (in config), set private EC address in config and then just use it.
Paying own 1 EC per 1 KB of data”

My concern is that this is more than my friend (as one example) can handle. Most projects that could make great use of this API in the near future need the crypto/token aspect abstracted away to even consider it.

I suppose the next step is for BaaS providers to integrate the API into their own offerings and for them to onboard projects that can’t deal w crypto.

Either way this is great and I’m excited to it it further develop.
 
Secured
#5
@damo sorry, I misunderstood your phrase :)

As a developer, that joined Factom community in Jan 2018, I realised, that although factomd & factom-walletd API are well documented, it's pretty hard for non-blockchain developers (whom I was in Jan 2018) to setup all environment (node, wallet instance) and start using it (write SDK, figured out how all calls worked, how transactions signed and etc.).

To be honest, it took a lot of time (not a single day) to start writing data on Factom for me.

Then I realised how to make this process easier for traditional developers like me.

After a lot of discussions, questions & suggestions (Niels remembered them all, I think :D), we finally combined it in this project proposal.

So, with Open API, the process may be:
1) Install Open API (via git clone or docker) on any server
2) Setup config with factomd URL (pretty good we have launched Open Node, you can start developing without waiting your own node to sync, then switched to own node if you want) & Es address (or generate it in API, so no need to touch wallets)
3) Fund EC wallet with Entry Credits, converting it via any wallet or buy in EC Store (already launched by us)
4) (optionally) Download SDK for your language and just use it

How much time does all of it take? 20-30 minutes, I guess, including 10 minutes waiting till EC funding tx processed :D
Is it much easier than low-level APIs even with SDKs? I'm totally sure it is.
Does it provide additional valuable functions comparing low-level API? Absolutely.
May it attract new developers & enterprise with own dev depts from different industries? I think it will.
 
Secured
#6
My concern is that this is more than my friend (as one example) can handle. Most projects that could make great use of this API in the near future need the crypto/token aspect abstracted away to even consider it.
Buy entry credits in store (our or Inc's) and don't touch crypto & wallets at all.
As one of the options for enterprise who doesn't want to touch crypto.

I suppose the next step is for BaaS providers to integrate the API into their own offerings and for them to onboard projects that can’t deal w crypto.
Sure. Take Open API, add your billing and sell.
That's what we will do.
I recently has a discussion with one of ANOs about this.

Having Open-source API won't create any issues in selling APIs as subscription (what Factom Inc, Sphereon & De Facto actually do right now), cause selling API you provide not only API, but additionally your expertise, support and environment.

So there always will be people who needs BaaS, and people who don't need this.
The first category will order BaaS from Operators, the second category will use Open API :)
 
Secured
#7
I suppose the next step is for BaaS providers to integrate the API into their own offerings and for them to onboard projects that can’t deal w crypto.
.
Although I applaud Anton with his open API I do not see that happening. Yes you will see people using open api, but when you want to do BaaS yourself you often have pretty specific requirements and running the actual API using php isn't the most obvious choice. Most low level clients nowadays also provide most of the simplicity the Factom BaaS solutions from Factom, Sphereon and DeFacto provide, minus the queueing and indexing, but these are pretty trivial to create.
 
Secured
#8
@Niels Klomp

1. No matter what language used for running API. You use it in Docker (no need to setup specific env by yourself)

2. You code in the language you know, using REST endpoints or GraphQL.

3. We explored languages for writing API before starting the development. PHP even has a little faster TPS than NodeJS according to a lot of tests I found on the Internet ;) but both of them have almost the same TPS

Also, I don’t know NodeJS frameworks that allow to run simultaneously REST endpoints and GraphQL. But Yii2 that we use allows to do it ;)

Sure, BaaS companies that already have own APIs with the similar functions, will rarely migrate to Open API to not rebuild own existing processes.

But for companies that don’t have own APIs — it’s the way to start providing BaaS without investement into development the own solution.
 
Secured
#10
You aren't getting what I was saying and assuming a BaaS solution provider would be using REST itself, which adds overhead. So if a BaaS solution provider want's to make changes it does that on the BaaS layer and not on the SDK layer obviously.

I would use neither of those ;)(
Now I got it ;)
Yeap, this is true.
Everyone may fork open-source solutions if needed to make some custom features.

But the initial idea is to provide high-quality product that has all needed functions, so I started this thread to collect a feedback on functions.
 
Secured
#13
@Paul Bernier
I have thought about it too before decided to develop Open API :)

It’s like the tool & the service difference.
You sell API subscription or usage (Harmony / Enterprise API / Sphereon API) as a service, which includes set of environment + code + your expertise + support.

Without all of this, the API is just a piece of code — it’s not unique, everyone may create the same thing.
The end-clients don’t need API as a code, they need it as your service with your expertise and support.

That’s one of the reasons we will apply for this grant — it won’t make troubles selling Enterprise API to enterprise clients at all, as won't make troubles to Inc. selling Harmony, and Sphereon — selling their API.