Replies: 5 comments
-
|
@s314cy How would this work? Would the admin panel be directly integrated to the website or will it be a separate client? |
Beta Was this translation helpful? Give feedback.
-
|
The admin panel can either be a seperate service or directly hosted on the website (there certainly exists an expressjs library for this). The goal would be to stop storing databases/json files on github, so no github tracking would be needed. This is relevant only if we intend to keep the same stack for the foreseeable future, which might not be the case considering the committee's will to have a python backend (some frameworks propose an admin panel out of the box -- hello django). And yeah @dialexo, you and I still have to talk about #66. |
Beta Was this translation helpful? Give feedback.
-
|
@s314cy I personally don't think this is a great idea, the main reason we used a git-based workflow was so that everything was tracked, backup'd and deployable with near-zero configuration e.g. if the whole system crashes (also because the main expectation was that people in IC should be able to use Git and edit Markdown files). Also migrating the stack from Node to Python seems like a terrible step back, performance would be terrible (https://www.simform.com/blog/express-vs-django/) and we would run into the eternal issue of having people able to code in 2 different languages for the back and the front-end. IMHO switching back to Python sounds like a bad case of golden hammer. Note that I am not saying that 100% of the website should be static (otherwise we would just use some kind of generator such as Jekyll or Gatsby), but that we should minimize the dynamic parts to the necessary relevant domains (e.g. highly dynamic data such as rentals, entity management, etc.), and use Git-able, flat-file based content storage for static stuff such as news, and pages such as about, commissions, etc. In my opinion keeping the NodeJS stack is the logical choice (another possibility would be to switch to a e.g. fully Scala codebase, with transpilers such as ScalaJS for the front-end, but this sounds like far too much overhead for what we need to achieve). Now, for sure there are definitely many many many things we could (and should!) improve in the current architecture, with a framework that is more opiniated and that imposes good rules and practices. One example would be to use NextJS for instance, and use existing tools for keeping the static part in check (things like ajv) and accessible through server-side rendering, progressive enhancement / graceful degradation, etc, while keeping the flexibility of highly dynamic React front-ends (with out-of-the-box support from NextJS!) and modern toolset that the Javascript / Typescript currently has (great developer experience such as live hot reload, type-checking, next-gen compilers (e.g. babel), static analysis tools such as ESlint, etc). All of this is related to #66 of course. I'd be very happy if you can bring up my opinion to the committee @s314cy although for sure we need to have a chat about all of these topics |
Beta Was this translation helpful? Give feedback.
-
|
If we go the microservices route, using a headless CMS like Strapi would make a lot of sense. Moving this to discussions. |
Beta Was this translation helpful? Give feedback.
-
|
We're using Strapi now at https://github.com/clicepfl/clic-website-v2 |
Beta Was this translation helpful? Give feedback.
-
Add an admin panel to easily edit json files used for news, events, etc.
Beta Was this translation helpful? Give feedback.
All reactions