View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005836 | Composr | core | public | 2024-08-03 22:19 | 2024-08-04 20:08 |
| Reporter | Chris Graham | Assigned To | |||
| Severity | Feature-request | ||||
| Status | non-assigned | Resolution | open | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0005836: API-first development | ||||
| Description | Move Composr to generate data via an API server, and render the HTML from a JavaScript platform. This would radically change the Composr programming model and radically improve speeds, while opening up the ability for there to be multiple 'clients' for a Composr site (including mobile apps, etc). The JavaScript API would be able to render Tempcode and locally cache resources like templates, which would be served through the API server. There'd be much less data transferred by request and most of the load would be moved from the server to the client, greatly improving throughput. Something like Swoole or ReactPHP (see 0005835) would be good to add even higher performance to the API server. This would all be an enormous amount of effort, almost a rewrite of the system. But to provide extreme performance and responsiveness, I think it's the future. | ||||
| Tags | Type: Performance | ||||
| Time estimation (hours) | 10000 | ||||
| Sponsorship open | |||||
| related to | 0005835 | non-assigned | Parallel block generation using Fibers (holding issue) | |
| related to | 0005834 | non-assigned | Switch to Typescript (Deno) | |
| related to | 0002091 | non-assigned | JavaScript-heavy forum implementation | |
| related to | 0002092 | closed | Chris Graham | JavaScript-heavy galleries implementation |
|
|
If doing this it would probably also make sense to have some kind of precaching of resources commonly-used on the front end. This could be learned automatically, i.e. resources used by over X% of users should be auto-cached in the background. Templates, images, etc. Probably based on available bandwidth, i.e. don't do over a cellular connection. |
|
|
I should put in a reference to GraphQL, which is now very popular for APIs. I think we should focus on simple JSON though. If someone then wanted to make that more performant with GraphQL that could be added on in parallel. GraphQL has a lot of complexity and presents caching challenges, so it's not something we should go for unless we identified a need for it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-08-03 22:19 | Chris Graham | New Issue | |
| 2024-08-03 22:20 | Chris Graham | Relationship added | related to 0005835 |
| 2024-08-03 22:20 | Chris Graham | Tag Attached: Type: Performance | |
| 2024-08-03 22:20 | Chris Graham | Relationship added | related to 0005834 |
| 2024-08-03 22:21 | Chris Graham | Relationship added | related to 0002091 |
| 2024-08-03 22:21 | Chris Graham | Relationship added | related to 0002092 |
| 2024-08-04 15:50 | Chris Graham | Note Added: 0009070 | |
| 2024-08-04 20:08 | Chris Graham | Note Added: 0009074 |
