Successful [DeFacto-001/2] Factom Open API – Sprint 2 (Admin API, Web UI, callbacks)

Was Factom Open API (Sprint 2: Admin API + UI + Callbacks) Successful?


Have not voted

Authority Nodes DBGrow DBGrow HashQuark LUCIAP LUCIAP

  • Total voters
    29
  • Poll closed .
Update #1
Grant completion:
35%

What's ready:
  1. Refactored Open API config
  2. Implemented API server restart
  3. Implemented UI skeleton with webpack & assets mapper
  4. Designed UI using React
  5. Implemented Admin API calls group with separate admin authorization
  6. Explored different authorization methods & security issues of different token storage methods
  7. Implemented JWT authorization for Admin with storing access token in HTTP-only cookie
  8. Implemented API calls for user management
1562161692773.png

What's next:
  1. Open API 1.1.0 release with Admin API & UI (scheduled on 22.07-04.08)
  2. Open API 1.2.0 release with Callbacks (scheduled on 19.08-01.09)
 
Last edited:
Update #2
  1. Admin API calls implemented
    1. GET /queue — Get all unprocessed writing tasks & tasks processed within last 1 hour
    2. DELETE /queue — Manual delete task from queue
    3. GET /users — Get all API users
    4. POST /users — Create new API users
    5. DELETE /users — Delete API user
    6. PUT /users/:id — Update API user
    7. POST /user/rotate — Rotate API key for user
  2. Finished UI for user management
  3. Finished UI for queue monitoring & management (+ queue monitor is updating in realtime)
  4. Echo REST API lib is updated to latest version (4.1.6), some bugs fixed (included the minor issue we found)
We made few videos of live interaction with Admin UI:

1. User management

2. Queue monitoring
 
Last edited:
Factom Open API 1.1.0 released
We are pleased to announce next version of Factom Open API.
https://github.com/DeFacto-Team/Factom-Open-API/releases/tag/1.1.0

What's new:
  1. Admin API endpoints
  2. Admin UI built with React
    1. API Server settings
    2. User management
    3. Queue monitor
  3. Random EC address generation
  4. EC address funding via store
Also:
  • Minor bugs fixed
  • Undercover DB functions improvements / refactoring
  • DB connection status monitor
  • Moved to new version of Echo framework
  • Moved to new version of Factom lib
  • You can now run Open API without EC wallet at all (for reading entries, e.g.)
Screenshots of Admin UI are in the attachment.
More cool stuff for Open API is coming in the development Sprint 3 :cool:
 

Attachments

Factom Open API 1.2.0 released
We are pleased to announce next version of Factom Open API.
https://github.com/DeFacto-Team/Factom-Open-API/releases/tag/1.2.0

What's new since version 1.1.0:
  1. ver. 1.1.1
    1. Added getUser into Admin API
    2. Clean code
  2. ver 1.1.2
    1. Fixed bug with token rotation (Admin API)
    2. Fixed availability of embedded documentation
    3. Minor UI improvements
  3. ver 1.2.0
    1. Callbacks for new chains/entries
    2. Security fix in project dependencies
Callbacks are registered with query param while creating chain or entry:
https://docs.openapi.de-facto.pro/chains/create-chain
https://docs.openapi.de-facto.pro/entries/create-entry

Open API sends callbacks twice – when chain/entry is in processing state (sent to blockchain) & then when it is in completed state (included into Factom DBlock).
 
Unless my math is incorrect (possible), this grant was delivered past its projected due date.
This grant was delivered on Aug, 29.
3 days before deadline.

Also, could you lay out the reasoning on what made this grant "exceptional?"
1. I am excited about UI/UX, that we achieved to bring to API server, and also the quality of realisation.
2. We developed separate Admin API with separate auth method and separate admin API calls to manage API server: its settings, users, queue and etc.
3. Frontend written on pure React and connects to Golang backend via Admin API.
4. Callbacks are easy to register and use.

I suggest you to run Open API on Docker and try it by yourself ;)
It's basically 2 mins to start using this manual:
https://github.com/DeFacto-Team/Factom-Open-API/blob/master/guides/INSTALL_DOCKER.md
 
1. I am excited about UI/UX, that we achieved to bring to API server, and also the quality of realisation.
2. We developed separate Admin API with separate auth method and separate admin API calls to manage API server: its settings, users, queue and etc.
3. Frontend written on pure React and connects to Golang backend via Admin API.
4. Callbacks are easy to register and use.

I suggest you to run Open API on Docker and try it by yourself ;)
It's basically 2 mins to start using this manual:
https://github.com/DeFacto-Team/Factom-Open-API/blob/master/guides/INSTALL_DOCKER.md
Thanks for the clarification Anton. Are ^^^ all features that were not in the grant? Meaning, you and your team went above and beyond? Or, were these deliverables in the grant?

Thanks
 
Thanks for the clarification Anton. Are ^^^ all features that were not in the grant? Meaning, you and your team went above and beyond? Or, were these deliverables in the grant?

