linc Has anyone written about the current challenges being faced? I assume this will involve a considerable backwards-compatibility break so I'm interested in what goals are in mind for this.
Not publicly yet, but this has been discussed internally somewhat. The main goal is to change the API for extending the JSON:API from "implement every endpoint for every model" to "describe the attributes, relations, restrictions, update rules, etc of a model, and the actual endpoints will be procedurally generated. This means that:
- Developers will need to write much less code to add or modify models. It hopefully won't be necessary to implement endpoints or serializers directly.
- Every model will (almost) automatically get some features w.r.t. filtering, sorting, searching, etc.
- Coordinating includes + relationships + etc will become a lot simpler.
- If the model implementation is generic, we can often do some graph traversals and figure out which relations need to be eager-loaded without that being specified explicitly
So this will definitely break extensions (although we will likely retain some BC layers where possible), but the client-facing JSON:API should only get more correct, if it changes at all.
linc If there's some other format or considerations you'd like me to make, hit me up sometime in the next month or two
I haven't spent a lot of time digging into importer architecture, but I imagine that with a modular core and a well-designed "intermediate" representation of data when converting from one forum architecture to another, it shouldn't be too difficult to connect Flarum to your project. Likewise, if you have any architecture questions or concerns regarding Flarum, please don't hesitate to reach out!
