Open gruhn opened 6 years ago
molnarmark
commented
6 years ago If there is a front end that is customizable by lets say, the owner of the static site, the data that was modified still need to be sent over an api to store the relevant json though.
gruhn
commented
6 years ago @molnarmark by front end, do you mean the web site or the GUI I proposed for modifying that web site?
My idea is: You have static JSON files in the project folder -> with the GUI they can be modified in a convenient way -> to deploy those changes the GUI sends them over the same channel it initially got the project files from (sync via FTP, make Git commit, ...)
So no additional API needed, if that is what you meant.
mbrobbel
commented
6 years ago gruhn
commented
6 years ago @mbrobbel thank you very much. I'm not entirely sure yet that this covers exactly what I need but this is definitively going the right direction.
FedericoCeratto
commented
6 years ago https://github.com/spanezz/staticsite is context agnostic and allows using Git
Project description
When I'm building web applications for clients, of course I have to provide some kind of CMS so they too can customize content. It's time consuming to get comfortable with a CMS and it's concepts though. And anyway, no matter how good that CMS is or how well it fits the use case, most of the time I end up having to implement something the CMS wasn't designed for. Than seemingly simple stuff becomes hacky and expensive. I find that really frustrating. Furthermore, most CMS don't separate "fluid" data from static data that defines the application like templates, installed plugnis and so on. They just store all that in a database. The database is not tracked in Git. I frequently encounter issues because of that. My master branch is up to date but I can't reproduce some issue because I'm missing changes in the production database.
I wish I could build my application as if there were no client I have to take care of.
Headless CMS like Contentful are doing a great job to separate data from the application. The client gets an interface to modify data which the application then just consumes over an API. Apart from the problem that there are little open source and self hosted solutions, headless is sometimes not enough. What if the client wants to customize the layout himself? Rearrange view elements or add pages? You can encode that information in JSON or whatever and pipe it through the API too but than I have to adjust my application to that stuff at runtime. That introduces a lot of complexity and also extra latency when rendering pages.
All this dynamic processing is just there to make including custom content more convenient for the client. Static site generators handle that at build time so it doesn't affect performance at runtime. Static site generators are often very opinioned though. I have to adjust my application so it works with their build process. But I already use webpack or browserify or whatever. Also static site generators rarely provide a UI so most clients can't really handle that.
Publii is a pretty cool approach. A static site generator with a native UI. You can modify and preview changes to your site offline and deploy easily. Publii again is very opinioned though. It's made for specific use cases and I have to build my application around Publii.
It would be cool if the client would just get some kind of UI that would allow him to modify the code base of my application without having to understand the code. The client would just be another developer in the team using a special editor. So:
This special editor, let's call it the front end, would only be able to understand Git repos and FTP servers and such. It would be extendable with plugins. Each plugin would just teach the front end how to deal with certain types of files and provide a visual interface for the client.
To preview changes or build the application, allow the front end to trigger the dev-server or build process you would use as a developer.
To install plugins run
When you start the naked front end, the user passes a URL and maybe login credentials to a Git repo, FTP server, local directory or wherever the projects source code is stored. The front end pulls the code and loads the front end plugins listed in the
package.json. An optional configuration file in the projects root directory would be loaded too.With plugins developers can control what their clients can modify in the application.
Those are just my thoughts on this topic. I don't know if this is doable in practice or if there might be better solutions to those problems. I'd love to here feedback.
Relevant Technology
I'm not really settled here. I guess
npm/nodeare mandatory. The front end has to support npm packages (the plugins), hence web technologies. So it would make sense to build the front end with electron also providing platform independence.Maybe front end users need to install a lot of tools involved in building the application. Some solution with docker might bring some convenience.