DEV Community: Rodrigo Ramirez

How Organization Roles Change in the AI Era

Rodrigo Ramirez — Sun, 01 Mar 2026 14:16:57 +0000

AI changed how teams build software. But most conversations stop at the tools — which AI to use, how to prompt it, how much code it generates.

The bigger question is different. How should the organization itself be structured when AI handles execution?

AI compresses the execution layer. The value of "I can write code" drops. The value of "I know what to build and why" rises. If AI can generate 80% of a feature, the bottleneck is not typing — it is judgment.

Leadership Becomes Architecture

When AI takes over execution, the value of leadership shifts. The most important work becomes making the key decisions, defining the rules, and creating the constraints that others — and AI — operate within.

This is what "architect" means in this context. Not just designing structures — but deciding what gets built, how teams work, and what rules AI agents follow. Every leadership role is becoming an architect of constraints in their domain.

Three Domains, Three Architects

An organization needs constraints in three areas. Each one has a different owner.

Role	Designs
PM	Product — strategy, rules, what to build
Manager	Operations — tools, teams, processes
Tech Architect	System — constraints, agents, guardrails

PMs are business architects. They translate the company vision into detailed business rules that guide daily work. What do we build? Why? What does success look like? These decisions cannot come from AI. They require understanding the market, the customer, and the strategy.

Managers are organization architects. They design how the company works internally — communication norms, tools, team boundaries, what each team owns. Their job is not to supervise execution. It is to create the environment where people and AI can work well together.

Technical architects design the system. They define code conventions, build AI agents, set quality guardrails, and create the rules that make AI output consistent and trustable. When something goes wrong, architects improve the rules. They do not review every line — they design the system that catches problems.

The common thread: all three design constraints for others to operate within. Different domains, same function. None of them are doing the building. All of them are shaping how building happens.

Members — Broad Generalists with Judgment

Members build within all three sets of rules. Business rules tell them what to build. Organization rules tell them how to work. Technical rules tell them how the system operates.

AI handles the execution — writing code, generating tests, scaffolding features. What members need is broad knowledge and judgment. The engineer who can go from customer conversation to problem framing to architecture to shipping is much more valuable than someone who only does one slice.

This is a shift. Before AI, deep specialization was the most valued skill. A backend expert did not need to touch frontend. Nobody expected them to talk to customers. Now, specialists become architects. Members become generalists. Not because depth does not matter, but because AI fills the gaps in breadth. You do not need to be an expert in React if AI can scaffold 90% of it. Enough judgment to review the output is what matters. The deep expertise lives in the architects who design the rules.

Members work freely within a safe area. The architects defined the boundaries. The business rules defined the goals. The member's job is to use judgment, solve problems, and deliver — with AI as the execution engine.

Smaller Teams, Broader Roles

If one engineer with AI can cover what used to take three specialists, teams shrink. Not because people were fired — but because fewer people carry more responsibility. Same output, fewer humans, each one operating more like a product-engineer hybrid.

The dedicated PM role shrinks. The function — business decisions, strategy, understanding the customer — does not disappear. It gets absorbed by engineers. In small teams, the person who builds also decides what to build. In larger organizations, a dedicated PM still makes sense. But even there, the wall between "person who decides" and "person who builds" gets thinner. Engineers are expected to have opinions about the business — not just take tickets.

Management changes too. A team of three does not need a full-time people manager. The role becomes more like a player-coach — someone who mostly builds but also coordinates. Less oversight, more contribution.

The risk is resistance. Some engineers want to stay in the "give me a well-defined ticket" mode. In teams optimizing for AI, that mindset becomes hard to justify. The engineers who thrive treat AI as a way to expand their scope — not just to write code faster.

The Junior Problem Is Real

Juniors are struggling in this new structure. Not because AI is hard to use — but because AI removed the execution work they used to learn through.

Before AI, juniors learned by writing code. They built intuition through repetition — debugging, refactoring, seeing patterns. Now AI handles most of that work. The skills juniors need earlier are the ones that used to come with experience: decision-making, judgment, problem evaluation.

Architects can help. Good guardrails create a safer space for juniors to operate. Clear rules, defined conventions, and automated quality checks let a junior produce work that meets the baseline. But judgment is still human. The guardrails reduce the risk — they do not replace the learning.

Training must change. Organizations cannot wait for juniors to accumulate years of experience before they make decisions. Decision-making and problem-solving must be taught earlier and more deliberately.

AI Helps You Think — But Does Not Decide for You

AI is more than an execution tool. It can research, propose ideas, surface options, and challenge assumptions. AI is a powerful thinking partner.

But there is a line. AI can present three approaches to a problem. It can analyze tradeoffs. It can find information faster than any human. The decision about which option fits your business, your team, your situation — that stays human.

