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).
3 Likes
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)
1 Like
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 …
3 Likes
Yes, please!
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.
1 Like
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.
2 Likes
I think you mean January 13, right? At least that’s what the Google Calendar invitation was for:
Meeting with James about Web Kit
Mon Jan 13, 2020 09:00 – 10:00
Yes, sorry! January 13th, this coming Monday.
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
fromandperparams - 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_aton the backend, butlast_updatedon the frontend, for instance) - All resources can also accept a
serializerparam, 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
categoriesortagsparam
4 Likes
@matthias, do you have time to verify and install? I’ve set aside resources for you for that sort of work, so keep a tally of your hours.
@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.
@owen go 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.
2 Likes
No, very low on time 
But Daniel will install it today or tomorrow, and then you can test.
1 Like
It’s installed now. (Didn’t test it myself, so go ahead and test it … .)
1 Like
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
Does that sound sane?
2 Likes
Sounds good to me; I’ll have a crack at that tomorrow evening.
1 Like
Sounds good, will have another update shortly.
1 Like