<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Maria Eduarda Paiva</title>
    <description>The latest articles on DEV Community by Maria Eduarda Paiva (@maria_eduarda_paiva).</description>
    <link>https://dev.to/maria_eduarda_paiva</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4095631%2F80a81f9e-1805-45b8-9fea-c63fbee441c8.png</url>
      <title>DEV Community: Maria Eduarda Paiva</title>
      <link>https://dev.to/maria_eduarda_paiva</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/maria_eduarda_paiva"/>
    <language>en</language>
    <item>
      <title>NutriApp: uma plataforma que conecta profissional com paciente</title>
      <dc:creator>Maria Eduarda Paiva</dc:creator>
      <pubDate>Wed, 26 Aug 2026 15:41:55 +0000</pubDate>
      <link>https://dev.to/maria_eduarda_paiva/nutriapp-uma-plataforma-que-conecta-profissional-com-paciente-50nb</link>
      <guid>https://dev.to/maria_eduarda_paiva/nutriapp-uma-plataforma-que-conecta-profissional-com-paciente-50nb</guid>
      <description>&lt;p&gt;O NutriApp é um projeto de estudos: plataforma de saúde conectando pacientes, nutricionistas, médicos e personal trainers, cada perfil enxergando só o que sua permissão libera.&lt;/p&gt;

&lt;p&gt;Stack: React 19 + TypeScript, TanStack Start (SSR, rotas file-based e server functions), Tailwind v4 + shadcn/ui, react-hook-form + Zod para formulários tipados, TanStack Query para cache, e Lovable Cloud (Supabase) com Postgres e Row Level Security.&lt;/p&gt;

&lt;p&gt;O maior desafio foi o controle de acesso por papéis. Três tabelas centrais — profiles, user_roles e pacientes — todas com RLS ativado. Paciente lê só seus próprios registros; profissionais e administradores enxergam todos os pacientes. Pra evitar recursão de política (problema clássico de RLS), criei funções SECURITY DEFINER como has_role e is_profissional, quebrando o ciclo de verificação.&lt;/p&gt;

&lt;p&gt;Autenticação e segurança:&lt;/p&gt;

&lt;p&gt;Login por email/senha, com rota administrativa separada (/admin/login)&lt;br&gt;
Server functions protegidas com requireSupabaseAuth, checando papel antes de qualquer ação administrativa&lt;br&gt;
Validação client-side com Zod: senha entre 6-72 caracteres, email até 255, telefone opcional&lt;br&gt;
Usuários criados por admin já nascem confirmados e ativos, reduzindo fricção operacional&lt;/p&gt;

&lt;p&gt;Automação como diferencial: o perfil de saúde calcula IMC em tempo real e gera um plano inicial baseado no objetivo selecionado (emagrecimento, ganho de massa ou controle de patologias) — reduzindo trabalho manual do profissional.&lt;/p&gt;

&lt;p&gt;Aprendizados principais:&lt;/p&gt;

&lt;p&gt;RLS bem modelado desde o início evita gambiarra depois — pensar em papéis antes da primeira quere economiza retrabalho.&lt;br&gt;
Verificação de papel precisa estar no backend, nunca só na UI.&lt;br&gt;
Separar login de paciente/profissional do login admin simplifica segurança e UX ao mesmo tempo.&lt;/p&gt;

</description>
      <category>database</category>
      <category>react</category>
      <category>security</category>
      <category>typescript</category>
    </item>
  </channel>
</rss>