This applies to every role. Architects use AI to explore constraints before defining them. Members use AI to evaluate options before choosing one. PMs use AI to research before setting strategy. In every case, AI expands what you can consider. The judgment about what to do is yours.

The human who approved the work carries the consequences. AI does not.

The Shift

AI did not change what organizations need. It changed where the value sits. Execution is cheap now. Judgment, constraints, and clarity about who decides what — that is the new bottleneck.

The organizations that get this right will move faster with fewer people. Not because AI replaced anyone — but because the structure made every person and every tool more effective.

Software Development in the AI era

Rodrigo Ramirez — Wed, 17 Dec 2025 02:53:23 +0000

Many teams using AI ship more code. Not all of them are shipping better software.

I'm writing this based on what I've seen in real teams adopting AI in production. Look at the metrics — cycle time, velocity, features delivered. If AI can generate most of the code, you might expect teams to be three or four times faster. Often, they're not. The improvement can be smaller than expected.

In my view, the tools aren't the limiting factor. The system around them is.

AI accelerates one part of the process: writing code. But software development is more than writing code. It's requirements, architecture, testing, reviews, QA, and release. These parts are interconnected. When only one part speeds up, the system doesn't improve much. Bottlenecks shift to the parts that weren't designed for this speed.

Engineers generate more code. But someone needs to review it, and that person needs context to judge correctness. QA can get overloaded. When requirements aren't clear enough, the AI builds the wrong thing. Teams iterate more, but progress can stay flat.

One pattern I've seen: a team doubles their PR volume after adopting AI. But review capacity stays the same. PRs queue up. Reviewers skim instead of reading. Bugs slip through. The team feels faster, but defect rates climb and cycle time doesn't improve. The bottleneck just moved.

The solution isn't to slow down AI adoption. It's to use AI across the workflow — but only where the system can safely validate the output. AI can assist with reviews, generate tests, clarify requirements, and automate QA. But for that to work, the system around it must change.

This post explores which parts of software development need to change to really benefit from AI code agents.

The big shift: code is cheap, trust is expensive

AI code agents changed the cost structure of software development.

Before AI, writing code was the slow and expensive part. Most processes were designed to protect that cost — long reviews, heavy planning upfront, clear separation of roles, manual testing at the end.

Now this assumption is broken. AI can generate working code very quickly. Creating code is no longer the bottleneck.

But this does not mean software is easier to build.

What became expensive is something else: understanding what changed, knowing if the change is correct, knowing if it's safe to deploy, knowing if it will break something later. In other words, trust became the expensive part.

Teams still own the consequences of changes. Bugs in production. Security issues. Performance regressions. Hard-to-maintain systems. AI doesn't take that responsibility.

This creates a mismatch.

One part of the system — code generation — is now very fast. Other parts — review, testing, validation, release — are still slow and human-limited.

When this happens, teams feel the pain. Pull requests pile up. Reviews become shallow because reviewers lack context. Bugs slip into production. More activity, same output.

This is why many teams don't see a big improvement in quality, stability, or features delivered per engineer. The system was optimized for a world where writing code was the hard part. In the AI era, the hard part is different.

Engineering work is shifting from writing code to creating trust in changes.

This trust doesn't come from the AI model. It comes from architecture that limits impact, tests that define what must be true, reviews that focus on intent and risk, and processes that catch problems early. If these parts don't change, faster code generation only creates faster bottlenecks.

This shift is the foundation for everything else in this post.

Codebases: consistency matters more than speed

When AI generates code faster than humans can review it, the main risk is no longer speed. The real risk is losing coherence.

A codebase is not just a collection of files. It's a shared mental model. When changes are slow, teams can rely on memory, informal knowledge, and manual coordination. When changes are fast, that stops working.

In the AI era, a codebase must help humans answer one question quickly: "What does this change affect?" If that answer is unclear, trust breaks down.

Change must be easy to understand

Fast code generation increases the volume of change. If each change is hard to understand, the system becomes fragile.

The priority is not writing clever code, maximizing reuse, or reducing lines of code. The priority is clarity of responsibility, clear boundaries, and predictable behavior. A good codebase makes it obvious where logic lives, why it exists, what depends on it, and what doesn't.

When this is true, reviews are faster and safer — even when AI generates most of the code.

Local reasoning becomes essential

Humans have limited attention.

If understanding a small change requires understanding the whole system, AI won't help. It will only accelerate confusion.

Modern codebases must support local reasoning: you can understand a change by looking at a small part, you don't need global context for every decision, and side effects are controlled and visible. This isn't a tooling problem. It's a design problem.

Before AI, this was a best practice. Now it's a survival requirement. Engineers used to keep context in their heads because changes were slow enough to remember. Now AI generates code faster than humans can track. The only way to stay in control is to build systems where you don't need to remember everything.

