Use static site generator or React integrated backend? #236
Replies: 3 comments
-
|
https://www.gatsbyjs.org/ may actually be a great fit for doing exactly that. As a bonus, we would get all the React goodness, however we should be careful in delimiting build-time rendering (which should be maximized) and client-side rendering (which should be minimized, to be used for instance for the dynamic sponsors display). Not sure how much of it is static, which we would prefer. |
Beta Was this translation helpful? Give feedback.
-
|
Also we should evaluate the feasability and convenience of switching to a fully JS-integrated workflow, and replace our entire stack. For instance, maybe we should consider:
IMO it is still important that the website works even if JS is completely disabled, which is why we're still using good old Express and server side templates with Nunjucks. It feels like the learning process will be tough in any case, so if we can constrain the developer with solid best practices, documentation and a framework that can catch as many bugs as possible, it would be better anyway. |
Beta Was this translation helpful? Give feedback.
-
|
With the microservices route, we could use NextJS for SSR. As such we could write the entire front-end app as a React app, and let other services handle content management, etc. Moving this to discussions. |
Beta Was this translation helpful? Give feedback.
-
Motivation
From the start I wanted to create a content management system (CMS) that only used files (no database). The goal was to have a standalone, file-based, version control friendly software that could be automagically deployed without additional configuration or system stack.
However, the software in its current form still requires manual editing of files (which in itself is not a problem). But I believe the software can abstract the content system further, and this abstraction could be controlled through a GUI software, which would help non-developer content editors manage the system.
Thus, I would want to ideally produce a standalone flat-file CMS that bundles this abstraction, the GUI software that controls it (for instance using electron), which generates files in the system itself, which can be tracked and version controlled (also through the GUI), and also deployment tools. The GUI (based on web technologies), could also be used to preview the website in itself. Still, no database would be required.
Examples
I stumbled upon https://getkirby.com/ which my gf used for a project, however it is a proprietary, paid license system. I realized that what I actually wrote for the CLIC website was very similar (although far less generic) than this file-based CMS. Thus, I believe I can write an equivalent system, that could be free and open-source, and there's probably a lot more potential in this.
Proposed implementation
There are 3 parts to the system: the web server (which is also used in production), the GUI that controls the files, and the machinery that glues everything together, which implements the content-file abstraction and tools for development and deployment.
Web server: ideally, it could be language agnostic (or at least, we could easily produce different versions of the core server): this would allow deployment on many different platforms (the backend could be either of NodeJS, PHP, ...)
GUI: an electron app (ideally, it bundles itself and all the other parts of the software including the runtime, so that content editors can simply download a binary or something). This would be an admin panel where all the content is managed, and versions could also be pushed through a GUI to Github for instance (either directly to master or through pull requests). The GUI should also be able to display the actual web server, allowing quick preview in the software itself.
Glue: written as logic behind the electron app, it will only run client-side anyway.
Beta Was this translation helpful? Give feedback.
All reactions