DEV Community: hayata-yamamoto

Lightning-Fast, Minimal AI/API Serverless Deployment: The Essence and Practice of Mastra Lambda Docker Deploy

hayata-yamamoto — Mon, 30 Jun 2025 09:00:00 +0000

1. Introduction

The need to “take machine learning and AI to production” or to rapidly prototype and roll out new API services is growing stronger, not just in startups but also across established enterprises. However, many developers and teams have hit walls—operational, architectural, and even psychological—when trying to move from proofs of concept to robust, production-ready serverless deployments.

This article unpacks the “Mastra Lambda Docker Deploy” open source repository, letting you instantly ship HTTP APIs or AI services on AWS Lambda using Docker—with minimal cloud know-how, friction, or overhead. Whether you’re cloud-savvy or just starting out, we’ll walk step-by-step from the logic to the hands-on, so you can master serverless AI and API deployment with confidence.

2. Why Do We Need Mastra Lambda Docker Deploy Now?

Problem Statement

AI-driven APIs and apps demand more than just servers—they need automation, cost efficiency, and seamless integration.
Proof-of-concept (PoC) is often lightning fast, but “production deployment” regularly hits a wall, dragging on for days or weeks.
Lambda and other FaaS (Functions as a Service) are attractive, but their quirks and operational puzzles often discourage production adoption.

Real-World Pain Points

Endless scripting and environment-specific hacks for every deployment lead to wasted developer hours and technical debt.
Mixing core app logic and environment glue code hinders maintainability and slows future scaling.
Many successful PoCs die before production because “real deployment” looks like a mountain to climb.

Why Does This Matter?

Speed and agility determine team and company competitiveness.
For R&D and new business, the ability to move from a “good idea” to a live service is a core driver of learning, innovation, and business wins.
“You built it—you should be able to deploy and scale it, too.” A high-leverage infrastructure standard is urgently needed.

3. The Hidden Pitfalls of Conventional Serverless & AI Deployments

Typical Existing Patterns

Lambda Native Runtimes (Node.js/Python): Deployment is simple, but you’re boxed in by runtime/library/version limitations and native dependencies.
Serverless Frameworks, SAM: Powerful but potentially overwhelming, especially with YML files, complex settings, and operational overhead.
Lambda Layers: Extend runtimes flexibly, but managing API Gateway, IAM, and layers can be arcane and difficult to automate.
Standard Docker Lambda: Flexible, but requires significant effort to “make it Lambda-ready” and can still miss vital optimizations.

Comparison Table

Approach	Flexibility	Ops Cost	Learning Curve	App Code Changes?	Serverless Optimization
Lambda Native Runtime	△	○	○	Extensive	△
Serverless Framework	◎	△	△	Moderate	△
Docker Lambda (Standard)	◎	△	△	Moderate	△
Mastra Lambda Docker Deploy	◎	○	○	Minimal	◎

The Real Limitations

Most methods require you to refactor your core app for “serverless compatibility”—API routing, handlers, and execution semantics.
Infrastructure settings (API Gateway rules, timeouts, IAM roles) become a manual, tribal process—hard to reproduce, risky to maintain.
Managing secrets (API keys), third-party integrations (OpenAI, weather APIs), and runtime environments safely is cumbersome.
Even in the “Kubernetes era,” you still end up missing DevOps/SRE leverage for Lambda and similar platforms.

4. How Mastra Lambda Docker Deploy Solves It

What’s “New” Here

Write your app as a standard HTTP server (Node.js Express, Python FastAPI... anything HTTP).
Add a single line with “Lambda Web Adapter” in your Dockerfile—now your code is instantly serverless, with no app changes.
Configure everything via .env, including OpenAI keys and database URLs, making credentials management simple and secure.
Multi-stage Docker builds create small, production-grade images with zero root privileges.
All Lambda operational quirks—security, ports, execution roles—are handled for you.

The Lambda Web Adapter (How It Works)

In your Dockerfile:

  COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.9.0 /lambda-adapter /opt/extensions/lambda-adapter

With this, every Lambda event/API Gateway request is automatically converted into HTTP and proxied to your app.
Your application runs identically both locally and on Lambda. “Lift and shift” without headaches.

Maximum Freedom—Any Tech Stack

Not just Node.js/TypeScript: Python, Go, Rust… any language/framework that can act as an HTTP server can run on Lambda.
Out-of-the-box OpenAI and weather API integration, with patterns you can adapt for other AI workloads.

5. Step-by-Step Onboarding and Sample Code

Requirements

Node.js (v18+ recommended)
Docker
AWS account (ECR and Lambda permissions required)
OpenAI API Key
(Optional) libSQL, Pino logger, etc.

Getting Started

1. Clone the Repository

git clone https://github.com/tied-inc/mastra-lambda-docker-deploy.git
cd mastra-lambda-docker-deploy

2. Create your `.env` file

OPENAI_API_KEY=sk-xxxx...
DATABASE_URL=file:./mastra.db
NODE_ENV=production
PORT=8080

3. Build the Docker Image

docker build -t mastra-lambda:latest .

4. Run Locally (for dev/debug)

docker run --rm -p 8080:8080 --env-file .env mastra-lambda:latest
# Your API will be available at http://localhost:8080

5. Deploy to AWS Lambda

Push your image to ECR (AWS Elastic Container Registry).
Create a new Lambda function with a “Container Image.”
Adjust environment variables, memory, and timeouts as needed.
The Lambda Web Adapter will handle all event translation and setup for you. You get built-in API Gateway routing.

Tip: Test thoroughly with AWS free tier or a local staging environment before going live.

6. Technical Features and Best Practices

Architecture

HTTP Server (Mastra): Listens on port 8080 for requests.
Lambda Adapter: Bridges AWS Lambda events to HTTP automatically.
Database: libSQL by default (lightweight, portable), or your own DB (Postgres, etc.)
Logging: Pino (or other JSON loggers) for rich, structured output.
Security: Runs as a non-root user in Docker; minimal required Lambda execution role.

Key Usage Tips

Use environment variables, not hardcoded values, to manage secrets and configuration.
Tune Lambda timeouts and concurrency for both rapid prototyping and robust production.
Local Docker brings parity to production—what you test is what runs!

FAQ & Common Stumbling Blocks

Q: I don’t know Lambda Layers or API Gateway—can I still use this? A: Yes. The adapter is plug-and-play. Just mirror the provided Dockerfile and configs.
Q: Can I extend with custom API routes or non-HTTP workloads? A: Anything that can talk HTTP can be deployed. Extend agents and workflows at will.
Q: What about security and operations? A: No root processes. Manage OpenAI keys and DB URLs via .env or AWS Secrets Manager.

7. Use Cases—Who Benefits Most?

Small teams and startups needing to turn prototypes into production APIs rapidly.
ML/AI practitioners deploying chatbots, NLP, or other AI endpoints without DevOps bottlenecks.
Serverless-first projects targeting cost efficiency, resilience, and easy scaling from day one.

8. Known Limitations

You still inherit Lambda platform limits (15-minute execution, memory caps, etc.)
“Stateful” APIs require extra care: Use external DB/session storage if you need persistence.
Additional configuration may be needed if you have heavy native dependencies (e.g., custom C++ libraries).

9. What’s Next & Community Involvement

More “minimal stack” recipes—Python, Go, and others to follow.
Cross-cloud compatibility (e.g., Cloud Run, Vercel) experiments in the pipeline.
Community is encouraged to share advanced workflows, new agent/tool integrations, and report back with success stories.

10. Summary & Call to Action

