FontraWeb: Serverless Fontra

[simoncozens]

So I've been playing recently with a little idea I'm calling FontraWeb - it's Fontra, but with the Python server made optional, and replaceable by a Rust-based WASM implementation.

It's obviously very, very incomplete right now - there's no support for saving yet, for example, and it only supports loading Glyphs 3 sources over the web - but it's working as a proof of concept. I think there's something compelling about the idea of thinking "There's a Glyphs file in some GitHub repo and I want to edit it", clicking a button in your web browser and there it is.

To build this out into a full web-based font editor, the steps would be:

• Add change tracking and exporting to the Rust backend
• Finish off Glyphs 2 and UFO/DS support in babelfont-rs
• Add export serialization (saving) to babelfont-rs
• Use octocat-plugin-create-pull-request to save changes to GitHub-based fonts as PRs
• Build out proper implementations of the backend API functions I have currently just being mocking (And yes, that means Boolean Path Operations in Rust, and that means a lot of porting. I know. :-) But we need it for other stuff too, so it's useful work...)

Anyway, this may go some way to explain what's behind some of my contributions recently...

[justvanrossum]

Cool! I had this kind of usage in mind when sketching out Fontra's block diagram. It would be cool if it could also support local files via upload/download or the file system API (which may be Chrome-only at the moment?)

[simoncozens]

That's a very good idea! Will add.

[justvanrossum]

Not that I will have the cycles to intensely look at it, but where is the source code for FontraWeb?

If you'd rebase, perhaps https://simoncozens.github.io/fontra/fontoverview.html?https://cdn.jsdelivr.net/gh/googlefonts/googlefonts-project-template/sources/RadioCanadaDisplay.glyphs could work? (Work in progress, but it's getting somewhere.)

[simoncozens]

It's at https://github.com/simoncozens/fontra/tree/serverless - the code is pretty gross at the moment as most of it was written in a mad sleep-deprived hacking run at the end of last year. It will get tidier, and I am hoping we can bring the branches closer together (hence #1919). Currently each of the view pages needs a small bit of "kick-off" Javascript to make the webpack bundle work, so fontoverview won't work as-is but won't be too much work to add.

[justvanrossum]

I now understand the challenges of getting this to work more.

I think we should do the following:

• Generally make the front end less dependent on the server and its quirks
• The server should do less magic:
  • serve static content from a fixed root folder
  • serve the web socket
  • some optional server specific plugin features
• The "view" plugin mechanism is a server feature, but should not be required, so that alternate deployments (ie. serverless operation) become more feasible
• Therefore, the builtin views (editor, fontinfo, fontoverview, applicationsettings) should not use this mechanism, and their place in the repo should follow how they appear to the front end. Ie. the contents of "views" should move to "client". Perhaps this means we can use relative imports everywhere, which could also benefit this request: [idea] Add an option to host the service under subdirectory #1352
• The view "entry points" (eg. /editor/editor.html) should be renamed "index.html", so we can use "/editor/", and will not need server magic. This adds the assumption that a server can be configured to serve "index.html" for "directory" requests.
• The project id should not be a virtual path ("/editor/-/path/to/project") but should be part of the query (eg. "/editor/?id=somestring-that-identifies-the-font"). This should allow is to have more consistent URLs between deployment types.
• I'm not sure yet how to handle the "landing" stuff, that is now done via the project manager plugin system. Perhaps a deployment should simply provide a "/landing/" view, and a root index.html would redirect there. Or we think of a flexible way to configure what to serve as /.

There are probably things I overlooked, but all in all I think this would be a doable refactoring.

[simoncozens]

I'd also consider getting webpack or similar to bundle the bulk of the application into a single JS file, as I do; it handles cache busting for you, and resolves all the imports statically. (which helps with #1352) How that would interact with potential plugins, I'm not sure.

[justvanrossum]

We use rollup for preparing the npm dependencies. It should be able to package the whole thing, too. Should definitely be a deployment option.

[simoncozens]

I'm already doing that in the serverless branch. :-) (With webpack, because it handles WASM better.)

[justvanrossum]

I know you’re doing that because you said so. All I’m saying is that I wish to support that out of the box. Yet I also want to keep being able to run from the source tree as that’s just extremely convenient.