Update plugins documentation

docs/plugins/development/graphql-api.md

@@ -9,10 +9,11 @@ A plugin can extend NetBox's GraphQL API by registering its own schema class. By
 ```python
 # graphql.py
 import graphene
+from netbox.graphql.types import NetBoxObjectType
 from netbox.graphql.fields import ObjectField, ObjectListField
 from . import filtersets, models
 
-class MyModelType(graphene.ObjectType):
+class MyModelType(NetBoxObjectType):
 
     class Meta:
         model = models.MyModel

docs/plugins/development/index.md

@@ -29,14 +29,20 @@ Although the specific structure of a plugin is largely left to the discretion of
 project-name/
   - plugin_name/
     - api/
+      - __init__.py
       - serializers.py
       - urls.py
       - views.py
+    - migrations/
+      - __init__.py
+      - 0001_initial.py
+      - ...
     - templates/
       - plugin_name/
         - *.html
     - __init__.py
     - filtersets.py
+    - graphql.py
     - models.py
     - middleware.py
     - navigation.py

docs/plugins/development/rest-api.md

@@ -4,6 +4,21 @@ Plugins can declare custom endpoints on NetBox's REST API to retrieve or manipul
 
 Generally speaking, there aren't many NetBox-specific components to implementing REST API functionality in a plugin. NetBox employs the [Django REST Framework](https://www.django-rest-framework.org/) (DRF) for its REST API, and plugin authors will find that they can largely replicate the same patterns found in NetBox's implementation. Some brief examples are included here for reference.
 
+## Code Layout
+
+The recommended approach is to separate API serializers, views, and URLs into separate modules under the `api/` directory to keep things tidy, particularly for larger projects. The file at `api/__init__.py` can import the relevant components from each submodule to allow import all API components directly from elsewhere. However, this is merely a convention and not strictly required.
+
+```no-highlight
+project-name/
+  - plugin_name/
+    - api/
+      - __init__.py
+      - serializers.py
+      - urls.py
+      - views.py
+    ...
+```
+
 ## Serializers
 
 Serializers are responsible for converting Python objects to JSON data suitable for conveying to consumers, and vice versa. NetBox provides the `NetBoxModelSerializer` class for use by plugins to handle the assignment of tags and custom field data. (These features can also be included ad hoc via the `CustomFieldModelSerializer` and `TaggableModelSerializer` classes.)

docs/plugins/development/templates.md

@@ -2,6 +2,10 @@
 
 Templates are used to render HTML content generated from a set of context data. NetBox provides a set of built-in templates suitable for use in plugin views. Plugin authors can extend these templates to minimize the work needed to create custom templates while ensuring that the content they produce matches NetBox's layout and style. These templates are all written in the [Django Template Language (DTL)](https://docs.djangoproject.com/en/stable/ref/templates/language/).
 
+## Template File Structure
+
+Plugin templates should live in the `templates/<plugin-name>/` path within the plugin root. For example if your plugin's name is `my_plugin` and you create a template named `foo.html`, it should be saved to `templates/my_plugin/foo.html`. (You can of course use subdirectories below this point as well.) This ensures that Django's template engine can locate the template for rendering.
+
 ## Standard Blocks
 
 The following template blocks are available on all templates.