DOCSEARCHbyAlgolia
Submit Docs

Yellow Pebble Knowledge Base

website·Indexed 29 days ago

https://yellow-pebble-04891261e.4.azurestaticapps.net/

A practical collection of technical documentation, project guides, and snippets. Content covers Go API development (including Gin, Fiber, and Echo), Azure services such as Azure Container Apps, Azure Functions, and Azure SQL, as well as Microsoft Power Platform (Power Apps and Power Automate) and SharePoint Framework (SPFx).

Tokens
12.9K
Snippets
68
Records
120
Agent score
49%

What's inside Yellow Pebble

  1. Determine when to use Power Apps model-driven apps

    Power Apps model-driven apps are designed for data-centric, enterprise applications built on Microsoft Dataverse. They are the preferred choice when the application is process-driven rather than UI-driven, and requires strong structure, security, and scalability.

    Key use cases include:

    • Managing complex relational data (one-to-many or many-to-many relationships).
    • Implementing role-based security and row-level access control.
    • Ensuring strict data integrity and enforcing business rules.
    • Prioritizing rapid development over custom UI/UX design.

  2. Understand Symmetry vs Hierarchy learning styles in programming

    Learning styles can be categorized into Symmetry (Pattern Seekers) and Hierarchy (Systems Shakers), which influence how developers approach code, learn new languages, and solve problems.

    Symmetry Learners (Pattern Seekers)

    • Focus: Horizontal patterns, similarity, and mirroring.
    • Thinking Style: Intuitive and relational; they look for matching pairs and analogies.
    • Coding Behavior: Tend to write clean, predictable code with balanced naming conventions (e.g., Open/Close).
    • Strengths: Rapidly grasp new languages and frameworks by spotting patterns.
    • Weaknesses: May struggle with deep debugging or complex codebases by missing 'outside the box' details.

    Hierarchy Learners (Systems Shakers)

    • Focus: Vertical structures, contrast, scale, and power dynamics.
    • Thinking Style: Critical and structural; they focus on the context and the 'Why' behind a system.
    • Coding Behavior: Excel at architecture and security; they focus on system failure points and permission levels.
    • Strengths: Strong at debugging and understanding complex interactions within a codebase.
    • Weaknesses: May take longer to ramp up on new languages due to a tendency to get caught in the details.

  3. Determine when to use ASP.NET Core for project development

    ASP.NET Core is a high-performance, cross-platform framework for building web applications and APIs using C#. It is suitable for Windows, Linux, and macOS environments and is designed for cloud-native development, scalability, and security. It supports REST APIs, MVC apps, Razor Pages, and Blazor, with native integration for Azure, containers, and DevOps pipelines.

    Recommended Use Cases:

    • Backend APIs for web, mobile, and Power Apps solutions.
    • Enterprise web applications requiring strong security and role-based access control.
    • Microservices and cloud-native architectures.
    • High-performance systems managing large traffic or data volumes.
    • Systems requiring tight integration with the Microsoft ecosystem (Azure, SQL, Entra ID).

    Avoid ASP.NET Core if:

    • The project is a simple static website.
    • Rapid no-code/low-code development is required (Power Apps is a faster alternative).
    • The development team lacks .NET/C# expertise.

  4. Implement a Go API using the 'Inside-Out' development approach

    To ensure a clean architecture where dependencies are well-defined, follow the 'inside-out' development order. This approach ensures that the data definitions exist before the logic that uses them, and the logic exists before the interface that exposes it.

    Development Order:

    1. The Model (Lettuce): Define the data structures (blueprints) first.
    2. The Service (Meat): Implement core business logic and database interactions.
    3. The Handler (Waiter): Create the interface to translate service data into HTTP/JSON responses.
    4. The Main (Bread): Assemble all components and start the HTTP server.

  6. Build a Go API with Northwind Azure SQL Database

    This project involves building a Go-based API that interacts with a Northwind database hosted in Azure SQL Database, paired with a React frontend for data visualization. The architecture follows an 'inside-out' development pattern: Model $\rightarrow$ Service $\rightarrow$ Handler $\rightarrow$ Main.

  7. Organize Go package dependencies for API development

    To maintain a clean architecture in Go API development, ensure dependencies point inward toward lower-level packages and never sideways or upward. High-level packages should depend on lower-level ones. For example: the api package can depend on the store package, the store package can depend on the model package, and the model package should have no dependencies.

  8. Distinguish between runtime files and build metadata in Go API architecture

    When mapping the integration architecture between a frontend and a Go API, only files affecting runtime behavior should be included. Build metadata files like go.mod and go.sum are used for dependency management and versioning during the build process and do not influence the runtime interaction with the browser or API clients.

  9. Integrate Docusaurus with a Go API backend

    Docusaurus (built on React) can be integrated with a Go-based API to create a unified frontend and backend experience. The frontend uses the fetch() API to communicate with the Go backend, which manages application entry, HTTP routing, API endpoints, and browser access rules (CORS).
    User (Browser)
│
└── Docusaurus (React)
└── fetch() → Go API
├── main.go # App entry
├── routes.go # HTTP routes
├── handlers/ # API endpoints
└── middleware/
└── cors.go # Browser access rules

  10. Organize a Go API project using a layered architecture

    For a scalable Go API, use a folder structure that separates the entry point, business logic, and data access. The recommended flow is: HTTP Request → Gin Router → Handler (HTTP) → Service (Business Logic) → Repository (Data) → Domain Model.
    my-api/
├── cmd/
│   └── api/
│       └── main.go
├── internal/
│   ├── app/
│   │   ├── server.go
│   │   ├── router.go
│   │   └── middleware.go
│   ├── config/
│   │   └── config.go
│   ├── domain/
│   │   └── user.go
│   ├── service/
│   │   └── user_service.go
│   ├── repository/
│   │   └── user_repository.go
│   ├── handler/
│   │   ├── user_handler.go
│   │   └── health_handler.go
│   └── platform/
│       └── database/
│           └── postgres.go
├── go.mod
└── README.md

  11. Distinguish between Methods and Handlers in object-oriented design

    In software design, a Method represents a 'skill' or capability that an object possesses (the 'what'), whereas a Handler is a specific reaction that triggers a skill when a particular event occurs (the 'when'). A handler typically acts as the glue between an event system and the business logic contained within a method.