How to go for a flask-admin "kind of" interface?

[aprilmay]

It's a very generic question, so i leave it open for comments and suggestions.

Many web frameworks propose a customizable "admin" interface, eg. Flask-admin, Django admin, etc. So, with a typical Sanic/Gino tool stack, what options do we have for such a facility?

[fantix]

167 provided some ideas on this topic.

[aprilmay]

Thanks! I also did some research, and also came to the conclusion that it's a long way, indeed. A solution based on GraphQL or plain REST, and Vue.js (or another web frontend) sounds like the way to go. That implies a Gino module exposing metadata and data with GraphQL or JSON REST, possibly with Sanic, Tornado and/or aiohttp. Do you have any kind of starting point in mind for that?

[fantix]

Yeah I was actually trying to do that too, with iView Admin, for company projects. The login API barely worked, and I didn't find time to continue yet. Graphene was planned, but it was too much to include at a time.

[gyermolenko]

don't know if it helps, but aiohttp_admin uses ng-admin but is migrating to admin-on-rest

[fantix]

@gyermolenko looks interesting! ..and familiar 😈

[aprilmay]

@gyermolenko and @fantix: thanks for the inputs.

This currently leaves us with a lot of choices in the architecture: rest vs graphQL, sanic vs aiohttp, react vs angular... emacs vs vi ;)

I think i'll try some options, and hopefully give some feedbacks.

[aprilmay]

Just a quick update (i've been diverted to many other works, and also a switch from sanic to aiohttp).

I started learning and experimenting with GraphQL, and grabbed the structure of graphene-sqlalchemy to create a graphene-gino package. Nothing that i can publish now, just a basic working proof of concept. The front end runs with Angular/Material and Apollo. A lot of work pending, but i find it's encouraging.

[amirouche]

@gyermolenko https://github.com/marmelab/admin-on-rest is archived, any update on where is going forward https://github.com/aio-libs/aiohttp_admin ?

[amirouche]

@aprilmay what is the rational for using graphql instead of REST. Can you (quickly) explain how you made your choice?

[aprilmay]

First, Graphql has metadata capabilities (schema description), which allows higher level operations (eg. relationships, types, caching) without too much hassle. Fantix mentioned graphene in this thread, so i had a try and i found the learning curve worth the effort. Apollo is also a popular and robust library, so all the bricks for a graphql based architecture are in place.

Compared to Django admin where the logic is mostly server side, i find Graphql more appropriate with modern web applications (Angular, React, etc).

So, it sounds like a reasonable choice compared to plain REST for starting such a project as of today.

@amirouche: are you planning to work on it?

[amirouche]

@aprilmay I am investigating the use of GINO / aiohttp for a new project and stumbled upon this conversation. I very keen to build "my own castles in the sky" (ref) so take what I say with a grain of salt.

Apollo is also a popular

I don't buy popularity by default.

and robust library

See this example extracted from the official apollo getting started:

const Feed = () => (
  <Query query={GET_DOGS}>
    {({ loading, error, data }) => {
      if (error) return <Error />
      if (loading || !data) return <Fetching />;

      return <DogList dogs={data.dogs} />
    }}
  </Query>
)

See the second if says something like:

If (it is not a not error, because handled previously and) it is loading or there is no data render a spinner

If it's not an error and it's not loading then why there is no data ? It might be because the query was not fired yet but the apollo documentation doesn't explain it and if it was that why isn't that "query not already fired" not part of the "loading" state?

Compared to Django admin where the logic is mostly server side

I agree.

i find Graphql more appropriate with modern web applications (Angular, React, etc).

Mind the fact that GraphQL is around for almost as much time as ReactJS and did not gain as much adoption.

I like the idea of GraphQL as standard way to query the backend but I think it is missing some bits. As of yet, with GraphQL, I don't know:

• how to query "graphical data" like trees (think of hierarchical menu, user / group hierarchy, whatever...).
• how to enforce access rights (ACL)

it sounds like a reasonable choice compared to plain REST for starting such a project as of today.

IMHO it only looks reasonable. From a marketing point of view, I see that it will be possible to sell that experience. From an engineering point of view, I am not buying... yet!

[aprilmay]

Very valid points. Don't buy anything from me either ;)

I can give some information, from my experience with a prototype (Angular/Apollo and Aiohttp/Gino):

• handling of the request states is not really an issue, imho (at least, i didn't have to go to such detail, Angular and rxjs give abstractions over an async producer/consumer model, i assume reactJS would do the same)
• ACLs: Graphene gives a "info" parameter where you find the request object from aiohttp. So, ACLs are no different from any other HTTP request (eg. "from aiohttp_security import check_permission")
• complex structures like trees: i don't think that Graphql deals with such data structures natively. I implemented a menu with 2 levels (category -> model) quite easily. A generalization would require more work, eventually. If i understood your point correctly, it would also depend on defining a tree structure for models on Gino's side. Afaik, Flask-admin or Django admin don't go that far.

[ShahriyarR]

I saw this project recently: https://github.com/xnuinside/gino-admin

Maybe it can be mentioned in the docs.