Application architecture 🏛

[chetbae]

vim/
  client/
    public/
    src/
  server (aka web-app)/ 
    django/

This is my general understanding of how our stack is structured as I work on setting up the front end. Not too familiar with how containerizing with docker will look - will read up on it.

@PythonSemicolon any thoughts on the client/ structure? naming or otherwise.

@zhannaklimanova if you see any problems with this slack me! I'm not entirely sure how frontend interacts with backend with docker. Is it any different with routing or cors by exposing an api/?

---

[PythonSemicolon]

looks good for the moment - I imagine most frontend code will be under src/, with sections for scripts, styles, etc. Naming seems fine for now - I feel like we'll know later whether changes are required (once we get going with concrete implementation).

[chetbae]

Upon further reading I've realized that django does it pretty differently from a separate client/server arch like a react-nodejs app. My gist of it is django has projects and apps, and urls.py handles routing to server-side render 'templates' which are .html files with inline python.

I came across this article which looks a good hybrid way to incorporate the pros of django and also client-side rendering.

The common practice seems to be setting up the django backend as a rest endpoint for the frontend to interact with. If no one has any convincing objections, I think this option would be preferable so we can use npm/webpack and keep front/back everything decoupled while developing.

[PythonSemicolon]

I imagine if we have Django purists that the rest endpoint wouldn't appeal as much to them, but it would also be my preference as I am more comfortable with that kind of architecture

[ahankinson]

would be preferable so we can use npm/webpack and keep front/back everything decoupled while developing.

You really need to be careful with the separate architecture. If you make this decision, you are effectively building two pieces of software, not one. You also need to really get your API design down before committing to this approach.

What are your URL patterns? What is the structure of your site? How will you handle routing of URLs in a REST-based architecture? How is routing handled on the front-end, vs. data retrieval on the back-end?

DIAMM uses a hybrid approach. The search and source pages are both complex enough that they are separate webapps. All other pages are built using the Django templating system. It uses the Django REST framework to provide a REST API for your application. Building the whole site as an SPA would have been too much work.

which are .html files with inline python.

Not quite -- they're the Django templating language, which is it's own thing.

[chetbae]

@ahankinson Thanks for the feedback! Took a look at the DIAMM repo which I'll definitely be using as a reference for any large django builds.

If you have any opinions to weigh in, do you think the hybrid approach will also be ideal for vim? I was hoping to use React for the front-end as well for the search pages but Ich would rather there be minimal dependencies (though we're already decided on the django framework...).

[ahankinson]

I was hoping to use React for the front-end as well for the search pages but Ich would rather there be minimal dependencies (though we're already decided on the django framework...).

You should decide on your site structure before you decide on the specific technologies to do it. What advantage does React bring to your project's goals?

While I can see some models in the top post, I don't yet see a list of URL endpoints and what data they will be expected to serve. I would start there.

When user visits URL x, what will they see? How will they interact with that page? Do you need a complex interactive search interface, or is a simple static page render good enough?

How will you handle routing? If you're doing URL routing in your client-side app, you need then special consideration of your server-side routes. Will your client fetch data from the same URL for both human and machine-readable data, or will you have separate URL endpoints for your JSON data vs. the URLs that your users will see.

(Also, a side note: Do Not use hash-based routing for your client-side applications! They make it really difficult for Google to index your site.)

[chetbae]

Great points thank you! I'm going to do more planning

[dchiller]

The common practice seems to be setting up the django backend as a rest endpoint for the frontend to interact with. If no one has any convincing objections, I think this option would be preferable so we can use npm/webpack and keep front/back everything decoupled while developing.

I think this makes sense! The article interestingly pulls the .html template files out of their specific django app directories, which I hadn't thought of but makes sense given the hybrid nature of the implementation.

[chetbae]

Noting this here, unless it belongs elsewhere.

Web pages for VIM:

• Landing Page: Greets users and gives context to the website, perhaps with a brief about section and other information.
• About: A more in-depth overview of the virtual instrument museum
• Search: Faceted search page that allows users to find instruments with a high control over a range of attributes (as defined in models). Intuition is for users trying to find a highly specific instrument.
• Browse: A gallery of instruments, with the option to narrow down via broader categories. Intuition is for users who would like to browse, may not have an instrument in mind, or has an idea but isn't entirely sure.
• Instrument Pages: For each instrument.
• Account: For each user created profile, where a user can interact with account settings for vim and their reward system.
• Contributors: Listing contributors and information concerning funding and participants.

# in order
/                     
/about
/search
/browse
/instrument/<id>
/account
/contributors

[ahankinson]

Looks good.

what types of responses are you expecting each endpoint to provide? HTML? JSON? Both? Will this have a machine-readable API? If so how does that work?

[dchiller]

From the meeting today, maybe we want /language/<language_id> where you can see the instruments that have names (or don't have names yet) in a certain language

[ahankinson]

Is <id> the ID of the instrument, or the ID of the language?

[dchiller]

Is <id> the ID of the instrument, or the ID of the language?

ID of the language...updated my comment above to disambiguate.