Consistent patterns build trust

You can't make external APIs or distributed systems predictable. But you can control how your code responds to unpredictability — retry patterns, rollbacks, logging, timeouts, error handling. These should be consistent rules in a shared framework, not left to individual judgment.

When every engineer (and every AI) follows the same patterns for handling failures, the system becomes easier to trust, test, and review. The goal isn't to eliminate unpredictability — it's to make your response to it consistent.

Structure is a safety mechanism

Structure is not about elegance. In the AI era, structure is a safety mechanism.

It exists to ensure that faster change doesn't reduce quality, more output doesn't reduce understanding, and automation doesn't remove human control. If the system doesn't protect coherence, AI will expose that weakness very quickly.

Testing & QA: defining trust, not finding bugs

When code becomes cheap, testing becomes more important — not less.

AI makes it easy to generate code, but it also makes it easy to introduce changes that look correct and still break important behavior. This is why testing and QA change role in the AI era. The goal is no longer mainly to find bugs. The goal is to define what it means for the system to be correct.

Tests as shared truth

In fast-moving systems, people can't rely on memory or manual checks.

Tests become the most reliable description of system behavior — the place where assumptions are made explicit, the contract between past and future changes. When AI generates code, tests are what allow humans to say "this change is safe," "this behavior is intentional," and "this must never break."

Without strong tests, faster code generation only increases uncertainty.

Quality moves earlier, by necessity

If validation happens late, AI creates pressure. More changes arrive faster. Reviews pile up. Manual QA becomes overloaded. Issues slip into production.

So quality must move earlier in the process. Not because it's fashionable, but because it's the only way the system can scale. Correctness gets checked close to where changes are made. Feedback is fast. Errors are cheap to fix. When this doesn't happen, teams feel busy but unsafe.

QA designs, AI executes

In this context, QA is less about execution and more about designing safety.

The shift is concrete: QA moves from clicking through pages to find bugs, to defining what should be tested. QA identifies risk areas, creates rules about what makes the system safe, designs end-to-end test scenarios, and specifies what's important to check. Then AI generates the test code, writes the automation, and executes the checks.

AI can help generate tests, but it can't decide what's critical, what's acceptable to break, or what trade-offs the business allows. Those decisions remain human. The hours are spent differently — designing rules versus executing manual checks.

Trust comes from systems, not heroics

In slower environments, teams can rely on manual testing, individual expertise, and last-minute checks. In fast AI-assisted systems, this doesn't scale.

Trust must come from clear definitions of correctness, automated validation, consistent signals, and repeatable processes. If trust depends on "someone checking carefully," the system will fail under speed.

Product and context: clarity becomes the main input

When AI generates code, the quality of the output depends heavily on the quality of the input.

In traditional development, unclear requirements created friction, but teams could compensate with meetings, back-and-forth, and manual adjustments over time. In AI-assisted development, this compensation doesn't scale. Fast code generation amplifies unclear thinking.

Context replaces instructions

AI doesn't understand intent unless it's made explicit.

The most important input to the system is no longer tasks, tickets, or step-by-step instructions. It's context — why this exists, what problem it solves, what constraints matter, what must not change, and what success looks like. Without context, AI produces code that's technically correct but conceptually wrong.

Product work moves closer to engineering

This changes how product and engineering interact.

The work is less about handing over requirements, translating documents, or defining every step upfront. It's more about shaping understanding early, defining boundaries, aligning on intent, and making trade-offs explicit.

Product and engineering collaborate earlier. Engineers participate more in definition. The gap between "deciding" and "building" becomes smaller.

Context is a scalability problem

When teams are small and slow, context can live in people's heads. When teams move fast, this breaks.

AI increases speed, which means implicit knowledge becomes dangerous, undocumented assumptions cause failures, and misunderstandings scale quickly. This is why clear context becomes a core engineering concern, not only a product one.

If context is weak, reviews become harder, tests are incomplete, and trust decreases. If context is strong, AI output improves, reviews focus on real risks, and teams move faster with confidence.

Think small, iterate fast

Big projects with detailed upfront specs don't work well in the AI era. Instead: think small, prototype quickly, get feedback faster. Since code is cheap, tries are cheap. But cheap tries only help if the team can validate and decide quickly. A/B testing, small releases, rapid iteration — this is how many high-performing teams work now.

But to iterate quickly and safely, you need to know the impact of each change. That requires clear boundaries, good tests, and fast feedback. Safety mechanisms enable speed, not slow it down.

Writing less, explaining better

This doesn't mean more documents. It means better signals — clear acceptance criteria, examples over abstractions, explicit constraints, and visible non-goals.

The system works best when humans focus on making intent clear, and AI focuses on executing within that intent.

Team shape: smaller teams, higher responsibility