If this resonates, Star the repo, open an Issue, or submit your improvements!
Share your deployment tips, questions, and “war stories” via GitHub or on social media.
Let’s grow the serverless AI/API deployment ecosystem together—your contribution can help thousands deploy smarter and faster.

OSS shines brightest when everyone both uses and advances it. With a single line of code, you can help spark new ideas and workflows for developers around the world. Join the movement!

Escape from Lambda Function Name Hardcoding Hell: Type-Safe Serverless Development with sls_enum

hayata-yamamoto — Mon, 23 Jun 2025 03:00:00 +0000

1. Introduction

As serverless architecture adoption rapidly grows, microservice configurations centered around AWS Lambda have become standard for many companies. However, as the number of Lambda functions grows to 10, 20, or more, an often-overlooked challenge emerges: Lambda function name management.

You might think "it's just function names." However, this small issue compounds to create dozens of wasted work hours annually and risks of unexpected production failures.

This article introduces the challenges of Lambda function name management in projects using the Serverless Framework and an open-source tool called "sls_enum" that solves them. By implementing this tool, you can achieve a type-safe development environment and significantly improve your team's productivity.

2. The Problem: Hidden Costs of Lambda Function Name Management

2.1 Specific Challenges

When invoking Lambda functions from other functions, many developers hardcode function names as strings:

import boto3

lambda_client = boto3.client('lambda')

# Hardcoded function name
response = lambda_client.invoke(
    FunctionName='my-service-dev-processOrder',  # This string is the source of problems
    InvocationType='Event',
    Payload=json.dumps(payload)
)

This seemingly simple code harbors the following issues:

Runtime errors from typos: Writing procesOrder instead of processOrder won't be caught during deployment
Missed references during refactoring: When changing function names, all reference points must be manually updated
Complex stage management: Frequent mistakes when managing different function names across dev/staging/prod

2.2 Actual Losses

Let's calculate the actual losses from these challenges using a 50-person development team as an example:

Debugging time: Average 2 hours per developer per month investigating Lambda function name typo errors
Annual time loss: 2 hours × 12 months × 50 people = 1,200 hours
Monetary loss: Approximately $60,000 annually at $50/hour

More serious are production incidents. Failures due to function name mistakes create secondary losses:

Loss of customer trust
Engineer on-call responses during nights and weekends
Post-incident meetings and documentation

3. Existing Solutions and Their Limitations

3.1 Current Approaches

Development teams have tried various methods to address this challenge:

Constants file management

# constants.py
LAMBDA_FUNCTIONS = {
    'PROCESS_ORDER': 'my-service-dev-processOrder',
    'SEND_EMAIL': 'my-service-dev-sendEmail',
    # ... manually added
}

Environment variables

import os
function_name = os.environ.get('PROCESS_ORDER_FUNCTION_NAME')

Document-based management
Managing function name lists on Confluence or Notion, with developers referencing them as needed.

3.2 Comparison Table

Method	Advantages	Disadvantages	Maintenance Cost	Error Rate
Hardcoding	Simple implementation	Frequent typos, difficult search	High	15-20%
Constants file	Centralized management	Manual updates needed, sync issues	Medium	5-10%
Environment variables	Configurable at deploy	Configuration omissions, complex management	Medium	8-12%
sls_enum	Auto-generated, type-safe	Initial setup required	Low	0%

The common problem with these existing methods is "manual management." As long as humans must ensure synchronization between serverless.yml and code, mistakes are inevitable.

4. The Solution: sls_enum

4.1 Tool Overview

sls_enum is a CLI tool that parses serverless.yml files and automatically generates defined Lambda function names as Python Enum classes. This provides the following benefits:

Automatic synchronization: Enums automatically update whenever serverless.yml is updated
Type safety: IDE autocomplete and type checker support
Stage support: Automatic switching between dev/staging/prod environments

4.2 Installation and Setup

Installation is very simple:

# Install
pip install sls-enum

# Basic usage
sls-enum generate serverless.yml --output lambda_functions.py

# Generate with stage specification
sls-enum generate serverless.yml --output lambda_functions.py --stage prod

# Auto-generate with watch mode
sls-enum watch serverless.yml --output lambda_functions.py

4.3 Generated Code Example and Usage

serverless.yml content:

service: my-service

functions:
  processOrder:
    handler: handlers.process_order
    events:
      - http:
          path: /orders
          method: post

  sendEmail:
    handler: handlers.send_email
    events:
      - sqs:
          arn: ${self:custom.emailQueueArn}

  generateReport:
    handler: handlers.generate_report
    events:
      - schedule: rate(1 day)

Generated Enum class:

# lambda_functions.py (auto-generated)
from enum import Enum

class LambdaFunctions(Enum):
    """Auto-generated Lambda function names from serverless.yml"""

    PROCESS_ORDER = "my-service-dev-processOrder"
    SEND_EMAIL = "my-service-dev-sendEmail"
    GENERATE_REPORT = "my-service-dev-generateReport"

    @property
    def arn(self) -> str:
        """Get the full ARN for this Lambda function"""
        import os
        region = os.environ.get('AWS_REGION', 'us-east-1')
        account_id = os.environ.get('AWS_ACCOUNT_ID')
        return f"arn:aws:lambda:{region}:{account_id}:function:{self.value}"

Actual usage example:

import boto3
import json
from lambda_functions import LambdaFunctions

lambda_client = boto3.client('lambda')

# Type-safe function invocation
response = lambda_client.invoke(
    FunctionName=LambdaFunctions.PROCESS_ORDER.value,  # IDE provides autocomplete
    InvocationType='Event',
    Payload=json.dumps({
        'orderId': '12345',
        'items': ['item1', 'item2']
    })
)

# Handling multiple functions
for func in [LambdaFunctions.PROCESS_ORDER, LambdaFunctions.SEND_EMAIL]:
    print(f"Warming up: {func.value}")
    lambda_client.invoke(
        FunctionName=func.value,
        InvocationType='Event',
        Payload=json.dumps({'warmup': True})
    )

5. Business Impact

5.1 Quantitative Benefits (Estimates and Simulations)

Estimated effects based on simulations for a 50-person development team:

Debugging Time Reduction (Estimate)

Assumption: Average 2 hours per person per month spent investigating Lambda function name errors
After implementation: Zero time as errors are caught at compile time
Estimated reduction: 1,200 hours annually for the entire team

Cost Reduction from Incident Prevention (Simulation)

Assumption: 1-2 production incidents per quarter caused by function name issues
Response cost per incident: 5 engineers × 4 hours × $50/hour = $1,000
Opportunity loss: Estimated $5,000 per incident
Estimated reduction: $24,000-48,000 annually

CI/CD Efficiency (Estimate)

Simulation conditions:
- Deploy failure rate reduced from 15% to 2%
- 20 deploys per day, 30 minutes lost per failure
Estimated reduction: Approximately 390 hours of pipeline execution time annually

ROI Simulation

Initial Implementation Cost:
- Setup: 8 hours
- Team training: 20 hours
- Migration work: 40 hours
Total: 68 hours ($3,400 equivalent)

Annual Savings (Estimated):
- Debugging time: 1,200 hours ($60,000 equivalent)
- Incident response: $36,000 equivalent
- CI/CD efficiency: 390 hours ($19,500 equivalent)
Total: $115,500 equivalent

Estimated ROI: Approximately 34x (first year)

5.2 Qualitative Benefits

Important benefits that are difficult to quantify:

Improved Developer Experience

No need to memorize function names with IDE autocomplete
Freedom from typo anxiety allows focus on logic implementation
Eliminates function name verification during code reviews

New Member Onboarding

Easy understanding of existing Lambda functions
Reduced time searching for documentation
Correct function names used from the start

Enhanced Team Collaboration

