[RFC] Expose serveApp so we can embed Glance

[rubiojr]

I've been toying with the idea of building a small desktop app powered by Glance, fully packaged and without the dependency of an external browser. To do that, Glance would need to expose a public package that I could reuse.

This is how such a public interface could look like, starting simple.

https://github.com/rubiojr/glance-embed is a sample app embedding Glance using this exposed package.

@svilenmarkov would something like this be accepted?

Mostly a request for comments, to figure out if this would be a welcome addition.
If something like this is to be accepted, it may be a good idea to add a context argument, so the Glance server can be shutdown gracefully programmatically.

[svilenmarkov]

I think the changes made in the PR are fairly safe to proceed with, however with the ever-increasing scope of what Glance does, it means that I have to be more mindful when potentially making changes to how the app gets served since this is a very different use case.

I'm not sure what you plan on doing with the desktop app but I can see the current API of only providing a path to a file not being ideal, as down the line you may want to directly provide the contents of the file through the API. Having the ability to do that would likely require a bunch of changes.

The point about adding a context argument would be a good addition so it makes sense to have that in place before going through with this.

[rubiojr]

however with the ever-increasing scope of what Glance does, it means that I have to be more mindful when potentially making changes to how the app gets served since this is a very different use case.

Indeed, certainly not to be taken lightly for a busy project like this. If it helps you with the decision making, vendoring Glance with a small patch is totally doable on my side.

I'm not sure what you plan on doing with the desktop app

It's going to be (at least for now) a private team dashboard, and the only goal with this is to ship it as a single binary that will simplify packaging, distributing and running. I also have to bundle an additional http server that powers a few Glance extension widgets defined in the config, so bundling everything together will simplify things.

but I can see the current API of only providing a path to a file not being ideal, as down the line you may want to directly provide the contents of the file through the API. Having the ability to do that would likely require a bunch of changes.

For my specific case, it's actually not too bad, since (I think, strategy still needs be tested) I can embed the config in the binary, drop it to /tmp or another private config area and boot pointing at it. Agreed that from a Glance PoV, it's a bit limited and not ideal as a public API you're commiting to.

The point about adding a context argument would be a good addition so it makes sense to have that in place before going through with this.

Totally. Let me know if you wanna move forward with a public API and I'll have a look at it. No rush 🙏.

[svilenmarkov]

If it helps you with the decision making, vendoring Glance with a small patch is totally doable on my side.

Since you bring this up as an option, would you be okay with doing that for a while until you've gotten a little further into your project's development? That would give you a better idea of the kinds of needs you may have from an API like this.

I also have to bundle an additional http server that powers a few Glance extension widgets defined in the config, so bundling everything together will simplify things.

Yeah, I get that. It's why I added the custom-api widget which removes the need for additional servers in most cases, but that comes with its own set of limitations. I really wanted to make the extensions dynamically loaded modules which would've allowed you to hook into a lot more things, but Go's plugins come with a ton of quirks. I am still in search for something more convenient and powerful, and I'm really hoping that Lua isn't the answer.

[rubiojr]

Since you bring this up as an option, would you be okay with doing that for a while until you've gotten a little further into your project's development? That would give you a better idea of the kinds of needs you may have from an API like this.

Totally, I'll report back.

Yeah, I get that. It's why I added the custom-api widget which removes the need for additional servers in most cases, but that comes with its own set of limitations. I really wanted to make the extensions dynamically loaded modules which would've allowed you to hook into a lot more things, but Go's plugins come with a ton of quirks. I am still in search for something more convenient and powerful, and I'm really hoping that Lua isn't the answer.

I still have to test how custom-api would fit in my case, maybe good enough for some of the widgets. It wasn't available when I started experimenting with Glance.

Re: Go plugins, Any thoughts about using something like Extism?

[rubiojr]

Closing this for now, I'll post back once I have something more concrete.