When AI increases individual leverage, team structure must change.

One engineer can now move faster and cover more ground. This reduces some coordination costs, but it also concentrates responsibility. Adding more people doesn't always help. Sometimes it makes trust harder.

Speed changes the failure mode

In slower systems, problems are visible early — delays, blocked tasks, long feedback loops. In fast systems, failures look different. Many changes happen at once. Issues appear later. Responsibility is unclear. Debugging becomes expensive.

This is why team shape matters more when speed increases.

Smaller teams need clearer ownership

When fewer people can deliver more, ownership must be explicit.

A healthy AI-era team knows what it owns and what it doesn't. It understands the consequences of its changes. It feels responsible for outcomes, not only tasks. Without clear ownership, faster execution creates confusion, not progress.

Responsibility moves closer to the work

AI reduces the need for handoffs — waiting for another role, depending on specialists for every step, pushing work downstream. But this also means decisions happen closer to code. Mistakes happen closer to code. Learning happens closer to code.

Teams that succeed accept this trade-off. They invest in safety mechanisms, fast feedback, clear boundaries, and shared understanding.

AI assists both sides

If AI only generates code, smaller teams face a bottleneck: who reviews all this output? The answer is that AI assists review too — checking code against rules, summarizing changes, flagging risks, ensuring consistency.

Humans don't need to review every line. They decide what to focus on, what risks matter, and whether the intent is correct. AI handles volume; humans handle judgment. This is how fewer people can oversee more output without sacrificing quality.

Trust must scale with speed

In high-speed teams, trust can't depend on individuals. It must come from the system — tests, clear ownership, visible signals, and predictable processes.

If trust depends on heroics, the team will break as speed increases.

Closing thoughts

AI doesn't remove engineering work. It changes where the hard work is.

Writing code is no longer the constraint. Requirements, reviews, QA, and release processes are. Some teams have already adapted — they redesigned their system around clarity, fast feedback, and explicit responsibility. For them, AI is delivering real improvements. For others, the gains are smaller because only one part of the process changed.

This isn't a universal failure story. It's an explanation of why outcomes vary, and what separates the teams that benefit from those still waiting for the payoff.

Database, Table and Column naming conventions

Rodrigo Ramirez — Sat, 03 Apr 2021 09:47:23 +0000

A naming conversion is a set of rules you should follow to increase your data models' readability.

In this post, we will talk about the best practice I have found and followed along on my career as a developer (PHP, Node.JS, MySQL, PostgreSQL) and the reasons for each one of them.

In the end, it's not important which one you follow, but you should follow a naming convention.

Table Name

You should use singular nouns for database table names.

If you have a table to store the users data, this table should be called user Or users?

Let's analyze both cases to understand the difference between each approach.

Plural

Clear that the table is storing more than one user.
It reads well in the FROM clause

SELECT id, name from users;

Singular

We are not naming a table, we are naming a relation.
It reads well everywhere else in the SQL query:

SELECT id, name
FROM user
JOIN country ON ( user.countryId = country.id )
WHERE country.name = "Japan"

It would make less sense if the ON Clause read users.country_id
If you are using an ORM, the class you will store your data is already in singular User

Column Name

You should use camelCase for your column names, specially for Node.JS.

Snake Case `snake_case`

SQL standards are case insensitive
Readability is better

Camel Case `camelCase`

It's better for data mapping. for a JSON object property user.firstName is better than user.first_name
Specially for Javascript standards, camelCase is recommended.
Faster typing avoiding the _
Better Readability for short worlds
Bad Readability for long words
- githubAccessToken
- facebookAccessToken

Fields

Date Fields

Include the timezone, specially if you are working on a global project.
As a good practice all tables should have a createdAt and updatedAt column, it will be very useful for debugging.
Field should finish with At
- createdAt
- updatedAt
- deletedAt
- lastUpdatedAt

Primary Key

Column name must be always named id.
It's short, simple and you don't have to remember the names of the fields to join tables.

Foreign Keys

They should be a combination of the name of the foreign table and the + _id, examples:

user_id
post_id

Status Fields

use booleans for single status.
- isActive
- isPublished
Use enums if you need few columns that can be true or false at the same time.
- post.status (draft, inactive, published)
- user.status (inactive, active, banned)
- product.status (draft, in_review, approved, disapproved)

Tools

Here are two tools I recommend to design your database schemas. I like them because their UI/UX is good, and I really enjoy using them.

DB diagram

A free, simple tool to draw ER diagrams by just writing code.

https://dbdiagram.io

FREE
Online service
Create your DB diagrams by writing
One click sharing
Export to Images and PDF

SQLEditor

Makes database design easier than ever!
https://www.malcolmhardie.com/sqleditor/