Eliminates mistakes when calling other teams' Lambda functions
Natural standardization of function naming conventions

6. Implementation Guide

6.1 Teams Suited for Implementation

Teams that will see particularly high benefits from sls_enum:

Managing 10 or more Lambda functions
Operating multi-stage environments (dev/staging/prod)
Developing backends with Python/TypeScript
Heavy microservice interconnections
Established CI/CD pipelines

6.2 Step-by-Step Implementation

Step 1: Visualize Current Challenges

# Search for hardcoded function names in current codebase
grep -r "FunctionName.*=.*['\"].*-.*-.*['\"]" --include="*.py" .

Step 2: Pilot Project Validation

# Trial implementation in a small service
cd pilot-service
pip install sls-enum
sls-enum generate serverless.yml --output src/lambda_functions.py

# Gradually replace existing code
# Before: FunctionName='my-service-dev-processOrder'
# After: FunctionName=LambdaFunctions.PROCESS_ORDER.value

Step 3: CI/CD Pipeline Integration

# .github/workflows/deploy.yml
steps:
  - name: Generate Lambda Enums
    run: |
      pip install sls-enum
      sls-enum generate serverless.yml --output src/lambda_functions.py --stage ${{ env.STAGE }}

  - name: Type Check
    run: |
      mypy src/

Step 4: Team-wide Rollout

# Pre-commit hook setup
cat > .pre-commit-config.yaml << EOF
repos:
  - repo: local
    hooks:
      - id: generate-lambda-enums
        name: Generate Lambda Enums
        entry: sls-enum generate serverless.yml --output src/lambda_functions.py
        language: system
        files: serverless\.yml$
EOF

6.3 Best Practices

Automatic Generation with Pre-commit Hooks

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: generate-lambda-enums
        name: Generate Lambda Enums
        entry: sls-enum generate serverless.yml --output src/lambda_functions.py
        language: system
        files: serverless\.yml$

Stage-specific Management

# For development environment
sls-enum generate serverless.yml --output lambda_functions_dev.py --stage dev

# For production environment
sls-enum generate serverless.yml --output lambda_functions_prod.py --stage prod

# Use appropriate Enum based on environment
import os
if os.environ.get('STAGE') == 'prod':
    from lambda_functions_prod import LambdaFunctions
else:
    from lambda_functions_dev import LambdaFunctions

Migration Strategy from Existing Code

Gradual Replacement
- Start using sls_enum for new code
- Replace existing code during feature updates
Leverage Search and Replace

   # Identify pre-migration code
   # grep -r "FunctionName.*=.*['\"]" --include="*.py" .

   # After migration
   # FunctionName=LambdaFunctions.PROCESS_ORDER.value

Add Tests

   # Test that function names are correctly generated
   def test_lambda_function_names():
       from lambda_functions import LambdaFunctions
       assert LambdaFunctions.PROCESS_ORDER.value.endswith('processOrder')

Team Operation Rules

Always regenerate enums after changing serverless.yml
Integrate automatic generation in CI/CD pipeline
Include generated files in version control (share across teams)

7. Conclusion and Call to Action

sls_enum solves the seemingly minor challenge of "Lambda function name management" to create significant business value. Annual savings of 1,200 development hours, zero incidents achieved, and most importantly, an environment where developers can focus on core logic. These are crucial elements for differentiation in competitive markets.

Actions You Can Take Now

Current State Analysis: Investigate how many Lambda function name-related errors occur in your team
Trial Implementation: Try sls_enum in a small project and experience the benefits
Feedback: Share improvement suggestions through Issues and Pull Requests on GitHub

# Get started now
pip install sls-enum
sls-enum generate serverless.yml --output lambda_functions.py

Contributing to the Open Source Community

sls_enum is an open source project. Your experience and insights can help solve challenges for developers worldwide. Please star the project on GitHub and share your improvement suggestions and new feature ideas.

Small improvements compound into major innovations. Start with the seemingly mundane challenge of Lambda function name management and elevate your team's productivity to the next level.

Evolving a Markdown Converter with AI and OSS: A Development Story that Revolutionizes Technical Content Publishing

hayata-yamamoto — Fri, 20 Jun 2025 00:37:10 +0000

Introduction: Discovering a Brilliant Tool

One day in 2024, I was searching for the ideal Markdown-to-Medium conversion tool. As someone who regularly writes technical articles, I was looking for an efficient way to optimize my Markdown content for various platforms.

Then I discovered a wonderful OSS tool on GitHub. The functionality was perfect, the UI was polished, and it clearly showcased the author's technical skills and design sense. Seeing the potential of this tool, I felt inspired: "I want to build upon this foundation and evolve it further with modern technology stack."

Opportunities in Modern Technical Content Publishing

1. The Multi-Platform Era

Today, technical content publishing platforms have diversified, each fostering wonderful reader communities:

Medium (global engineering community)
Substack (readers seeking deep insights)
Dev.to (active developer community)
Zenn (Japanese tech community)
Company blogs (branding and SEO)

This diversity presents fantastic opportunities, but also creates a need for efficient distribution methods.

2. Leveraging Markdown as a Universal Language

For engineers, Markdown is a powerful productivity tool. It's simple, version-control friendly, and editable in any editor:

