Flask python blueprint logic code separation

Question

I'm a bit confused about separation for my flask app. Users can login, post adverts and these are available to the public.

The URL structure would be something like this:

• User Home - www.domain.com/user
• User login - www.domain.com/user/login
• User advert List - www.domain.com/user/advert
• User advert add - www.domain.com/user/vacancy/add
• Public Advert - www.domain.com/advert/1

The issue comes from the fact that there is advert forms and logic which is required inside and outside of the user control panel. Which of these is the most correct way of laying out my application:

Option 1:

• User Blueprint (no url prefix) Contains all user related logic

• Advert Blueprint (no url prefix) Contains all advert related logic, including the user posting adverts and displaying them to the public

Option 2

• User Blueprint (/user/ prefix) Contains user logic and advert logic (adding adverts from the user control panel)

• Advert Blueprint (/advert/ prefix) Contains advert logic relating only to advert tasks outside of the user control panel.

Answer 1

I think Option 2 provides the most logical consistency. Although you're building a website, and not an API, I'd say there is still some relevance in this advice. Each endpoint is clearly defined where it's coming from, and you aren't left with the odd situation of mixing blueprints for different parts of the URL. This way, you always know exactly where to work if there is a problem.

You should have all of the complicated logic outside of your blueprints, and inside of libraries. I'd assume you're using a database somewhere to store everything, so you're going to need a library for that anyway. You should then have a form template that you can use for the form, wherever it happens to be served. If the complicated logic is in libraries and forms, there is little cost to duplicating functionality at each endpoint.

Source: Currently working on the redesign of a huge API, so I've been talking with lots of people about best practices recently.

Answer 2

am I right your logic should be in models and service classes? and blueprints (aka views) only a thin middleware between template and these modules?