design architecture

Using Django
1

Hello Guy,
I am building a website using django for my startup. Right now it has two use (landing page & blog), later I will have a product page and service page within the same website. I would like to know how do I design the website.
→ I am looking for easy maintains (new to django)
→ Standard practice ( future developer can work on it without redo)
→ Which can scale on cloud or hybrid setup.

Arch 1:
Build a main project and sub APP for each service(Blog, Product, Service and landing page).

Arch 2:
Build a main project and have a signal app with all the service.

Thank You in advance.

2

You’re likely going to get multiple different opinions here. I just have a couple thoughts to toss into the mix.

  • I’m a member of the “One app unless proven necessary otherwise” camp. Start small and see how things develop. It’s not really that hard to refactor code if it grows to the point that multiple apps would really show a benefit. It’s more difficult to “collapse” apps into one.

  • Make yourself familiar with Python PEP 8 and the Django code style conventions. (Note: This does not necessarily mean that I think you should dogmatically adhere to every element of both documents. However, all other things being equal, you will find your code more consistent, and therefore understandable, if you follow generally-accepted practices.

  • Scalability is a bit of a nebulous term. Django can be scaled - and usually without significant changes to the application itself. (Settings, yes. But not the core code - unless its poorly designed to begin with.)

  • Be aware of what appears to me to be about the biggest “gotcha” - the “N+1 query” issue that can crop up on “listing-style” pages.

  • Strong Opinion: Work on a strict segregation of duties between the views and the templates. (By “views” in this case, I’m referring to all code that executes outside the context of a template being rendered, which may include utility functions outside the strict scope of the view class or function.)

    • A view exists to determine what data should be available to be displayed
    • A template exists to determine how that data is to be displayed.
      • A template can choose to not display fields from models
      • A template may not exclude rows from models. Such filters belong in the view.
      • A template may not add data from models. If a template is going to refer to related models, those models should be selected in the view (even if it’s just through using a select_related clause).

This last principle comes from a long history of trying to work with systems not making this distinction. With this principle in place, you can find all data being displayed from the view. Otherwise, you end up needing to look in multiple places to determine the source(s) of data appearing on a page.

2 Likes
3

Thank you sir, for the advice. I will have a look at PEP8 to have a generally-accepted practices. I will start with a single app that has both my landing page as wells my blogging site.

Thank you for the reply. :slight_smile: