Hmm, maybe. I don’t see any obvious candidate right now. Candidates for docstore engines, yes, but not too nested.
I’d say either Postgres’ JSON data type, or Redis, or a combination of both.
It’s that I’m not convinced that “relational” is the right choice – see e.g. here – not that I know much else.
It’s very adequate for an MVP (as you referenced when you linked to this), but I fear it constrained the evolution of SE’s data, and might constrain yours similarly.
There’s potentially some areas where tree structures may come in handy, but they are unlikely to be particularly heavy use of the structure. Given that, we’ll be okay storing them in a relational database - RDBS aren’t brilliant at handling tree data, but can be made to work without too much hassle. I’ve had some experience managing that sort of thing, so I have some potential approaches we can use.
2 Likes
This is why isomorphism is a good idea (rendering by using the same code on both the server and client, so it can work in server only mode for search engines and legacy users). If we go with an SPA approach, it’s a good idea to have isomorphic rendering as a top priority.
2 Likes
I don’t quite get what you mean here. Any app can work in “server only mode” by relying on normal navigation and form submission, no? Am I missing something?
When you use isomorphic rendering, exactly the same code runs on the server, that runs in the browser. Usually you do this to render the first page load on the server, and then the client takes over from there, but for people who don’t have JS, they continue using server renders.
You said the following:
By using isomorphic rendering, you’re giving yourself a fallback, without doubling your work, because the same code runs on the server and the client.
2 Likes