Gui about elk HOT 18 CLOSED

I'll have a look at it. Thank you for the suggestion 😊

from elk.

Gio can compile to Browser, Desktop and Mobile from the same code. Just like flutter.

it’s much easier to debug and extend imho if your already a golang we coder.

in the last month many developers have started to build apps south it and support is stellar I find.

I will be happy to help build the gui for ent.

The chat app in gio is probably the most advanced and best practice at the moment, so worth looking at that one

from elk.

I am amazed how well it works 😱

One thing I noticed though: Google required new apps to be uploaded as AppBundle and gio does not support it yet, does it? Plus it is maintained by one guy, isn't it?

from elk.

About the app bundle, your absolutely right that Google has made it mandatory now!

I think it’s worth raising it on their issues on sourcehut and mentioning that it’s for Ent gui. They are eager to have the system used.

Also adding app bundling is quite easy when you look at the cmd folder. But I think if you raised it it will be added quite quickly.

One guy originated it, true. He is mainly working on the gpu shader acceleration which works well with other working on other bits now.

I also had the same concerns as you , but there are now 2 or 3 other deep into the team and some are paid by companies to work on it.

So yes it’s a small group compared to the massive Google flutter team.
I tried to use it for a project 8 months ago but decided not too. But am now using it for 2 projects as I can see how support and stability has picked up. The support is really great too and feedback within a day I have noticed.

there will be some rough edges but the core is solid.

from elk.

Also I just wanted to point out that if you wanted to add something to the flutter core you would have a really hard time.

with gio is so much easier to get things added / fixed, even at the core. Or do fo it yourself and get quick reviews via GitHub.

this I find is one of the highly attractive aspects.

from elk.

https://github.com/planetdecred/godcr is a good example of a big app btw

from elk.

@masseelch I raised the issue here about the Google Play Store bundling:
https://todo.sr.ht/~eliasnaur/gio/249

from elk.

@masseelch I think gio does support bundling ( . aab ) . I just looked into the code, but have not done a deploy to google play store yet myself.

https://github.com/gioui/gio/blob/main/cmd/gogio/androidbuild.go

I will let the Issue in sourcehut stand to get confirmation though.

from elk.

@masseelch

Android app bundling works. I tried it myself.

See:

https://todo.sr.ht/~eliasnaur/gio/249#event-93164

from elk.

Also I just wanted to point out that if you wanted to add something to the flutter core you would have a really hard time.

I already felt that. My issue was opened 1 and a half year ago. Still no progress event though a lot of people complain about the same stuff.

Android app bundling works. I tried it myself.

Nice!
I still have some concerns though. But there is a lot to do on this repo. If you want to provide a gui for ent and need some help setting up an ent extension, I am happy to help. I reccomend using the gqlgen extension as backend though. Its the new cool stuff compared to Rest.

from elk.

hey @masseelch

ok, I can work on the GUI for Ent.

Can i get your feedback on the following ?

HTTP REST versus GraphQL

Can you outline why a GraphQL version is preferred. I ask so that i understand the tradeoffs and why you asked for it to be this way.

GUI side caching

I would like to eventually add caching to the GUI, and want to get your thoughts on this.

GUI caching is a useful for the Ent Admin GUI, but for any golang devs building projects using Ent and GIO. It gives perf, offline support, etc.

One way to do it would be to use genji ( https://github.com/genjidb/genji ) .

Genji can be embedded into GIO because, like GIO, it supports Browser WASM, Desktop and Mobile and is also Golang based. Desktop and Mobile use the badgerDB engine, and Browser WASM uses a memory engine ( IndexedDB is on the roadmap ).
I have been using Genji for about 6 months, and its been ok, but API changes a fair bit still.

The following sequence would be:

• When a mutation is sent from the GIO GUI to the Ent Server, the Ent Server updates the respective View, and then emits a change event using the Outbox pattern.
• The GUI would get the Change event via a subscription, and update the Genji Table.

I do not know how far the Ent team got on supporting the OutBox pattern, which is probably required to support the sequence. Do you know ?

from elk.

HTTP REST versus GraphQL

It is my opinion, that GraphQL will be the standard in the future and will replace REST any time soon. At least for newer APIs. It offers way more flexibility over REST. However, it is totally up to you, what backend you take. Note though, that theelk is still in development.

GUI side caching

Eventually this is a useful feature. Currently genji has no release though and is considered unstable as is elk. I'd say start the work and keep in mind you want to add caching in the future and consider it when designing the API (middlewares is what immediatly came to my mind). I do not know about ent OutBox.

from elk.

ok will use graphql and wait on caching.

Will let you know here how it goes...

from elk.

Looking forward to it. In the meantime I close this.

from elk.

Saw the OAS.

this will make it a breeze to gen the golang gui .

I want to integrate push also eventually. For example awhen record changes in the dB , it sends all clients the changed record.

I am using SSE and web sockets. Am leaning towards SSE as it’s now supported in every browser and is very simple to deploy.

The intent is to make the gui real time such that you see data changes so that collaboration is more complete.

So curious what your options are to do this ?

ent hooks is the way to do this ?

ent privacy can later model auth aspects ?

history catchup can be done by using the Outbox pattern where the events are stored in ent ?

from elk.

Hey @gedw99, sorry to only answer now. I did not get a notification on this issue since it is closed.

I'd prefer SSE too, since it works with http and this will prevent a lot of hassle that comes with using websockets.

I like the real-time idea. Hooks on a mutation are definetly the way to go. Keep in mind though to only notify connected clients when the query was executed succesfully and not when the hook is called.

I am still thinking about providing some options to spec generation to sync privacy and authentication.

Can you use Outbox pattern with just SSE?

from elk.

Can you use Outbox pattern with just SSE?

@masseelch
yes, its just push based on some event queue as a table in the db.

from elk.

I am still thinking about providing some options to spec generation to sync privacy and authentication.

@masseelch

i feel this is really important. Groups would need to be modelled and then Users.
A new Signup would then create the User inside Ent, and get default group.

The most flexible pattern is for groups to be in groups like a tree.

• Group A (Super Admin )
  • User ID 00 ( the actual Super Admin )
  • Group B ( Org "blah blah")
    • Group C ( role inside this org )
      • User ID 01
      • User ID 02

So you effectively have Orgs with their own groups and users inside it. And Orgs inside Orgs. Its a graph basically.
So basically you have a multi tenant solution then via this graph approach. But you also get scaling because you are able to split the normal data between the servers, with the Auth controlling access.

The Auth data is synchronised between each one.

• The Master Server has ALL the Auth data. Master Server can see all the sub groups ( Orgs and roles and users ).
• An Org Server B ( Group B above in the example ) only gets auth data that it can see.
• An Org Server C ( that happens to be below Org Group B ) can only see its data, but can be Administered by Org Sever B.
• etc. down the tree of Orgs and Groups.

Sync is such that ent hook changes to the DB that relate to Auth are the sync upwards and downward appropriately by NATS. The inherent Auth data inside nats itself drives the NATS sync, so there is not need to configure nats.

from elk.