FREE (for 30 days, but you can continue using)
Paid ($80 single user license)
Mac app
Great usability
Fast
Export to Images and PDFs

Image Optimization, Processing and Hosting

Rodrigo Ramirez — Wed, 17 Feb 2021 06:30:37 +0000

Hosting images and processing them is quite complicated. It involves many elements to do this correctly and to be sure it scales with your website.

Hosting images requires 3 key elements:

A place to Storage your images
A way to Resize the images on demand
A CDN to cache and deliver the images to your users as fast as possible.

You can achieve this by implementing your own solution or delegating all the complexity to a third party service like AWS or Cloudinary.

Let's analyze each one of these elements and their costs and by the end of this post, you will be able to decide which way is right for your project.

Storage

A place to host the images uploaded by your users. It could be in your own server or using a third-party service like Amazon S3 or Cloudinary. In each case, you will need to consider the cost of hosting the images, and It depends on the amount and traffic you expect to receive to calculate the final price.

Here is a simple comparison of storage prices without considering the bandwidth.

DigitalOcean:

Cheapest Doplet with at least 5GB free for OS+others.
Up to 50GB is a good option to keep the files on the same server. After that, the prices increase dramatically for storage. It would be better to consider Digital Ocean Spaces at that point.

Amazon S3:

Only S3 storage.

Cloudinary:

All in one solution. Difficult to compare individually.

Image Resizing

After we receive the user's image, you will need to display a resized version on your website. We don't want to make users download a big size image when browsing our website, especially from their mobile devices. Speed is important for UX and SEO purposes.

Resizing Strategies

At Upload time

After we store the user's image, you will need to create the resized versions of the original picture. It will require you to know in advance which dimensions are necessary for your website. If later you require a new size, you will need to regenerate all the previous pictures again.

On Demand

Recommended solutions, but more complex to implement by yourself.
Instead of calling your images directly, you will request them from a special URL that generates the new image, passing in the URL the new size parameters. Example:

https://domain.com/image-resize?source={local-path}&width=500&height=500

Implementations

Own Solution

The cost, in this case, is the development time and the maintenance of the code.

If you opt to resize the images at the upload time, you will need to consider doing the resizing in the background to don't make your users wait while you are processing the images.

AWS

With AWS, you will have to create a serverless function that triggers when a new image is uploaded to the S3 bucket or create a URL to execute it on demand and generate the resized images.

Likely there is a solution provided by amazon that simplifies all these processes and much more:

Serverless Image Handler https://aws.amazon.com/solutions/implementations/serverless-image-handler/

Cloudinary

Cloudinary includes all these features in their service. But the price is very tricky, be sure to check them very carefully.

Cloudinary Pricing https://cloudinary.com/pricing

CDN

Having a CDN between where your images are hosted and your users is a good practice. It will speed up your website by serving the images to your users from their closes location. If you are using a service to host your images, it probably already includes a CDN.

Cloudflare

Suppose you are hosting the images on your own server. In that case, Cloudflare is the best solution for you, they have a free version, and It not only provides a CDN for your images, but It also does for your entire website as well that offers a security layer between your user and your server.

https://www.cloudflare.com

AWS Cloudfront

CDN solution from AWS. Very easy to connect with an existing S3 bucket. If you are using the "Serverless Image Handler" solution from AWS, It already includes Cloudfront.

https://aws.amazon.com/cloudfront/

Cloudinary

Already provide a CDN by default.

Conclusions

Here we have the summary of the 3 solutions I have mentioned in this post.

DigitalOcean / Own Server

Pros

✅ Good up to 50GB of storage

✅ Fixed cost

✅ Cloudflare for CDN and Security

Cons

❌ Image processing requires your own implementation

❌ If you need more than 50GB, you will need to consider another alternative.

AWS

Pros

✅ Amazon S3 is very cheap

✅ A popular option for developers to storage files

✅ Cloudfront for CDN

✅ Image Server Handler solution from AWS simplifies everything

✅ It scales infinite, and the prices are low

Cons

❌ No free options, but very cheap

❌ You will need to understand the basic of AWS

Cloudinary

Pros

✅ Free up to 25GB = 25 credits

✅ Simples options

✅ All in one solution

✅ Extra features (Widgets, Video Hosting, etc.)

Cons

❌ It could get costly

❌ To have a copy of your files, you will need to pay at least $99 monthl

GraphQL Schema Best Practices

Rodrigo Ramirez — Mon, 08 Feb 2021 07:19:13 +0000

Are you creating or managing GraphQL schemas, but you don't know the best practice for creating maintainable schemas that your team or even you can follow to gain confidence in your project?

In this post, I will explain the best practice I have found by creating high maintainable GraphQL Schemas for the projects I'm working on.

General Advice

When designing your GraphQL schema, one of the common mistakes is to replicate your database tables and fields.

