Django for Startup Founders

·

Статья рассказывает о выработанных подходах к написанию приложений с django и [[drf]], чтобы было удобно поддерживать SaaS приложение вместе с фронтендом на SPA.

TL;DR:

  • писать везде в одинаковом стиле, что подразумевает
    • соблюдение одинаковой логики во всех views
    • вынесение переиспользуемых сервисов
    • выработка правил по именованию файлов
  • не сильно упарываться с деклатаривным подходом в сериализаторах и generic views
  • покрывать это всё тестами
  • сделать это поддерживаемым с точки зрения апгрейдов

Rule #12: Write tests. Not too many. Mostly integration:

  • Permissions — Always test the permissions for each endpoint. For example, if a view should only allow authenticated users, the first test should be ensuring that the endpoint throws an error for unauthenticated users.
  • Validation errors — Have one test for each validation error. For example, if a username can’t be more than 15 characters, test that it returns the correct error message. Also test multiple validation errors at once to ensure that the error messages are aggregated correctly.
  • Business requirement errors — Have at least one test that triggers each business requirement error. For example, if an endpoint requires that a user’s account be at least two weeks old to submit content, have a test for that.
  • Success conditions — Have at least one test for each way you can call an endpoint and receive an HTTP 2xx or 3xx response.

Rule #10: There are exactly 4 types of errors:

  • Upstream errors: Errors that happen upstream of our user code, e.g. in the authentication package we’re using, or in our other middleware. The main thing to know about these errors is that you should leave them alone. Don’t try to rewrite errors from upstream middleware to make them look like the kind of errors we throw in our user code, because that will make it very difficult to update our external dependencies later.
  • Validation errors: Errors that occur when a user has permission to access an endpoint, but they supply syntactically invalid input. For example, if they enter a username longer than the maximum allowed length or don’t enter an email address.
  • Business requirement errors: Errors that occur when a user has permission to access an endpoint and they enter input in the correct format, but there are business requirements that prevent us from doing the thing they want. For example, if there is a business requirement to not allow users to access private information belonging to other users, or to not allow users to create multiple accounts using the same email address, then these would be business requirements errors. Return the first business requirement error that occurs, there is no need to check for or return multiple errors. The internal_error_code is a unique 5-digit number associated with each business logic error, whose first three digits are always the same as the HTTP status code. The idea is that developers looking at errors returned to the front end can use this unique number to quickly Command-Shift-F to find the exact line in the backend where the error is raised, which eliminates the time that would otherwise be wasted trying to figure out where in the backend an error is occurring.
  • 500 errors: Errors that happen when your application randomly bombs out due to a bug in the code. Just let these happen, don’t try to catch them and re-raise them as other types of error because it’s important to be able to find these errors when (and where) they’re happening in whatever APM software you’re using to monitor the health of your application.

Link:: https://alexkrupp.typepad.com/sensemaking/2021/06/django-for-startup-founders-a-better-software-architecture-for-saas-startups-and-consumer-apps.html