Thanks
I am not sure if I wrote about exceptional UI/UX in my grant proposal :)
To be honest, we made better UI than I expected to build when started the grant.

All other features are as described.
 
@Anton Ilzheev I remember a discussion about testing of the code, as you cannot create good quality software without extensive tests. Especially for an API product you also want to make sure you have no regressions and the API stays stable and giving the same results back over time. You mentioned you were going to create this. Could you point me in the right direction in the repo so I can ascertain whether your suggestion for a 9 makes sense? Thx
 
@Tor Paulsen I do not agree with Niels. Automatic tests != high quality code, and the opposite No automatic tests != bad quality code.

The good example is factomd with a lot of automated tests and a lot of bugs at the same time. From the other side Open API is very well tested and has no bugs.

I understand what Niels is trying to do with his assumptions about bad quality code and I won’t answer on this provocation.

The automatic tests are not a part of the grant proposal, and they will be developed eventually using ANO income — that’s what I said earlier and confirm it again right now.
 
Last edited:
Thanks for replying @Anton Ilzheev. I did look in your original grant application about testing and didn't find it mentioned (i.e automatic testing not explicitly mentioned - so you are right on that account). I did however notice that @Bedrock Solutions is listed as a sponsor for this grant.

Have they been involved in the development and gotten regular updates? If so they should also post their opinion of the grant in this thread before the vote closes (ideally before it opened really).
 
@Tor Paulsen To clarify for everyone. I don't say that testing are not needed, for sure, they are. And we are willing to add them eventually, but it's low priority right now among all other activities. Some factomd functions had no tests for years and were added recently, as far as I remember from someone's update. No tests doesn't mean the product has bugs, having tests doesn't mean the product has no bugs.

Regarding your question about @Bedrock Solutions. They didn't develop by themselves, but helped me a lot in discussing/exploration of admin session security and their advices regarding React development were very very valuable.
I am glad having them as a sponsor and looking forward to work together in the future!
 
@Tor Paulsen To clarify for everyone. I don't say that testing are not needed, for sure, they are. And we are willing to add them eventually, but it's low priority right now among all other activities. No tests doesn't mean the product has bugs.

Regarding your question about @Bedrock Solutions. They didn't develop by themselves, but helped me a lot in discussing/exploration of admin session security and their advices regarding React development were very very valuable.
I am glad having them as a sponsor and looking forward to work together in the future!
To clarify; I didn't mean to ask if they had been actually performing development - but if they had followed along with the development as a sponsor and gotten regular updates. The sponsor role is created to ensure that at third party can provide some kind of grant oversight and report to the standing parties. My question was if you have been keeping them in the loop and provided them updates so they could provide that oversight function as you have listed them as a grant sponsor.

They have received 300 FCT to be a sponsor for this grant, and as a sponsor they should report their findings to the community (which it seems that they haven't).
 
Since when is the absence of tests quality software design? It says to an extent nothing about the quality of the code itself. It says something about the developers though, as they cannot guarantee the code to be working, remain working and stay consistent in behavior. Part of my book and all of our devs book is that software is not done without proper tests.

You promised to do it, so how is this a provocation? You mention a 9 and I am questioning how it can be a 9 without proper tests.
 
Turning it around is also kinda off odd. No, having tests does not guarantee quality software. But at least it allows me to build further on it. For instance doing refactoring and guaranteeing the refactored code is behaving as the original code.

I find it odd to have to have this discussion with a developer tbh. Or saying it is low priority. Every developer knows testing is part of the development process itself. You do that during development or even up front not after a project is finished.

It might not have been mentioned in the grant but I do hope we can at least agree that testing is part of development and as such should not have to be mentioned as a deliverable
 
Last edited:
To clarify; I didn't mean to ask if they had been actually performing development - but if they had followed along with the development as a sponsor and gotten regular updates. The sponsor role is created to ensure that at third party can provide some kind of grant oversight and report to the standing parties. My question was if you have been keeping them in the loop and provided them updates so they could provide that oversight function as you have listed them as a grant sponsor.

They have received 300 FCT to be a sponsor for this grant, and as a sponsor they should report their findings to the community (which it seems that they haven't).
Hi Tor,

I can confirm Anton provided us regular updates on his progress during the grant period. This included high level design discussions early on, as well as test builds that we were able to interact with directly. We believe Anton's updates at the top of this thread are an accurate portrayal of the work completed for this grant period, and that the grant should be rated "Successful". Thanks for asking, and let me know if you have any more questions.
 
Hi Tor,

I can confirm Anton provided us regular updates on his progress during the grant period. This included high level design discussions early on, as well as test builds that we were able to interact with directly. We believe Anton's updates at the top of this thread are an accurate portrayal of the work completed for this grant period, and that the grant should be rated "Successful". Thanks for asking, and let me know if you have any more questions.
Thank you very much for your comments @David Kuiper. Very much appreciated.

I will vote this grant a success.
 
Top