Think in the GraphQL Schema DX (Developer Experience); you want to simplify the use of your schema for your team.

My advice here will be to create your Schema in the exact way that you need to consume them. Avoid adding fields that you will not need to use or overcomplicate to get the information for your UI.

Start with the minimum and expand them as you need. Taking too many decisions in advance could lead to feature problems and force you to refactor the code.

Naming Fields

Naming fields are very important because they can impact future schema changes; being very explicit early on will make things easier in the future.

❌ Bad example:

type Product {
    id: ID!
    category: String!
    image: String
    visits: Int!
}

✅ Good example:

type Product {
    id: ID!
    image: Image
    stats: ProductStats! // or just visitsCount: Int!
}

type ProductStats {
    visitsCount: Int!
    purchasesCount: Int!
}

type Image {
    id: ID!
    url(size: ImageSize): String
    description: "String"
}

enum ImageSize {
    XS,
    SM,
    MD,
    LG,
    ORIGINAL
}

Queries

Avoid writing queries named like getProduct or getAllProducts These queries will always return something. I consider starting with the word get is redundant and makes your schema difficult to read.

Don't force your queries to do more than one thing, instead create different queries that are self-explanatory.

❌ Bad query examples:

type Query {
    product(id: ID, slug: String): Product
    getProduct(id: ID!): Product
}

✅ Good query examples:

type Query {
    productById(id: ID!): Product
    productBySlug(slug: ID!): Product
}

Pagination

Returning multiple results in GraphQL could end in a very complicated schema design, but you can opt for a simple solution depending on your project.

Offset Pagination

Best for page based paginations, users can jump to a specific page. This option may be the right fit for most of the cases. If you are using an ORM it would be easy to implement.

But It has some disadvantages if your data change often; some results could be potentially skipped or returned duplicated.

type Query {
    products(page: Int, limit: Int, filters: ProductFilters): ProductConnection!
}

type ProductConnection {
    nodes: [Product!]
    pageInfo: PageInfo!
    totalCount: Int!
}

type PageInfo {
    hasNextPage: Boolean!
    hasPreviousPage: Boolean!
    currentPage: Int!
    perPage: Int!
    lastPage: Int!
}

Cursor Pagination (Relay way)

Best for infinite scroll or Load more results. (Facebook, Airbnb uses this style), In this solution, there is no concept of pages.

This one will scale well for large datasets, but it's the most complicated to implement. With this style, you can prevent the problems of offset pagination.

type Query {
   products(first: Int, after: ID, last: Int, before: ID, 
 filters: ProductFilters): ProductConnection!
}

type ProductConnection {
   edges: ProductEdges!
   pageInfo: PageInfo!
   totalCount: Int!
}

type ProductEdges {
   nodes: Product!
   cursor: ID!
}

type PageInfo {
   hasNextPage: Boolean!
   hasPreviousPage: Boolean!
   startCursor: ID
   endCursor: ID
}

Mutations

We can summarise the mutation naming conventions into 5 rules

Mutation are named as verbs CreateProduct , UpdateProduct , DeleteProduct
There must be a single argument input
The input type name is the capitalised mutation name with a Input postfix e.g CreateProductInput , UpdateProductInput
The returned value is a new custom type that can contain various fields.
The return type name is the capitalized mutation name with a Payload postfix e.g. CreateProductPayload , UpdateProductPayload

CreateProduct

type Mutation {
   CreateProduct(input: CreateProductInput!): CreateProductPayload!
}

input CreateProductInput {
   name: String!
   categoryId: ID!
   description: String
}

type CreateProductPayload {
   product: Product!
}

UpdateProduct

type Mutation {
   UpdateProduct(id: ID, input: UpdateProductInput!): UpdateProductPayload!
}

input UpdateProductInput {
   name: String
   description: String
   categoryId: ID
}

type UpdateProductPayload {
   product: Product!
}

DeleteProduct

type Mutation {
   DeleteProduct(id: ID): DeleteProductPayload!
}

type DeleteProductPayload {
   isDeleted: Boolean!
}

Conclusions

These best practices are what worked for me, and I hope they are useful for you.

Just remember to make your schema self-explanatory, even if it requires you to add more queries or mutations.

Moving from PHP to NodeJS

Rodrigo Ramirez — Tue, 02 Feb 2021 07:30:04 +0000

I started my career in Web development using PHP. Since that day, PHP was evolving and getting more robust and performant than before. With Frameworks like Laravel, PHP has increased its popularity, keeping it one of the main programming languages that companies choose to create their websites.

If PHP with Laravel is a very good option for making high scalable websites, why have I decided to switch to the Node.JS/Javascript ecosystem?

Many reasons make me move from my comfort zone to challenge myself with a new programming language.

One programming language

