Tech Stack Selection

[mjoynes-wombat-web]

This is to discuss possible tech stacks and their costs/benefits. Based on several previous discussions there are a couple of ideas that have floated around.

Rolling our own from scratch. Some preliminary work has been done on a MySQL and Elastic Search system. This would require a lot of bare metal work and makes us have to focus on additional domains like security.

Using something like Prisma to create and model the GraphQL and Rest API. This reduces a lot of the complexity around access, user authentication, and security. However, there is no interface to work with this so we would have to create that. It would need an Admin System to approve/manage submissions and a contributor system to submit edits/new definitions.

Another option would be to use a full fledged CMS like Craft CMS. Craft itself provides internationalization support. It has native GraphQL API. It also has user management. The security is regularly updated and managed by the Craft CMS team. It also has a built in concept of revisions and drafts. The entire system can be expanded to accommodate the contributor system and management of edits/new definitions. It could also be fairly easily expanded to allow for API gating and paid subscription to the API. The downside would be we have to work within their system and are somewhat limited by it.

I believe any of these three options would be usable with a search indexing service like Elastic Search.

This is by no means an exhaustive list of options. Whatever option we choose will need to accommodate the data structure outlined in this issue.

[mjoynes-wombat-web]

Questions to discuss. @tatianamac

Given the challenges associated with the different types of systems what level of effort vs flexibility would you like going forward?

Also a note. Brandon Kelly at Craft CMS is willing to provide us with a pro-license for free to support this project. I also work with Craft CMS very frequently so it is a system that I am confident will be adaptable to our needs.

[alex-page]

I wonder if moving to Next.js and creating an API from the markdown files would be a good first step. This would allow some quick iteration of data structures and for the API to be tested before creating a CMS.

[ovlb]

Hey, @alex-page. Thanks for getting into this. :)

We had the discussion re React/Next somewhen before, allow me to reiterate my standpoint.

I’m opposed to this. Nothing against Next, they are doing amazing work. But: I think it isn’t the right tool. For multiple reasons. It would require folx interested in helping out with the project to know React, which is a huge burden and – in my opinion at least – one that far outweighs the benefits.
From a more philosophical standpoint: Implementing Facebook’s recruitment tool in a community project feels antithetical.
I also don’t think that we have too much to gain by making this implementation, as we have selfdefined/web-app#213 open, which does the first «search from Markdown» step. Without us needing to rewrite the project. There will further be performance issues and so forth. So, currently, I think Next.js would be a solution to a problem we don’t yet have while opening up potential other problems.

However, though, that’s my current standpoint, I’m always open to hearing reasons why it might be the correct tool. :)

All the best,
Oscar