We also need to consider the backend for such generators, the current sites can be deployed on any server - while server side rendering or static site generators require a specific setup and configuration on the backend… I think what we’re aiming at is a template that can be generated and deployed on its own, without any further server configuration.
For our purposes, where we’ll be displaying a lot of current content, the existing solution works better. We can also add a pre-render plugin that allows non dynamic content to be statically generated for web crawlers.
I thought about static sites that are redone every x hours or minutes and of course pulling the content and structure from discourse. Or even better (but more prone to mistakes and complicacies): are every time a topic in the relevant category is created/edited (but I can imagine that there are nasty edgecases, like it would also really need a rebuild when peoples profiles are changed etcpp, might become a mess to do this properly).
Yes, sure. That would also work. This is in fact how the earlier attempt of the Culture Squad site is deployed. It’s a little bit trickier to get right.
Its true that you need additional infrastructure and I do not want to stand in your way of doing it.
I just thought that I should share the approach I would have chosen: On the same box where discourse is run, generate the static pages and push them to whatever location where there are served. You need infrastructure to BUILD the site (run the generator), but the hosting afterwards is trivial (1990s: usually it will just be html + css + image files, but of course you could also add js + vue on top; just saw that there are static vue site generators).
Actually, with Netlify, which we use, it is extremely trivial. Just pass the build command to Netlify (for example yarn build) and specify where the dist folder ends up, and Netlify does the rest. Great when it works, which it often does.
You need infrastructure to BUILD the site (run the generator), but the hosting afterwards is trivial (1990s: usually it will just be html + css + image files, but of course you could also add js + vue on top; just saw that there are static vue site generators).
I think there is a middle ground. We could use Nuxt to generate the site when static content (the content in the JSON file) is modified (Netlify takes care of this). Then client side API calls for fetching content for components such as Events, People etc.
Nope there was no particular standard (I’m not aware of any JSON standards for static site generators, although surely some attempts at making some exist)
Bit late, but I’m catching up with unread threads now eventually …
A few points:
I’m not sure if that refers to a formal JSON schema or just an informal definition. Just saying: please define a formal JSON schema, it really makes life easier. You’d then also use a validator for that schema, which for Vue.js will probably be vue-vuelidate-jsonschema.
I have been toying around (here) with the idea of providing structured data in Discourse posts as JSON embedded inside Discourse posts as code sections. That would address most of your question (for bios, calls, campaigns) except for “content types” that we expect “normal users” to contribute (events, stories), which would require plugin-provided custom fields in Discourse to ensure nothing can be entered the wrong way.
Now for this “JSON in Discourse posts” idea I discovered that editing and viewing JSON in Discourse code sections is cumbersome. YAML seems much better for this application, as it allows multi-line strings, comments etc… I’d like to strongly encourage @owen to evaluate if YAML is a good data standard for the modular web kit as a whole, and if so, to use it for that. It’s just a superset of JSON anyway – so even if we don’t evaluate this now, I might still introduce it as our standard data exchange format later anyway (in case it’s a matter of funding / resources at the moment). Just as a warning that I have this in mind
And @felix.wolfsteller: I share your points about Vue.js web applications. However the larger concern for me is to fracture the Edgeryders-wide IT landscape as little as possible. If we require Vue.js capabilities for some websites, it’s better to use it as the standard for all websites, due to skill reuse, learning curve, server admin effort etc… I propose we will not use Nuxt.js again: it may be able to generate static sites, but otherwise is just another JS framework, largely adding just redundant complexity. If we were to add a static website generator for websites fed from a Discourse forum in some ways, I’d rather go for something close to the Discourse ecosystem: based on a static website generator written in Ruby. Because that makes it more useful for others who have a similar need for a website associated to a Discourse forum. We did some initial work on this concept here, and it’s feeding three of our websites so far. I’m not yet sure what should be the fate of this piece of software, as I quite liked the way it works …
I like this idea. I have used YAML myself to store localization strings in Ruby projects. I didn’t suggest it because I didn’t know that it was suitable for storing ordered data too. It seems to be a pretty perfect fit. Rewriting the form to also use YAML should be pretty trivial too. I support evaluating this option.
I just had a talk with @gdpelican, and we planned for a meeting on January 13th at 09:00 AM CET to talk about the framework and the tasks ahead. I have sent you calendar invites @matthias and @owen.
Our initial conversation was that he would work on:
The API plugin for Discourse
Front end framework data-flow architecture
Implementing the form to integrate with the framework
Code review of the project and recommendations
However, we can make a decision together on how to structure the work once we talk in January.
Alright, I think I’ve made a good head start on this one this weekend; you can check out the functional plugin here:
I’ve done my best to write a quality README for some details on what it does, but the tl;dr is
There are three endpoints, one for topics, categories, and users
All resources can be paginated by passing from and per params
All resources have a custom serializer to match as close as possible to the format outlined in the node app (I’ve made some changes to unify the discourse fields with what it’s serialized out as; there’s not much point in having the same value called bumped_at on the backend, but last_updated on the frontend, for instance)
All resources can also accept a serializer param, which allows us to change up the format of the JSON we get back. (it’s not quite GraphQL, but writing new serializers will be trivial as we run across new use cases). Topics can now be rendered as ‘topics’, ‘events’, or ‘organizers’, which were the three use cases I came across in the given node app.
Topics can be filtered by any number of tags or categories by passing a categories or tags param
@owen, great work so far! I have created a project scrum board for us on GitHub. We will use it to track the progress of the entire project, including the plugin that @gdpelican is working on.
@owengo to the scrum board and check the issues that I have assigned to you. Add any tasks that you are already working on or have on your todo list. Everything we plan to do in the next couple of months should be on that board.
@gdpelican, can I ask you to do the same thing? I have added you to the org.
I just tried accessing the topics endpoint, and it looks like it works.
I propose the following division of labor now: @gdpelican moves on to integrating the webkit client components with the new plugin endpoints. I have added that as a task to our project scrum board. @owen focuses on the other tasks assigned to him
But Daniel will install it today or tomorrow, and then you can test.