When you are creating successful websites/services, one of the most important factors is if they have a good UI/UX. In the past, these interfaces were static, but now, they are more reactive to the users' interactions and require you to combine Javascript with your backend language.

This combination makes you to master two different programming languages and switches the way you write code from one to another.

In the end, most of the time is spent on the user interface and less on the backend. The hard work is now on the frontend.

The first reason for moving to Node.JS is to utilize the same language both on the frontend and backend. And this leads to the next point.

One type of programmer

Utilizing the same programming languages across all of our projects simplifies the hiring process. Because if you hire a programmer who is good at Javascript/Node.JS, they can participate in the frontend and backend, etc.

Today companies, need to create their website and mobile applications, and Javascript with hybrid solutions such as React Native allows you to use Javascript to create multi-platform applications.

Sharing responsibilities between the team

One common programming language allows having more synergy between your team.

Now all the team can switch between projects and collaborate with other members.

There is no more, the backend guy or the just frontend guy. Of course, all of us have our strengths and weaknesses, but It doesn't block to support other members with problems or deadlines.

Code review across projects

Because all the team members use the same languages, They can review each other code allowing them to strengthen the team.

Package compatibility

In the PHP world, some libraries depend on a specific version of PHP, but in the Node.JS world, everything is compiled at the end with the help of webpack, etc., so you don't need to worry so much about these problems.

Same as PHP with composer packages, there are NPM with millions of packages to help you to create sophisticated websites.

Speed of Development

It's just javascript, As long as you are using the latest version of Node.JS on your computer and, You can share part of your code between all of your projects (web, mobile app, backend).

Testing

Without any doubt, Javascript is very mature when it comes to testing applications. And the good part is that you can use the same testing framework for your website, backend, and mobile apps.

If you use Javascript with Typescript adding strong typing will save you time catching errors and proving fixes before running code. You will be surprised about how good it works.

Host Anywhere

Because your app mostly depends on Node.JS that comes by default in most of the OS. It's effortless to host your application anywhere.

Node.JS/JS apps are the best fit for serverless solutions, saving you cost, and ensuring that your applications scale together with your traffic. You don't have to worry anymore about managing servers.

Final Conclusions

PHP still an excellent option. I really like PHP; don't misunderstand me. But at the end of the day, Node.JS makes my developer experience(DX) much better, and It's what the market is requiring.

Tailwind CSS vs Styled-components

Rodrigo Ramirez — Thu, 14 Jan 2021 09:22:00 +0000

Are you considering using Tailwind CSS rather than Styled-components or another CSS in JS solution? In this post, you will learn the advantages and disadvantages of each approach.

First, Let's start by explaining the good and bad things about each of them, and at the end, let's jump to conclusions where you can see my way to go and decide yours.

Tailwind CSS

Tailwind CSS is a utility-first CSS framework. It means that they provide a set of CSS classes representing each combination of CSS property and value. For example, p-4 represents padding: 1rem and block represents display: block;

So you may be wondering why we need to use classes instead of writing the CSS directly in an HTML style tag? There are many reasons for that, especially with Tailwind CSS that comes equipped with good defaults for sizing, colors, and helpers for responsible classes.

You can't apply responsive styles directly in your HTML style attribute. You will need to have a CSS file or create a style tag inside your HTML to achieve this.

Let me show the potential of Tailwind CSS with one example:

HTML+CSS

<div class="button">
    Click Me
</div>

<style>

    .button {
        background-color: red; 
        color: white; 
        border-rounded: 3px; 
        text-align: center;
    }

    .button:hover {
        background-color: black;
    }

    @media (min-width: 768px){
        .button {
            margin-bottom:4px;
        }
    }
</style>

Tailwind CSS

<div class="bg-red-400 text-white rounded text-center hover:bg-black md:mb-4">
    Click Me
</div>

As you can see, in the HTML+CSS example, we needed to use a style tag to add a hover state and responsive styles to our button. But with Tailwind CSS, We achieved the same with fewer code lines, and using some specific prefixes to our CSS classes like hover: or md: we can extend the use of the base utilities.

Another good point of Tailwind CSS is their default settings and the possibility of extending or replacing their defaults. It will allow you to share your theme between different projects and have good defaults when working with the team gaining consistency across your design.

Finally, Let's talk about the final CSS bundle size delivered to the browser. By default, Tailwind CSS will generate all the CSS utilities class name combinations, but many of those CSS classes will not be used in your project. Minified It's about 399kb.

We have two solutions to reduce the final bundle size.

The first one will be by manually adding only the necessary theme settings inside your project, but there is a high chance you to miss some of them, and even with that, you will still delivering unused classes to your bundle.

The second and the recommended way is to use PurgeCSS, This library is already build-in Tailwind CSS, and It can be activated easily from your Tailwind config file.

