2.1.0

The back-end project now has a database. Every word that is consulted through the V2 endpoint of the transcribe action, its transcription is taken from the database using the CMU Pronouncing Dictionary. What is consulted is saved in the database as well for future use (like consulting which word is most sought so we can create some projects from it, like a robot that informs people through our social medias). By default, the dictionary only has entries for EN-US. As EN-GB is needed too, a routine was created to fill the database using the Transcriber Wrapper. It can be consulted in the create_dictionary.py file. A new endpoint was created to allow the front-end side to send suggestions from the user. The Django Admin (see admin.py) has some features that allow the administrator to apply a suggestion, and to see what was the most sought words given the current admin filter.

The front-end project was adapted to use the new endpoints as well as some updates in the UI. Most of the logic related to transcription, such as show stress, was implemented on the front-end project, so the user does not need to consult the back-end server again to see how is the transcription with or without stress marks.

2.0.0

Comparing to 1.0.0, the project changed completely in 2.0.0. The repository is a monorepo now. It includes the front-end project based on Gatsby and the back-end one based on Django, which acts here simply as an API server, still without a database.

Summarizing the front-end project:

• It uses Gatsby as the static site generator with Netlify CMS. The last one only for the blog section.
• The front-end was totally modified and, instead of MaterializeCSS, it is using Material-UI through react components.

Summarizing the back-end project:

• Django now only has APIs, no Django Template anymore. In url.py it has endpoints to transcribe words and to deal with GitHub OAuth flow because of Netlify CMS that is used on the front-end project.
• The transcribe endpoint can only be consumed if the reCAPTCHA asserts that the origin matches a certain criteria, otherwise it won't be allowed.

1.0.0

Here you'll find a stable and workable solution which runs as a Python back-end based on Django. It has the following technologies:

• All the assets is served by WhiteNoise with Django through Gunicorn (WSGI HTTP Server). As it is very basic, no CDN was used in production. If you look at the Pipfile and the settings.py, it's using Brotli compression format with cache support.
• Django acts here simply as the SSR, with Django Template. No database used.
• All the views can be consulted here and its URLs here. Basically, Rave of Phonetics has an index and changelog pages, as well as custom ones for errors 400, 404 and 500.
• In order to use some advanced JavaScript features on the browser, Parcel was used. See this package.json's line to understand how it was used during development and this one for the build process. A good catch is to look at the Dockerfile too.
• Parcel looks at an entry point to find all related files used in the project, then creates a bundled file containing all resources used (CSS, JS, among others). Ours can be consulted here.
• Apart from Django Template, the front-end on client-side uses MaterializeCSS and IndexedDB to persist what was transcribed by the user. See the files indexeddb-setup.js, TextConfigurationDao.js, TextHistory.js and TranscriptController.js.
• Tests are separated by unit and int folders. The support folder has some utilities to assist some tests either for Python and JavaScript.
• The scripts related to CI/CD are not available in this release. Everything is configured on Azure DevOps using Classic pipeline.