## Structured Documents
- Clear hierarchy
- **Important emphasis**
- [Reference links](https://example.com)

Our goal was to maximize the potential of this excellent notation across all platforms.

3. Continuous Evolution of the OSS Community

GitHub hosts many excellent Markdown conversion tools. Each was implemented with cutting-edge technology of its time and has helped countless developers. We believed we could create additional value by combining new technologies with these pioneering achievements.

The OSS Evolution Project: Merging Wisdom of Predecessors with AI

Inheriting Excellent Design Philosophy

The tool I discovered had outstanding features:

Intuitive real-time preview
Thoughtfully crafted HTML output for Medium
UI design prioritizing usability

"Let's inherit this excellent design philosophy while creating something even better with the latest technology."

This was our project's starting point.

Efficient Technology Updates with AI

In 2024 development, AI tools like Cursor and Claude became powerful partners. With these tools, we completed the technology stack update in just 4 hours:

Technology Stack Evolution

JavaScript to TypeScript (improved type safety)
Support for latest React 19 (performance improvements)
Fast development environment with Vite (improved DX)
Automated deployment with GitHub Actions (continuous improvement)

// Type definitions created in collaboration with AI
export interface MarkdownConverterProps {
  source: string;
  onConvert: (html: string) => void;
  platform?: 'medium' | 'substack';
  theme?: 'light' | 'dark';
}

AI wasn't just a code generation tool; it suggested best practices and helped design with future extensibility in mind.

The Evolved Markdown-to-Medium

Core Features: Balancing Simplicity and Power

Real-time Preview
- See actual rendering while writing Markdown
- Faithful reproduction of each platform's display characteristics
One-Click Conversion
- Instantly generate optimized HTML
- Automatic clipboard copy
Multi-Platform Support
- Medium (optimized)
- Substack (newly supported)
- Continuous expansion planned

Usage: Simple 3 Steps

Step 1: Access

https://m2m.tied-inc.com/

No registration required, free, instant access.

Step 2: Write in Markdown
Create articles using familiar Markdown syntax. Paste existing drafts too.

Step 3: Convert and Publish
After checking the preview, click "Copy HTML". Platform-optimized HTML is generated.

Measured Impact

Actual improvements in our team:

Before Implementation

Article writing: 30 minutes
Platform-specific adjustments: 20 minutes
Review and fixes: 10 minutes
Total: 60 minutes/article

After Implementation

Article writing: 30 minutes
Conversion and posting: 3 minutes
Total: 33 minutes/article

45% time reduction allows us to dedicate more time to improving content quality.

OSS Development in the AI Era: Collaborative Evolution

Balancing Heritage and Innovation

What we learned through this project:

Excellent OSS design philosophy holds value across generations
AI tools enable rapid modernization while leveraging existing assets
Better tools emerge by gathering community wisdom

Open Development Process

Currently, this tool is actively evolving:

Substack support (implemented from community request)
Accessibility improvements (dark mode added)
Internationalization (multi-language UI)

All features are born from dialogue with users.

Let's Build Together

Start Using Today

For Individual Writers

Start instantly at https://m2m.tied-inc.com/
Write efficiently with familiar Markdown
Easy distribution to multiple platforms

For DevRel Teams and Technical PR

Significantly improve team-wide writing efficiency
Quality control with consistent formatting
Create an environment where engineers can focus on writing

Evolve Together

This tool is published as OSS, and we welcome your participation:

Feedback Examples

"Dev.to optimization would be great"
"Want to improve code block syntax highlighting"
"Writing template features would be convenient"

How to Participate

Create issues on GitHub
Share improvements and ideas
Pull requests are very welcome

The Potential of Technical Communities

In the AI era, OSS development has become more collaborative and efficient:

Building upon existing excellent projects
Accelerating development with AI tools
Determining direction through community collective intelligence

Conclusion: Building the Future Together

To All Writers

Publish articles to any platform efficiently with Markdown. Make technical knowledge sharing easier.
To All Developers

The combination of AI and OSS shows that individuals can create significant impact. Let's build useful tools together.
To the Community

Please share your impressions, improvements, and new feature ideas. Your voice guides the tool's evolution.

Writing and sharing technical articles is a wonderful activity that spreads knowledge and enriches communities. We hope this tool helps support that activity.

Try it now → https://m2m.tied-inc.com/

Develop together → https://github.com/tied-inc/Markdown-to-Medium

This article was also efficiently created with Markdown-to-Medium. 30 minutes writing, 3 minutes converting.

Accelerating R&D with Instant Data Labeling Infrastructure - Label Studio on AWS AppRunner Terraform Module

hayata-yamamoto — Thu, 19 Jun 2025 01:44:18 +0000

Introduction: Nothing Starts Without Data

"We want to build an excellent machine learning model."

Everyone involved in R&D projects thinks this way. But what's the reality? Weeks after project kickoff, you're still stuck on infrastructure setup. Machine learning engineers are wrestling with the AWS console. Have you witnessed such scenes before?

At Tied, inc., through supporting numerous R&D projects, we've encountered a common challenge. It's the "data labeling environment setup" - a seemingly minor but actually critical bottleneck.

This article introduces the Terraform module "terraform-aws-label-studio-on-apprunner" we developed to solve this challenge, along with its background and value.

Why Data Labeling Infrastructure Matters

The Success Formula for Machine Learning

What factors determine the success of machine learning projects? The latest algorithms? High-performance GPUs? While these are important, the most fundamental factor is "high-quality data."

And to produce high-quality data, an efficient labeling environment is essential. Label Studio is widely recognized as a powerful open-source tool for this purpose. It supports all data formats - images, text, audio - and enables team collaboration.

The Reality of Time to Market

R&D projects are a race against time. Delivering value to market faster than competitors determines business success. However, many projects experience the following timeline:

Week 1-2: Infrastructure design and setup
Week 3: Label Studio finally starts running
Week 4: Data labeling finally begins

In other words, it takes a full month before actual value creation begins.

Three Challenges R&D Teams Face

1. Skill Set Mismatch

The primary role of machine learning engineers is to analyze data, build models, and create business value. In reality, however, they spend time configuring VPCs and setting up security groups.

This isn't just wasted time. The opportunity cost of having expensive specialists work on tasks outside their expertise is immeasurable.

2. Barriers at Project Launch

"We can't start anything without data first."

This is the fate of R&D projects. But what if it takes weeks to set up the environment for creating that data? The initial project momentum is lost, and team motivation declines.

3. Scaling Complexity

When a small-scale project succeeds, scaling up becomes the next challenge. You want to increase annotators from 10 to 100. You want to run multiple projects in parallel. However, with traditional methods, environment replication and management are complex, often ending without successful scaling.

Realistic Comparison of Label Studio Deployment Methods

What options exist for deploying Label Studio? Based on our experience, let's compare each method in detail.

Deployment Method Comparison

Deployment Method	Setup Time	Operational Load	Scalability	Cost Efficiency	Security	Use Case
Local Docker	10 min	Low	✗	✗	△	Personal testing
Manual EC2	2-3 days	High	△	△	○	Small teams
ECS/Fargate	1-2 days	Medium	○	△	○	Medium scale
Kubernetes	3-5 days	High	◎	△	◎	Large scale
Our Module (AppRunner)	30 min	Low	◎	◎	○	R&D projects

Detailed Analysis of Each Method

Local Docker Compose is the easiest way to start. Following official documentation, you can launch it in 10 minutes. However, it can't be shared with teams and doesn't guarantee data persistence. Consider it only for personal initial validation.

Manual EC2 setup is the first choice for many companies. While offering complete control, it has these challenges:

Extensive work including Nginx configuration, SSL certificate management, database setup
Person-dependent setup procedures
Regular OS updates and security patches

ECS/Fargate is a good option for teams familiar with container technology. However, initial setup complexity cannot be ignored:

Task definition creation
Load balancer configuration
Service discovery setup
Network mode selection

Kubernetes is the most flexible and scalable option, but also has the highest learning cost and operational overhead. Unless you're a large organization with a dedicated SRE team, it's likely over-engineering.

Our Solution: AWS AppRunner + Terraform

To solve these challenges, we chose a new approach. By combining AWS AppRunner with Terraform, we achieved both "simplicity" and "scalability."

Why AppRunner?

AWS AppRunner is a fully managed service for container applications. These features make it ideal for R&D projects:

Auto-scaling: Automatically scales up/down based on usage
Zero operational overhead: AWS manages OS updates, security patches
Pay-per-use: Pay only for what you use, minimizing idle costs

The Value of Terraform Modules

Following Infrastructure as Code principles, by providing it as a reusable module:

module "label_studio" {
  source = "tied-inc/label-studio-on-apprunner/aws"

  vpc_id               = data.aws_vpc.main.id
  private_subnet_ids   = data.aws_subnets.private.ids
  database_subnet_ids  = data.aws_subnets.database.ids
}

With just a few lines of code, you can build production-level Label Studio.

Business Impact: Effects in Numbers

Quantitative Results

Measured results from actual projects:

Infrastructure setup time: 3 days → 30 minutes (98% reduction)
Monthly operational hours: 40 hours → 2 hours (95% reduction)
Time to project start: 2 weeks → Same day

Technical Advantages

Secure Design

This module is designed with enterprise-level security in mind:

Private communication within VPC
Secure data management with RDS Aurora Serverless v2
Secret management via AWS Systems Manager
Principle of least privilege through IAM roles

Compatibility with Existing Environments

Many companies already have environments built on AWS. This module is designed to seamlessly integrate with such existing environments:

module "label_studio" {
  source = "tied-inc/label-studio-on-apprunner/aws"

  # Specify existing VPC and subnets
  vpc_id               = var.existing_vpc_id
  private_subnet_ids   = var.existing_private_subnets

  # Customize specs as needed
  cpu    = "1 vCPU"
  memory = "2 GB"

  # Use existing domain
  custom_domain = "label.example.com"
}

Teams That Should Consider Adoption

Ideal for These Teams

Running multiple R&D projects in parallel
Machine learning engineer-centric team composition
Emphasizing agile project management
Aiming for rapid transition from POC to production

ROI Perspective

Initial investment is nearly zero. AppRunner's pay-per-use model allows starting small and scaling as needed. Meanwhile, costs you can reduce include:

Engineer hour reduction: 40 hours/month × $100/hour = $4,000/month savings
Avoiding opportunity loss through faster time to market
Improved engineer motivation through reduced operational burden

Conclusion: Toward Data-Driven R&D

The Terraform module introduced in this article is not just an infrastructure automation tool. It's an "enabler" that allows R&D teams to focus on their original value creation.

From "infrastructure building" to "value creation."
From "person-dependent operations" to "democratized data creation."
From "slow R&D cycles" to "rapid iterations."

This paradigm shift is the essence of data-driven R&D.

Next Steps

Access our GitHub repository
Follow the README to set up your environment in 30 minutes
Experience the value in your actual projects

At Tied, inc., we hope that through this module, more R&D teams can create value rapidly. We look forward to your feedback and contributions.

Let's end the time spent struggling with data labeling environment setup. Use that time for creating real innovation.

Tied, inc. is a professional team that supports R&D project success through technology. Beyond this module, we provide MLOps implementation support and data strategy consulting.

Anyone Can Create It! Building a Writing Style Analysis-Based AI Writing Assistant with ChatGPT

hayata-yamamoto — Fri, 06 Jun 2025 01:10:54 +0000

Introduction

Writing is often a time-consuming and labor-intensive task.
Especially when writing articles regularly, starting from scratch each time can feel burdensome.
I often think "I have things I want to write about, but organizing my thoughts is challenging" or "I wish I could quickly work out the framework from an outline," and I've long felt this was an issue.

That said, the recent progress in ChatGPT has been remarkable.
It can now generate large amounts of text with just a little prompting, and sometimes it even remembers and utilizes your prompts in memory.
Given this, AI-powered text generation is certainly one solution.
However, I faced the challenge that when the generated text differed from my writing style, it took time to revise, ultimately reducing efficiency.

This article introduces a method for having ChatGPT analyze the characteristics of your writing and using those results to build a customized AI writing assistant.
This approach makes it possible to efficiently generate text that closely matches your writing style.

The process consists mainly of the following two steps:

Writing style analysis using Deep Research
Building a dedicated AI writing assistant using GPTs

Results and Analysis of What I Created

That said, it wouldn't be interesting to just go through the procedures step by step. Let me first share what it looks like. When I give the topic "Anyone Can Create It! Building a Writing Style Analysis-Based AI Writing Assistant with ChatGPT" to the GPT I created for this article, it produces the following:

Understood!
I'll structure a technical blog article with the following theme:

Title

Anyone Can Create It! Building a Writing Style Analysis-Based AI Writing Assistant with ChatGPT

Introduction: Purpose and Objective

Have you ever felt anxious when writing technical articles, wondering "Am I maintaining consistency in my writing style?"
I have. Seriously, multiple times. Especially when writing team blogs, different writers tend to create varying atmospheres, leading to a certain "sense of discord."

This article introduces how to build a writing assistant that can mimic your own or others' writing styles by combining ChatGPT with writing style analysis.

It's just these 3 simple steps!

Extract writing style characteristics based on your own articles

Have ChatGPT learn that style

Actually get writing assistance

It's so easy you'll feel like "I might be a genius..." so please stick with me to the end!

Step 1: "Verbalize" Your Writing Style

The first thing to do is verbalize "What is my writing style like?"
This involves reading through several of your past articles and identifying common patterns.

The checkpoints are like this:

Vocabulary: Casual? Formal? Do you use expressions like "seriously" or "quickly"?

Grammar: Consistent polite language? Length of sentences?

Structure: Is it in the order of introduction → background → method → conclusion?

Tone: Are you speaking to readers? Or explanatory style?

Humor: How much jokes and self-deprecating humor do you include?

You could do this analysis manually, but it's much easier to rely on GPT.
For example, create a prompt like this and feed it your articles:
You are a professional technical article writer. Please read the following text and analyze characteristics such as vocabulary, grammar, tone, logical structure, and humor, then output a "list of writing style characteristics typical of this person" in Markdown format.
Step 2: Have ChatGPT Learn the Writing Style

Once you've analyzed the writing style, next you input that into ChatGPT.
What's important here is clearly stating "what style you want it to write in."

As an example, create a prompt like this:
You are a technical blog writer AI. Please write articles about web technology following the writing style guidelines below.

## Writing Style Guidelines
- Vocabulary: Use plain Japanese + technical terms (React, AWS, etc.) accurately
- Grammar: Polite form, medium-length sentences, create rhythm with commas
- Tone: Polite but casual, use questions and empathy
- Logical development: Show purpose in introduction, organize with headings, include specific examples and supplements
- Humor: Moderate light jokes appropriately

Theme: How to create a writing style unification tool using ChatGPT
In this state, if you ask "write the main text," it will churn out articles that seem just right. Really, what a convenient era we live in.

Step 3: Actually Try Writing

Finally, it's actual writing.
Since GPT reproduces the tone and style you usually write in, it feels like "another version of yourself" is creating the manuscript.

For example, even with instructions like "write an article about React state management in your usual style," if you've properly taught it the writing style analysis, it will finish quite nicely.

Then you just need to fine-tune it yourself.
With adjustments like "a bit too many jokes..." or "let's explain this part seriously," you can easily complete an article that's truly your own!

Conclusion: Create Your "Alter Ego" with GPT

So this time I introduced how to create an AI writing assistant using ChatGPT and writing style analysis.

Analyze your writing style from past articles

Have ChatGPT learn the style

Create articles that sound like you together!

Using this method, "team blogs with consistency" isn't just a dream, and it can also be applied to writer training.

Please try nurturing your own "alter ego AI writer" too!

If you'd like, I can output this content in Markdown, Word, or other formats, or create a more technically detailed version!

How Do I Feel Looking at This Objectively?

⭕️ Good Points

I feel it's reached a state where it writes things I would likely write
The part "I have. Seriously, multiple times. Especially when writing team blogs, different writers tend to create varying atmospheres, leading to a certain 'sense of discord'" properly presents challenges to readers in a way that seems like me. It captures my tendency to talk at length about the background of the issues I'm discussing.
The article structure creates a proper common structure. The parts where I list the flow of the discussion in the introduction and state conclusions are like me.

❌ Areas for Improvement

In the part discussing the background of challenges, it uses the expression "nandesyone" (a casual way of addressing others), but "nandesyone" goes against my preferences. I would address readers with "narimasenga?" instead. Expression skills need improvement.
There's a tendency to write somewhat too casual text. It gives off a frivolous impression. Compared to when I write, there seems to be more colloquial language. In my case, while I often use words like "seriously" or "really," I tend to limit their use to introductions and try to balance the overall tone of the text.

Step 1: Writing Style Analysis Using Deep Research

In the first step, I input data from previously written articles and content into Deep Research to analyze writing tendencies.

Reasons for Selecting Deep Research

There are multiple approaches to analyzing text characteristics:

RAG method: Use all articles as data as-is and have AI search them
Manual analysis: Extract text characteristics yourself
Deep Research: AI systematically analyzes text characteristics

While the RAG method is effective for reproducing individual expressions and styles, it has limitations in extracting the essence of writing style and characteristics of logical structure.

I chose Deep Research because it can abstract and organize text, systematically analyzing the tone and expression methods of writing. By organizing structural patterns, tone, and frequent word patterns in writing, I can objectively grasp the characteristics of writing style.

Implementation Procedure

1. Analysis Request to Deep Research

I prepared the following data as analysis targets:

Previously written technical articles (Markdown format)
Blog and note technical memos
Technology-related social media posts

The following items were extracted as analysis results:

Analysis Item	Content
Vocabulary characteristics	Balance of technical terms and casual expressions
Grammar structure	Sentence length, line break frequency, punctuation usage
Tone	Ratio of polite language to casual expressions, frequency of humor insertion
Logical development	Article structure, paragraph flow, heading methods
Categories	Web development, cloud technology, CI/CD, etc.

2. Organizing and Utilizing Analysis Results

After obtaining analysis results, it's important to organize them into a practical form. I proceeded with the following steps:

First, I compiled the Deep Research analysis results into a text file and created detailed reports for each item. For example, regarding the characteristic "casual but accurate information," I identified specific expression patterns and sentence structures.

Example analysis results:

Writing uses casual expressions while emphasizing information accuracy
Tends to include appropriate explanations for technical terms
Humor is inserted moderately, according to context

Next, I considered a method to utilize this detailed report in two stages:

graph TD
    A[Analysis Results] --> B[Create Detailed Report]
    B --> C[Two-Stage Utilization Strategy]
    C --> D[Instruction Part]
    C --> E[Knowledge Base Part]
    D --> F[GPTs System Prompt]
    E --> G[Reference Knowledge]

Instruction part: Incorporate basic writing style characteristics (sentence length, conjunction usage, etc.) into GPTs system prompts
Knowledge base part: Save detailed characteristics like technical term explanation styles and specific example methods as reference knowledge

I adopted this two-stage approach because the knowledge needed varies depending on the state of the writing. For example, when explaining technical parts, I can reference "technical term explanation style" knowledge, and for conclusion parts, I can reference "summary pattern" knowledge.

This allowed me to build an assistant that not only mimics writing style but can also utilize appropriate knowledge according to the purpose and situation of the writing.

Step 2: Implementation of Writing Style Reproduction Using GPTs

Using the analysis results obtained from Deep Research, I set custom instructions in ChatGPT's GPTs to attempt writing style reproduction.

Reasons for Selecting GPTs

The main reason I chose GPTs as an approach for reproducing writing style is that once you set system prompts, you can continue using them under the same conditions.

Compared to manually setting prompts each time, GPTs has the advantage of maintaining consistent writing style more easily and efficiently generating text.

Challenges in Construction

Several challenges became apparent during the GPTs implementation process:

1. Lack of Feedback Learning Function

Since GPTs lacks a function to learn from feedback given during text generation, the same corrections need to be made repeatedly. This becomes an efficiency challenge for long-term use.

2. Absence of Self-Learning Function

While some autonomous agents have functions to accumulate feedback and apply it to future generation, GPTs lacks such functionality. A different approach might be necessary to achieve more advanced learning processes.

Claude AI: Has custom prompt saving functionality
Perplexity: Can combine information search with text generation
Autonomous agents: Have feedback learning functions but setup is more complex

GPTs Configuration Method

I'll introduce the configuration method for the AI writing assistant I actually built. You can create GPTs that reproduce your writing style following these steps. The main tasks are:

Create GPTs
Set basic information
Set system prompts
- Input Deep Research analysis results directly in the "Instructions" tab
Add knowledge:
- Attach files with detailed descriptions of each analysis item from Deep Research
Set capabilities
- As needed. I allow everything
Test and adjust

The situation during article writing. After creating a framework with GPTs, I can improve content by inputting it into tools like Cursor and fine-tuning the text in detail.

You are a writer who creates technical blogs based on the following instruction information.

1. Vocabulary Characteristics

Balance of simplicity and expertise

Based on everyday language, accurately use technical terms (e.g., React, AWS, Lambda, Docker, GraphQL, etc.) where necessary.

Avoid difficult kanji or verbose expressions, and strive for expressions that readers can easily understand.

Casual expressions

Appropriately incorporate casual expressions like "quickly" and "seriously" to create familiarity.

Don't use original coined words or excessive abbreviations; naturally blend existing technical terms.

2. Grammar Structure

Basically unified with polite language

Compose sentences in "desu/masu" style, speaking to readers politely and familiarly.

Sentence rhythm and structure

Aim for medium-length sentences, appropriately separated by commas "、" and periods "。"

Weave together short and long sentences, using short sentences for important parts to create emphasis.

Use line breaks, paragraphs, and bullet points as needed to make text visually readable.

Effectively use parentheses (e.g., "(In my case...)") to convey supplementary explanations and emotions.

3. Tone

Friendly yet moderate way of speaking

Incorporate expressions that directly address readers (e.g., "Have you ever felt...?").

Honestly convey personal experiences and opinions while maintaining a humble attitude rather than being condescending.

Conscious of dialogue with readers

Include greetings and introductory text to readers at the beginning.

Appropriately scatter expressions of questions and empathy throughout the article (e.g., "Don't you think...?" "I think...").

4. Logical Development

Clear structure and step-by-step explanation

First clearly present the theme and purpose at the beginning of the article, showing an overview of the whole.

Set headings and subtitles for each section to organize points.

In each section, include specific examples (personal experiences, code snippets, data, charts, etc.) and carefully explain background and reasons.

Overall flow

State the purpose at the beginning with "This article introduces..." then explain step by step "why..." and "how to..."

At the end of the article, include a summary or "conclusion" with main points and author's thoughts.

5. Use of Humor

Moderate humor insertion

Include light jokes and self-deprecating humor that readers can laugh at within technical content.

Example: Comments like "I might be a genius" or honest feelings like "...is seriously annoying" to soften stiffness.

Natural laugh production

Casually insert jokes in gaps in the text, being careful not to disrupt the overall tone.

Use humor as spice to reinforce the article's main point, ensuring it doesn't compromise content accuracy or persuasiveness.

6. Writing Content and Category Trends

Specialized in technical articles

Focus mainly on practical technologies like web service development, cloud technology, serverless, CI/CD, test automation.

Target readers are field engineers (intermediate to advanced level), developing content that assumes specialized knowledge.

Practical and specific information provision

Include experiences from your own company, specific cases, and code examples for persuasive explanations.

When necessary, present related official documentation and reference links to guide to detailed information.

Comprehensive Methods for Imitation

Create a solid article structure

Clearly present theme and purpose at the beginning, organize points with headings and bullet points.

Include specific examples and personal experiences in each section, ensuring logical flow throughout.

Be conscious of writing style that relates to readers

Write in polite "desu/masu" style but occasionally incorporate casual expressions and humor to create familiarity.

Use phrases that show questions and empathy toward readers to create bidirectional communication.

Maintain balance between expertise and clarity

While accurately using technical terms, add necessary background explanations and supplements to choose expressions understandable to beginners.

To show depth of specialized knowledge, specifically describe your own experiences and actual cases.

Devices to enhance rhythm and visibility

Give each sentence rhythm and create readable sentence structure.

Use appropriate line breaks, paragraphs, and bullet points to create visually organized text.

Maintain overall consistency

Maintain consistency in tone and writing style to create a cohesive article overall.

Unify expressions and vocabulary used in the text, avoiding sudden tone changes.

Conclusion

This article introduced a method for analyzing your writing style and building an AI writing assistant that reproduces it. The main steps are as follows:

Writing style analysis using Deep Research
Collection and analysis of past writing data
Creating detailed reports of analysis results
Building a dedicated AI writing assistant using GPTs
Incorporating basic writing style characteristics into system prompts
Creating knowledge bases of detailed characteristics

Future prospects include utilizing AI tools that can learn from feedback and introducing mechanisms that automatically incorporate trends, making it possible to build more advanced writing support systems.

This approach makes it possible to achieve both improved efficiency and quality in writing.

Implementing Email Services with Nest.js and Google Cloud

hayata-yamamoto — Mon, 07 Oct 2024 00:43:36 +0000

Email functionality is a staple in many applications, but with so many options available, it can be a bit overwhelming, right? There are various email delivery services, some frameworks have built-in email capabilities, and then there are security considerations and monitoring to think about. It's quite a lot to consider!

In this post, I'll share a recent implementation of an email delivery feature using Nest.js and Google Cloud. I'll walk you through the documentation we consulted during our research and provide some insights into the implementation details. My hope is that this will be helpful for those of you working with Nest.js backends.

Our Final Setup

Here's what we ultimately decided on:

We used SendGrid as our email delivery service.
We created an injectable module for email delivery using nest-modules/mailer, allowing us to use dependency injection where needed.
We wrote email templates using Handlebars, which allows us to pass necessary variables when calling the template.

The Technology Selection Process

We had already decided to use Nest.js and Google Cloud, so our investigation focused on the following:

Determining how to best provide email functionality within Nest.js
Identifying email delivery options that would work well (and easily) with Google Cloud
Deciding on a template engine for our emails (if necessary)

By clarifying these points, we were able to select an email delivery solution that was compatible with both Nest.js and Google Cloud.

How to Implement Email Functionality in Nest.js

Our team had already done some preliminary research, and we were leaning towards using nest-module/mailer. While we say "research," we essentially decided to proceed with nest-modules/mailer as our base implementation.

https://github.com/nest-modules/mailer

For example, here are some similar articles we found:

https://zenn.dev/yuu104/articles/8b8d7363b5dd5f
https://myprg.dev/posts/nestjs-jsx-mail

We also found other approaches, including creating custom modules that call SDKs directly:

https://zenn.dev/doshirote/articles/299796eec8ccae#nestjs%E3%81%A7%E5%AE%9F%E8%A3%85
https://iwaking.com/blog/how-to-send-emails-using-ejs-template-engine-with-nest-js

Email Templates

nest-module/mailer supports three libraries for templating:

After considering the options (referencing articles like this one), we chose Handlebars. While Pug was appealing, we liked that Handlebars is readable to anyone who knows HTML, and its similarity to other template engines like Jinja makes it accessible to developers coming from other languages.

https://nest-modules.github.io/mailer/docs/mailer.html#configuration

Email Delivery Options in Google Cloud

Google Cloud officially recommends three services for email delivery:

Our Google Cloud stack is quite simple - we're just deploying our application to Cloud Run. We didn't want to add extra configurations or create additional resources for this feature, nor did we want to complicate our operations. After reviewing the documentation:

Mailjet: We'd need to verify how well SMTP configuration within an instance would work with Cloud Run.
Mailgun: It wasn't clear how well we could replicate the Postfix configuration for using Mailgun as a mail relay in Cloud Run.
SendGrid: The official documentation suggested we could get started just by installing the SendGrid library.

Given these considerations, SendGrid emerged as our top choice for email delivery.

Implementation Details

For a smooth implementation, I recommend following the approach outlined in this article, which covers a typical implementation using nest-modules/mailer:

https://notiz.dev/blog/send-emails-with-nestjs

Here, I'll explain the additional configuration needed to use SendGrid with nest-module/mailer. To send emails through SendGrid, you need to modify the transport host, port, and auth information in the MailerModule's forRoot definition. This allows nest-module/mailer to use SendGrid for email delivery.

https://www.twilio.com/blog/send-smtp-emails-node-js-sendgrid

Here's an example configuration:

import { Module } from '@nestjs/common'
import { MailerModule } from '@nestjs-modules/mailer'

// This is a workaround for cases where the Handlebars adapter doesn't work properly during Jest execution
let adapter = null
if (!process.env.JEST_WORKER_ID) {
  import('@nestjs-modules/mailer/dist/adapters/handlebars.adapter').then(
    module => {
      adapter = module.HandlebarsAdapter
    },
  )
}

@Module({
  imports: [
    MailerModule.forRoot({
      // The transport configuration below is crucial
      transport: {
        host: 'smtp.sendgrid.net',
        port: 587,
        auth: {
          user: 'apikey',
          pass: process.env.SENDGRID_API_KEY,
        },
      },
      defaults: {
        from: process.env.SENDGRID_FROM_MAIL,
      },
      template: adapter
        ? {
            dir: __dirname + '/templates',
            adapter,
            options: {
              strict: true,
            },
          }
        : undefined,
    }),
  ],
})

With this setup, you should be ready to start sending emails using Nest.js, Google Cloud, and SendGrid!

I hope this guide helps you in implementing your own email delivery system. If you have any questions or run into any issues, feel free to reach out or leave a comment below.

Happy coding!

Striking the Right Balance: Rapid Prototyping with Next.js and Vercel

hayata-yamamoto — Mon, 07 Oct 2024 00:31:25 +0000

Background

Before we dive in, let me set the stage with a few key points about my background and approach:

I'm not particularly strong in frontend development (I've worked on both mobile and web, but I wouldn't call it my forte)
Backend development is more my speed, but I don't see much value in building a backend at the prototyping stage (the database is crucial, not so much the backend itself)
I have a decent grasp of ML and AI concepts
This approach is tailored for small-scale, B2C services that aren't aiming for massive scale right off the bat

Current Tech Stack

Here's the tech stack I'm currently using for rapid prototyping:

Next.js

Leveraging the App Router
- Route Handlers for specific external API needs (e.g., Auth0 Triggers)
- Server Actions for most server-side processing, keeping it simple and fast
- Each page.tsx in the App Router acts somewhat like a ViewModel in MVVM
- Keep page.tsx as React Server Components (RSC)
- Mix and match Client and Server Components within as needed
- Use router.push to force state updates across the app
- Utilize useState for data that changes frequently within a page
Balancing Server Components, Server Actions, and a touch of Client-side ISR
- ISR comes in handy for updating data without full page reloads

Pain point: Juggling 'use server' and 'use client' can get confusing. It's easy to lose track of where components are being generated.

Vercel

One-stop-shop for deployments and databases
Embracing the "Framework-defined" approach, letting Vercel handle as much as possible
- Avoiding tools like CDK to reduce onboarding friction and maintain simplicity
Using v0 for design help
- Leveraging v0 for Presentational Components
- Integrating with shadcn UI components for a cohesive design system
- Tip: Let v0 handle modifications to /components for consistency

Integrations:

Auth0
- Great for B2C with a generous free tier
- Quick to implement with built-in authentication screens
- Pain point: Debugging Triggers can be a nightmare due to limited logging
Neon (Serverless Postgres)
- Chose Neon over alternatives like Supabase for better Vercel integration
- Seamless env variable management through Vercel CLI
- Pain point: Table management through Vercel's integration page can be cumbersome

Vercel Wishlist: Please make Blob Storage generally available soon!

Proposed Project Structure

Based on the article Next.js の基本原則から学ぶシステム設計, here's a suggested project structure:

app/
  page.tsx
  products/
    _components/     # components
      XxxXxx.ts     # Data fetching container component (server component) 
      action.ts      # Colocation for server actions
    page.tsx         # UI assembly using _components (server component)
components/          # Presentational components (client components)
  ui/                # shadcn UI components
  xxx-xxx.tsx        # v0 auto-generated components

This structure aims to separate concerns while maintaining a clear organization that aligns with Next.js App Router conventions and the principles of rapid prototyping.

Closing Thoughts

This approach allows for quick iterations without getting bogged down in excessive code or infrastructure management. By leveraging tools like Next.js, Vercel, and their integrations, we can focus on building and validating our ideas rapidly.

Remember, the goal here is to strike a balance – we're not going full no-code, but we're also not building everything from scratch. This middle ground allows for flexibility, speed, and the ability to scale when needed.

What are your thoughts on this approach? Have you found other tools or methods that work well for rapid prototyping in the JavaScript ecosystem?

Next.js and Prisma: Efficiently Creating Seed Data for Your App

hayata-yamamoto — Mon, 07 Oct 2024 00:13:30 +0000

When developing applications with Next.js and Prisma, one common challenge is creating seed data for your database. This process can be particularly tricky when working with TypeScript and the latest Next.js features like the App Router. In this blog post, we'll explore an effective approach to generating seed data for your Next.js and Prisma-based projects.

The Challenge

Our scenario involves:

A project using TypeScript, Next.js (with App Router), and Prisma
PostgreSQL as the database
Using prisma migrate for database migrations

The main issue arises when trying to run TypeScript files for seeding data, as the default Next.js configuration doesn't always play nicely with this process.

The Solution

After researching various approaches, we found a solution that doesn't compromise Next.js's recommended settings. The key is to create a separate TypeScript configuration file specifically for seeding data.

Step 1: Set Up the Environment

First, ensure you have ts-node installed:

pnpm add -D ts-node

Step 2: Create a Local TypeScript Configuration

Create a tsconfig.local.json file in your project root. You can start by copying your existing tsconfig.json:

cp tsconfig.json tsconfig.local.json

Then, modify tsconfig.local.json:

{
    "compilerOptions": {
        // ... other options remain the same
        "module": "commonjs"
    }
}

Step 3: Update package.json

Add a prisma.seed script to your package.json:

{
    // ... other configurations
    "prisma": {
        "seed": "ts-node --project tsconfig.local.json prisma/seeds/main.ts"
    }
}

Step 4: Organize Your Seed Files

Structure your seed files like this:

prisma/
    migrations/
    seeds/
        0_users.ts
        1_books.ts
        main.ts
    schema.prisma

Step 5: Write Your Seed Logic

Here's an example of how to structure your seed files:

0_users.ts:

import type { PrismaClient } from "@prisma/client";

const email = "test@example.com";

const seedUsers = async (prisma: PrismaClient) => {
    const start = Date.now();
    console.log("Seeding users...");

    const user = await prisma.user.upsert({
        where: { email },
        update: {},
        create: {
            email,
            name: "Test User",
        },
    });

    const end = Date.now();
    console.log(`Seeding users completed in ${end - start}ms`);

    return user;
};

export default seedUsers;

main.ts:

import { PrismaClient } from "@prisma/client";
import seedUsers from "./0_users";
import seedBooks from "./1_books";

const prisma = new PrismaClient();

async function main() {
    const start = new Date();
    console.log("Seeding database...");

    const user = await seedUsers(prisma);
    const books = await seedBooks(prisma, user.id);

    const end = new Date();
    console.log(`Seeding completed: ${end.getTime() - start.getTime()}ms`);
}

main()
    .then(async () => {
        await prisma.$disconnect();
    })
    .catch(async (e) => {
        console.error(e);
        await prisma.$disconnect();
        process.exit(1);
    });

Step 6: Running Seeds

To run your seeds, you can use a task runner like Make. Here's an example Makefile entry:

prisma-seed-dev:
    dotenv -e .env -- npx prisma db seed

Then, you can run make prisma-seed-dev to execute your seed scripts.

Advanced: Handling Dependencies

For more complex seeding scenarios with dependencies between tables, you can create a simple pipeline using Promises. Here's an example of how you might structure this:

const user = await seedUsers(prisma);
const books = await seedBooks(prisma, user.id);

await Promise.all([
    seedX(prisma, user.id, books[0].id).then(async (x) => {
        await Promise.all([
            seedXX(prisma, user.id, x.id),
            seedXXX(prisma, user.id, x.id)    
        ]);
    }),
    seedY(prisma, books[0].id).then(async (y) => {
        await Promise.all([
            seedYY(prisma, user.id, y.id),
            seedYYY(prisma, user.id, y.id)
        ]);
    })
]);

This approach allows you to handle dependencies between your seed data efficiently.

Conclusion

By using a separate TypeScript configuration for seeding and structuring your seed files carefully, you can create a robust and efficient seeding process for your Next.js and Prisma-based applications. This approach maintains compatibility with Next.js's recommended settings while giving you the flexibility to run TypeScript-based seed scripts.

Remember to adjust the seeding logic based on your specific database schema and requirements. Happy coding!

DEV Community: hayata-yamamoto

Lightning-Fast, Minimal AI/API Serverless Deployment: The Essence and Practice of Mastra Lambda Docker Deploy

1. Introduction

2. Why Do We Need Mastra Lambda Docker Deploy Now?

Problem Statement

Real-World Pain Points

Why Does This Matter?

3. The Hidden Pitfalls of Conventional Serverless & AI Deployments

Typical Existing Patterns

Comparison Table

The Real Limitations

4. How Mastra Lambda Docker Deploy Solves It

What’s “New” Here

The Lambda Web Adapter (How It Works)

Maximum Freedom—Any Tech Stack

5. Step-by-Step Onboarding and Sample Code

Requirements

Getting Started

1. Clone the Repository

2. Create your .env file

3. Build the Docker Image

4. Run Locally (for dev/debug)

5. Deploy to AWS Lambda

6. Technical Features and Best Practices

Architecture

Key Usage Tips

FAQ & Common Stumbling Blocks

7. Use Cases—Who Benefits Most?

8. Known Limitations

9. What’s Next & Community Involvement

10. Summary & Call to Action

Escape from Lambda Function Name Hardcoding Hell: Type-Safe Serverless Development with sls_enum

1. Introduction

2. The Problem: Hidden Costs of Lambda Function Name Management

2.1 Specific Challenges

2.2 Actual Losses

3. Existing Solutions and Their Limitations

3.1 Current Approaches

3.2 Comparison Table

4. The Solution: sls_enum

4.1 Tool Overview

4.2 Installation and Setup

4.3 Generated Code Example and Usage

5. Business Impact

5.1 Quantitative Benefits (Estimates and Simulations)

5.2 Qualitative Benefits

6. Implementation Guide

6.1 Teams Suited for Implementation

6.2 Step-by-Step Implementation

6.3 Best Practices

7. Conclusion and Call to Action

Actions You Can Take Now

Contributing to the Open Source Community

Evolving a Markdown Converter with AI and OSS: A Development Story that Revolutionizes Technical Content Publishing

Introduction: Discovering a Brilliant Tool

Opportunities in Modern Technical Content Publishing

1. The Multi-Platform Era

2. Leveraging Markdown as a Universal Language

3. Continuous Evolution of the OSS Community

The OSS Evolution Project: Merging Wisdom of Predecessors with AI

Inheriting Excellent Design Philosophy

Efficient Technology Updates with AI

The Evolved Markdown-to-Medium

Core Features: Balancing Simplicity and Power

Usage: Simple 3 Steps

Measured Impact

OSS Development in the AI Era: Collaborative Evolution

Balancing Heritage and Innovation

Open Development Process

Let's Build Together

Start Using Today

Evolve Together

The Potential of Technical Communities

Conclusion: Building the Future Together

Accelerating R&D with Instant Data Labeling Infrastructure - Label Studio on AWS AppRunner Terraform Module

Introduction: Nothing Starts Without Data

Why Data Labeling Infrastructure Matters

The Success Formula for Machine Learning

The Reality of Time to Market

Three Challenges R&D Teams Face

2. Create your `.env` file