PurgeCSS is in charge of automatically removing the unused classes, providing the paths to your HTML/JS files. This library will scan those files and extract the unused class names from the final bundle.

For more information check their docs:
https://tailwindcss.com/docs/optimizing-for-production#purge-css-options

To summarize the pros and cons of using Tailwind CSS:

Pros

✅ Good defaults

✅ Extensible theme settings

✅ Easy to share your theme settings between projects

✅ Small bundle size

✅ Very good DX

✅ Fast for prototyping

✅ No class names conflict

Cons

❌ You will need to get used to the class names

❌ PurgeCSS requires to work to avoid generating the class names dynamically

❌ Write your logic to add or remove classes from your HTML

Styled-components

Styled-components is one of the most famous CSS in JS solutions. It works with React components and allows you to generate presentational components easily using pure CSS syntax.

With Styled-components, you can use Sass style syntax to write nesting rules. When your components render, they automatically generate unique class names.

An example of a Button component with styled-components would be:

const Button = styled.a`
    background-color: red; 
    color: white; 
    border-rounded: 3px; 
    text-align: center;

    &:hover{
        background-color: black;
    }

    @media (min-width: 768px){
        margin-bottom:4px;
    }
`;

<Button>Click me</Button>

With the help of webpack, you can generate the critical CSS based on the components rendered for each page and deliver it using SSR with a code-splitting implementation.

On the client-side, when a new component is rendered the CSS from that component is injected inside a global style tag and removed from it when the component is unmounted.

Pros

✅ Generate your components and CSS in one time

✅ Use native CSS syntax

✅ Write CSS conditionals using Javascript

✅ Easy to start using

✅ Good DX

Cons

❌ No default theme

❌ Responsive need to be writing by hand

❌ Rules are needed to keep the consistency in your design.

❌ With Typescript, the DX decrease.

❌ Similar components can deliver the same CSS.

Conclusions

Both solutions are excellent. I had experience using both of them in production. But lately, I'm more inclined to the Tailwind CSS approach, and the main reason for this is their default theming and their easy way to apply responsive, dark mode, and other utilities to those based classes.

On my previous projects with styled-components, one of the main challenges I had with my team was defining good defaults to generate consistency between our projects. And we had spent a lot of time creating utilities to apply in the styled-components way responsive and dark mode styles, but it resulted in increasing the complexity of our code.

Since we started using Tailwind CSS, that problem disappear, and everyone is happy now using it.

Once you get used to their syntax, I can guarantee that your DX and Development speed will increase considerably.

Extra tip:

If you are using VScode (not sure about other IDEs), but with the Tailwind CSS IntelliSense plugin, you can have autocompletion for your class names directly from your tailwind theme settings file.

More information here:
https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss

DEV Community: Rodrigo Ramirez

How Organization Roles Change in the AI Era

Leadership Becomes Architecture

Three Domains, Three Architects

Members — Broad Generalists with Judgment

Smaller Teams, Broader Roles

The Junior Problem Is Real

AI Helps You Think — But Does Not Decide for You

The Shift

Software Development in the AI era

The big shift: code is cheap, trust is expensive

Codebases: consistency matters more than speed

Change must be easy to understand

Local reasoning becomes essential

Consistent patterns build trust

Structure is a safety mechanism

Testing & QA: defining trust, not finding bugs

Tests as shared truth

Quality moves earlier, by necessity

QA designs, AI executes

Trust comes from systems, not heroics

Product and context: clarity becomes the main input

Context replaces instructions

Product work moves closer to engineering

Context is a scalability problem

Think small, iterate fast

Writing less, explaining better

Team shape: smaller teams, higher responsibility

Speed changes the failure mode

Smaller teams need clearer ownership

Responsibility moves closer to the work

AI assists both sides

Trust must scale with speed

Closing thoughts

Database, Table and Column naming conventions

Table Name

Plural

Singular

Column Name

Snake Case snake_case

Camel Case camelCase

Fields

Date Fields

Primary Key

Foreign Keys

Status Fields

Tools

DB diagram

SQLEditor

Image Optimization, Processing and Hosting

Storage

Image Resizing

Resizing Strategies

Implementations

CDN

Conclusions

DigitalOcean / Own Server

AWS

Cloudinary

GraphQL Schema Best Practices

General Advice

Naming Fields

Queries

Pagination

Offset Pagination

Cursor Pagination (Relay way)

Mutations

Conclusions

Moving from PHP to NodeJS

One programming language

One type of programmer

Sharing responsibilities between the team

Code review across projects

Package compatibility

Speed of Development

Testing

Host Anywhere

Final Conclusions

Tailwind CSS vs Styled-components

Tailwind CSS

Snake Case `snake_case`

Camel Case `camelCase`